Uploaded image for project: 'JGroups'
  1. JGroups
  2. JGRP-578

It is possible to create a deadlock when trying to close a channel which is not yet connected

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Won't Do
    • Icon: Major Major
    • 2.6
    • 2.5
    • None
    • Medium
    • Workaround Exists
    • Hide

      There is actually a pretty dirty way of handling this.

      ProtocolStack stack = channel.getProtocolStack();
      GMS gms = (GMS) stack.findProtocol("GMS");
      gms.getImpl().stop();

      Show
      There is actually a pretty dirty way of handling this. ProtocolStack stack = channel.getProtocolStack(); GMS gms = (GMS) stack.findProtocol("GMS"); gms.getImpl().stop();

      The problem lies in the fact that both connect() and close() in JChannel are synchronized on the same object, the channel. Now lets assume that you have called connect() on the channel. This will eventually take us to the join(Address mbr) in ClientGmsImpl. Now if the channel cannot connect for some reason the code will be stuck here in the while(!leaving) clause until such time that the connection can be established. Now if the user in the meantime decides to quit you will have to call close() on the channel. Unfortuanately nothing will happen since the initial connect is still holding the lock to the channel. Deadlock.

      Now to how to create the hanging join. That is pretty simple by just setting the disable_initial_coord flag and making sure that the entity set to be the coordinator is not available (i.e. not started). I know that you intend to deprecate this flag eventually but first of all we totally depend on this flag for a correct behaviour in our environment and secondly I assume that you will introduce something similar in the upcoming 3.0 version.

            rhn-engineering-bban Bela Ban
            anderspersson_jira Anders Persson (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

              Created:
              Updated:
              Resolved: