JBoss ESB
  1. JBoss ESB
  2. JBESB-256

An explicit Thread.sleep should not be required between starting the message aware listeners, and starting the gateway listeners

    Details

    • Type: Bug Bug
    • Status: Closed Closed (View Workflow)
    • Priority: Critical Critical
    • Resolution: Done
    • Affects Version/s: 4.0 CR1
    • Fix Version/s: 4.0
    • Component/s: Rosetta
    • Security Level: Public (Everyone can see)
    • Labels:
      None
    • Similar Issues:
      Show 10 results 

      Description

      You have to manually enter a Thread.sleep between launching EsbListenerController in a thread and launching GatewayListenerController. I spent ages trying to work out an error until I was let in on the little secret. If EsbListenerController is this scencitive, it should manage it's startup such that the caller blocks until EsbListenerController is fully up and ready. This would be a piece of * to do.

        Issue Links

          Activity

          Hide
          Mark Little
          added a comment -

          Agreed.

          Show
          Mark Little
          added a comment - Agreed.
          Hide
          Mark Little
          added a comment -

          Which class(es)?

          Show
          Mark Little
          added a comment - Which class(es)?
          Hide
          Tom Fennelly
          added a comment -

          listeners:org.jboss.soa.esb.listeners.message.EsbListenerController must be up and running fully (in its own thread) before listeners:org.jboss.soa.esb.listeners.gateway.GatewayListenerController.

          Currently it's Runnable and has an internal state property that can be accessed via a getState method. I'd suggest 2 mods to EsbListenerController for this (can be ignored of course ):

          1. Less Important:
          Add an additional state of something like "Ready" and set the state to this before line 316. At this point the listeners under its control are all up and running.

          2. More Important:
          I'd suggest making the Runability of EsbListenerController hidden internally and forcing its constrution into a static factory method (make all constructors private). From in there, you can construct the instance, start your thread, and block returning from the factory method until the internal (hidden) Runnable is in a state of "Ready". This will stop anyone launching an instance of this class and continuing on before it is "ready".

          Just a suggestion - of course there are other ways of doing it I'm sure.

          Show
          Tom Fennelly
          added a comment - listeners:org.jboss.soa.esb.listeners.message.EsbListenerController must be up and running fully (in its own thread) before listeners:org.jboss.soa.esb.listeners.gateway.GatewayListenerController. Currently it's Runnable and has an internal state property that can be accessed via a getState method. I'd suggest 2 mods to EsbListenerController for this (can be ignored of course ): 1. Less Important: Add an additional state of something like "Ready" and set the state to this before line 316. At this point the listeners under its control are all up and running. 2. More Important: I'd suggest making the Runability of EsbListenerController hidden internally and forcing its constrution into a static factory method (make all constructors private). From in there, you can construct the instance, start your thread, and block returning from the factory method until the internal (hidden) Runnable is in a state of "Ready". This will stop anyone launching an instance of this class and continuing on before it is "ready". Just a suggestion - of course there are other ways of doing it I'm sure.
          Hide
          Tom Fennelly
          added a comment -

          Just to add there - basically what I'm proposing is to make the classes construction + thread launch + wait-until-ready an atomic operation. One way of doing that is what I suggested there.

          Show
          Tom Fennelly
          added a comment - Just to add there - basically what I'm proposing is to make the classes construction + thread launch + wait-until-ready an atomic operation. One way of doing that is what I suggested there.
          Hide
          Tom Fennelly
          added a comment -

          Done.

          The only way to get your hands on an instance of EsbListenerController now is via the EsbListenerControllerFactory (it has to factory methods). It makes sure that before it returns, the controller is in a state of "Ready" (or an error/shutdown state). The controller itself will not transition into a state of "Ready" until all listeners under its control are in a state of "Ready".

          Show
          Tom Fennelly
          added a comment - Done. The only way to get your hands on an instance of EsbListenerController now is via the EsbListenerControllerFactory (it has to factory methods). It makes sure that before it returns, the controller is in a state of "Ready" (or an error/shutdown state). The controller itself will not transition into a state of "Ready" until all listeners under its control are in a state of "Ready".

            People

            • Assignee:
              Mark Little
              Reporter:
              Tom Fennelly
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: