I managed to debug this a little further and have identified why the startup code is
hanging -- it is because of something my code is doing (I'll come to that in a
second). I still don't know why the WebService port is being looked up before it is
defined so there is still an issue there.
The hang is because I am trying to coordinate initialization of my war apps and the XTS
service which deploys them. The problem I face is that the listeners are run in an
arbitrary order but the war apps have initialization dependencies. So, I make the war
listeners register callbacks in a fixed sequence. If any of them finds that the sequence
is complete after regsitering then it runs all the callbacks.
This was ok until I added transaction recovery which requires initialization in the XTS
service start() routine before the wars can be initialized. I had assumed that the XTS
service start() call happened in parallel with the war listener calls so I added a latch
in the callback runner which was released by the XTS service start(). If the runner gets
there first it does a wait() and the start() call wakes it with a notfiy(). It appears
that the start() and listener call actually run in the same thread in arbitrary order and
up until now the start() call has always run first. Now, the sar start() call occasionally
gets run last, resulting in a deadlock. I guess I need to make my war apps depend on the
XTS service bean.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4184411#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...