axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas Veithen <andreas.veit...@gmail.com>
Subject Re: Problem with ServiceClient/ListenerManager
Date Tue, 25 May 2010 18:07:20 GMT
The start/stop vs. init/destroy issue is now fixed; see r948144.

Andreas

On Tue, May 25, 2010 at 19:43, Andreas Veithen
<andreas.veithen@gmail.com> 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 <hiranya911@gmail.com> 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 <hiranya911@gmail.com>
>> wrote:
>>>
>>> Hi Deepal,
>>>
>>> On Tue, May 25, 2010 at 7:50 PM, Deepal Jayasinghe <deepalk@gmail.com>
>>> 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
>>>> <hiranya911@gmail.com> 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: hiranya@wso2.com;  Mobile: +94 77 633 3491
>>>> > Blog: http://techfeast-hiranya.blogspot.com
>>>> >
>>>>
>>>>
>>>>
>>>> --
>>>> http://blogs.deepal.org
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>>>> For additional commands, e-mail: java-dev-help@axis.apache.org
>>>>
>>>
>>>
>>>
>>> --
>>> Hiranya Jayathilaka
>>> Senior Software Engineer;
>>> WSO2 Inc.;  http://wso2.org
>>> E-mail: hiranya@wso2.com;  Mobile: +94 77 633 3491
>>> Blog: http://techfeast-hiranya.blogspot.com
>>
>>
>>
>> --
>> Hiranya Jayathilaka
>> Senior Software Engineer;
>> WSO2 Inc.;  http://wso2.org
>> E-mail: hiranya@wso2.com;  Mobile: +94 77 633 3491
>> Blog: http://techfeast-hiranya.blogspot.com
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org


Mime
View raw message