It's definitely true that some of the code that AbstractTransportListenerEx executes inside init and destroy should actually be executed in start/stop. That needs to be fixed. However, your findings seem to suggest also that Axis2 may call the init method of a transport listener twice. That should be considered a bug as well.
Andreas On Tue, May 25, 2010 at 18:15, Hiranya Jayathilaka <[email protected]> wrote: > I ran a few more debug sessions and it seems the culprit is > AbstractTransportListenerEx. This is the class which starts globally > configured endpoints during init phase (before start is called). But the > ListenerManager does not consider a transport is started until the start > method is called on the listener. Therefore following step sequence can lead > to the same endpoint getting started twice (code is not in actual Java > code): > listener.init(); // This will start a globally configured endpoint > if (!ListenerManager.isStarted(listener)) { > listener.init(); // re-initialization of the listener !!! > } > Any idea how we can fix this? > Thanks, > Hiranya > > On Tue, May 25, 2010 at 8:36 PM, Hiranya Jayathilaka <[email protected]> > wrote: >> >> Hi Deepal, >> >> On Tue, May 25, 2010 at 7:50 PM, Deepal Jayasinghe <[email protected]> >> wrote: >>> >>> Hiranya, >>> >>> I will give you a detailed answer later (now I do not have access to >>> the source code), here is what I remember. As I remember correct when >>> you first initialize the transport it only adds to the HashMap, and >>> when you want to start it just start the entry in the Hasmap. So >>> nothing harm happen, this code is around 4 years now and haven't seen >>> any problem, so I believe code works fine (but need to double check, >>> as I said before I will double check and let you know more about it) >> >> Yes, I believe for most scenarios it will work fine. But in the scenario I >> mentioned above it becomes a problem (as detected by one of the TCP test >> cases). >> The ListenerManager maintains a map of started transports. For a transport >> to be considered started, it has to be added to this map. For this to happen >> you have to call start on the ListenerManager. Calling init on >> ListenerManager will only call init on the respective transport receivers >> (which will get the transport endpoints up and running). Therefore from the >> ListenerManager pov the transport is not really started even though the >> ports/sockets are running. >> Thanks, >> Hiranya >>> >>> Deepal >>> >>> On Tue, May 25, 2010 at 10:07 AM, Hiranya Jayathilaka >>> <[email protected]> wrote: >>> > Hi Folks, >>> > While debugging through the TCP test cases, I stumbled upon a little >>> > problem. Let's say somebody creates a ServiceClient instance as >>> > follows: >>> > ServiceClient sender = new ServiceClient(configContext, clientService); >>> > When this is called, internally it will initialize a ListenerManager >>> > instance. I found the following bit of code in the ServiceClient: >>> > // Initialize transports >>> > ListenerManager transportManager = >>> > configContext.getListenerManager(); >>> > if (transportManager == null) { >>> > transportManager = new ListenerManager(); >>> > transportManager.init(this.configContext); >>> > } >>> > This in turns initializes transport listeners. However ServiceClient >>> > does >>> > not call start on the ListenerManager. Therefore none of the transports >>> > get >>> > marked as started in the ListenerManager. Now, if I try to use the >>> > service >>> > client to invoke a service with useSeparateListener set to true, the >>> > following bit of code in the ClientUtils class is executed: >>> > if >>> > (!listenerManager.isListenerRunning(transportIn.getName())) { >>> > listenerManager.addListener(transportIn, false); >>> > } >>> > The if condition evaluates to true since the listener has not been >>> > marked as >>> > started. In addListener method the corresponding transport listener >>> > will be >>> > initialized again. If an endpoint has been configured globally, this >>> > can >>> > result in the same endpoint getting started twice thus potentially >>> > causing >>> > bind exceptions. I'm experiencing this with the TCP transport now. >>> > Thoughts? >>> > Thanks, >>> > Hiranya >>> > -- >>> > Hiranya Jayathilaka >>> > Senior Software Engineer; >>> > WSO2 Inc.; http://wso2.org >>> > E-mail: [email protected]; Mobile: +94 77 633 3491 >>> > Blog: http://techfeast-hiranya.blogspot.com >>> > >>> >>> >>> >>> -- >>> http://blogs.deepal.org >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >> >> >> >> -- >> Hiranya Jayathilaka >> Senior Software Engineer; >> WSO2 Inc.; http://wso2.org >> E-mail: [email protected]; Mobile: +94 77 633 3491 >> Blog: http://techfeast-hiranya.blogspot.com > > > > -- > Hiranya Jayathilaka > Senior Software Engineer; > WSO2 Inc.; http://wso2.org > E-mail: [email protected]; Mobile: +94 77 633 3491 > Blog: http://techfeast-hiranya.blogspot.com > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
