You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by Hiranya Jayathilaka <hi...@gmail.com> on 2010/05/25 16:07:30 UTC
Problem with ServiceClient/ListenerManager
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
Re: Problem with ServiceClient/ListenerManager
Posted by Andreas Veithen <an...@gmail.com>.
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
<an...@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 <hi...@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 <hi...@gmail.com>
>> wrote:
>>>
>>> Hi Deepal,
>>>
>>> On Tue, May 25, 2010 at 7:50 PM, Deepal Jayasinghe <de...@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
>>>> <hi...@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
Re: Problem with ServiceClient/ListenerManager
Posted by Andreas Veithen <an...@gmail.com>.
The start/stop vs. init/destroy issue is now fixed; see r948144.
Andreas
On Tue, May 25, 2010 at 19:43, Andreas Veithen
<an...@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 <hi...@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 <hi...@gmail.com>
>> wrote:
>>>
>>> Hi Deepal,
>>>
>>> On Tue, May 25, 2010 at 7:50 PM, Deepal Jayasinghe <de...@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
>>>> <hi...@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
Re: Problem with ServiceClient/ListenerManager
Posted by Andreas Veithen <an...@gmail.com>.
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
<an...@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 <hi...@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 <hi...@gmail.com>
>> wrote:
>>>
>>> Hi Deepal,
>>>
>>> On Tue, May 25, 2010 at 7:50 PM, Deepal Jayasinghe <de...@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
>>>> <hi...@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
Re: Problem with ServiceClient/ListenerManager
Posted by Andreas Veithen <an...@gmail.com>.
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
<an...@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 <hi...@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 <hi...@gmail.com>
>> wrote:
>>>
>>> Hi Deepal,
>>>
>>> On Tue, May 25, 2010 at 7:50 PM, Deepal Jayasinghe <de...@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
>>>> <hi...@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
Re: Problem with ServiceClient/ListenerManager
Posted by Andreas Veithen <an...@gmail.com>.
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
<an...@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 <hi...@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 <hi...@gmail.com>
>> wrote:
>>>
>>> Hi Deepal,
>>>
>>> On Tue, May 25, 2010 at 7:50 PM, Deepal Jayasinghe <de...@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
>>>> <hi...@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
Re: Problem with ServiceClient/ListenerManager
Posted by Andreas Veithen <an...@gmail.com>.
The start/stop vs. init/destroy issue is now fixed; see r948144.
Andreas
On Tue, May 25, 2010 at 19:43, Andreas Veithen
<an...@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 <hi...@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 <hi...@gmail.com>
>> wrote:
>>>
>>> Hi Deepal,
>>>
>>> On Tue, May 25, 2010 at 7:50 PM, Deepal Jayasinghe <de...@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
>>>> <hi...@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
Re: Problem with ServiceClient/ListenerManager
Posted by Andreas Veithen <an...@gmail.com>.
The start/stop vs. init/destroy issue is now fixed; see r948144.
Andreas
On Tue, May 25, 2010 at 19:43, Andreas Veithen
<an...@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 <hi...@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 <hi...@gmail.com>
>> wrote:
>>>
>>> Hi Deepal,
>>>
>>> On Tue, May 25, 2010 at 7:50 PM, Deepal Jayasinghe <de...@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
>>>> <hi...@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
Re: Problem with ServiceClient/ListenerManager
Posted by Andreas Veithen <an...@gmail.com>.
The start/stop vs. init/destroy issue is now fixed; see r948144.
Andreas
On Tue, May 25, 2010 at 19:43, Andreas Veithen
<an...@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 <hi...@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 <hi...@gmail.com>
>> wrote:
>>>
>>> Hi Deepal,
>>>
>>> On Tue, May 25, 2010 at 7:50 PM, Deepal Jayasinghe <de...@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
>>>> <hi...@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
Re: Problem with ServiceClient/ListenerManager
Posted by Andreas Veithen <an...@gmail.com>.
The start/stop vs. init/destroy issue is now fixed; see r948144.
Andreas
On Tue, May 25, 2010 at 19:43, Andreas Veithen
<an...@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 <hi...@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 <hi...@gmail.com>
>> wrote:
>>>
>>> Hi Deepal,
>>>
>>> On Tue, May 25, 2010 at 7:50 PM, Deepal Jayasinghe <de...@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
>>>> <hi...@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
Re: Problem with ServiceClient/ListenerManager
Posted by Andreas Veithen <an...@gmail.com>.
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
<an...@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 <hi...@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 <hi...@gmail.com>
>> wrote:
>>>
>>> Hi Deepal,
>>>
>>> On Tue, May 25, 2010 at 7:50 PM, Deepal Jayasinghe <de...@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
>>>> <hi...@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
Re: Problem with ServiceClient/ListenerManager
Posted by Andreas Veithen <an...@gmail.com>.
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 <hi...@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 <hi...@gmail.com>
> wrote:
>>
>> Hi Deepal,
>>
>> On Tue, May 25, 2010 at 7:50 PM, Deepal Jayasinghe <de...@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
>>> <hi...@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
Re: Problem with ServiceClient/ListenerManager
Posted by Andreas Veithen <an...@gmail.com>.
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 <hi...@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 <hi...@gmail.com>
> wrote:
>>
>> Hi Deepal,
>>
>> On Tue, May 25, 2010 at 7:50 PM, Deepal Jayasinghe <de...@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
>>> <hi...@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
Re: Problem with ServiceClient/ListenerManager
Posted by Andreas Veithen <an...@gmail.com>.
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 <hi...@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 <hi...@gmail.com>
> wrote:
>>
>> Hi Deepal,
>>
>> On Tue, May 25, 2010 at 7:50 PM, Deepal Jayasinghe <de...@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
>>> <hi...@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
Re: Problem with ServiceClient/ListenerManager
Posted by Andreas Veithen <an...@gmail.com>.
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 <hi...@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 <hi...@gmail.com>
> wrote:
>>
>> Hi Deepal,
>>
>> On Tue, May 25, 2010 at 7:50 PM, Deepal Jayasinghe <de...@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
>>> <hi...@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
Re: Problem with ServiceClient/ListenerManager
Posted by Andreas Veithen <an...@gmail.com>.
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 <hi...@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 <hi...@gmail.com>
> wrote:
>>
>> Hi Deepal,
>>
>> On Tue, May 25, 2010 at 7:50 PM, Deepal Jayasinghe <de...@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
>>> <hi...@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
Re: Problem with ServiceClient/ListenerManager
Posted by Hiranya Jayathilaka <hi...@gmail.com>.
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
<hi...@gmail.com>wrote:
> Hi Deepal,
>
> On Tue, May 25, 2010 at 7:50 PM, Deepal Jayasinghe <de...@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
>> <hi...@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
Re: Problem with ServiceClient/ListenerManager
Posted by Hiranya Jayathilaka <hi...@gmail.com>.
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
<hi...@gmail.com>wrote:
> Hi Deepal,
>
> On Tue, May 25, 2010 at 7:50 PM, Deepal Jayasinghe <de...@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
>> <hi...@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
Re: Problem with ServiceClient/ListenerManager
Posted by Hiranya Jayathilaka <hi...@gmail.com>.
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
<hi...@gmail.com>wrote:
> Hi Deepal,
>
> On Tue, May 25, 2010 at 7:50 PM, Deepal Jayasinghe <de...@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
>> <hi...@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
Re: Problem with ServiceClient/ListenerManager
Posted by Hiranya Jayathilaka <hi...@gmail.com>.
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
<hi...@gmail.com>wrote:
> Hi Deepal,
>
> On Tue, May 25, 2010 at 7:50 PM, Deepal Jayasinghe <de...@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
>> <hi...@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
Re: Problem with ServiceClient/ListenerManager
Posted by Hiranya Jayathilaka <hi...@gmail.com>.
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
<hi...@gmail.com>wrote:
> Hi Deepal,
>
> On Tue, May 25, 2010 at 7:50 PM, Deepal Jayasinghe <de...@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
>> <hi...@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
Re: Problem with ServiceClient/ListenerManager
Posted by Hiranya Jayathilaka <hi...@gmail.com>.
Hi Deepal,
On Tue, May 25, 2010 at 7:50 PM, Deepal Jayasinghe <de...@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
> <hi...@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
Re: Problem with ServiceClient/ListenerManager
Posted by Hiranya Jayathilaka <hi...@gmail.com>.
Hi Deepal,
On Tue, May 25, 2010 at 7:50 PM, Deepal Jayasinghe <de...@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
> <hi...@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
Re: Problem with ServiceClient/ListenerManager
Posted by Hiranya Jayathilaka <hi...@gmail.com>.
Hi Deepal,
On Tue, May 25, 2010 at 7:50 PM, Deepal Jayasinghe <de...@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
> <hi...@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
Re: Problem with ServiceClient/ListenerManager
Posted by Hiranya Jayathilaka <hi...@gmail.com>.
Hi Deepal,
On Tue, May 25, 2010 at 7:50 PM, Deepal Jayasinghe <de...@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
> <hi...@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
Re: Problem with ServiceClient/ListenerManager
Posted by Hiranya Jayathilaka <hi...@gmail.com>.
Hi Deepal,
On Tue, May 25, 2010 at 7:50 PM, Deepal Jayasinghe <de...@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
> <hi...@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
Re: Problem with ServiceClient/ListenerManager
Posted by Deepal Jayasinghe <de...@gmail.com>.
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)
Deepal
On Tue, May 25, 2010 at 10:07 AM, Hiranya Jayathilaka
<hi...@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
Re: Problem with ServiceClient/ListenerManager
Posted by Deepal Jayasinghe <de...@gmail.com>.
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)
Deepal
On Tue, May 25, 2010 at 10:07 AM, Hiranya Jayathilaka
<hi...@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
Re: Problem with ServiceClient/ListenerManager
Posted by Deepal Jayasinghe <de...@gmail.com>.
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)
Deepal
On Tue, May 25, 2010 at 10:07 AM, Hiranya Jayathilaka
<hi...@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
Re: Problem with ServiceClient/ListenerManager
Posted by Deepal Jayasinghe <de...@gmail.com>.
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)
Deepal
On Tue, May 25, 2010 at 10:07 AM, Hiranya Jayathilaka
<hi...@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
Re: Problem with ServiceClient/ListenerManager
Posted by Deepal Jayasinghe <de...@gmail.com>.
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)
Deepal
On Tue, May 25, 2010 at 10:07 AM, Hiranya Jayathilaka
<hi...@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