I was just thinking that the problem sounds somehow familiar, and indeed some time ago, we already encountered it and I opened a JIRA for it: AXIS2-4552.
Andreas On Tue, May 25, 2010 at 19:43, Andreas Veithen <[email protected]> wrote: > 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]
