You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@synapse.apache.org by Paloschi Diego E <DE...@qinetiq.com> on 2008/10/21 20:41:42 UTC
RE: client http connection to synapse ESB closed four times
every 60 seconds
Hi Asanka,
Thanks for the quick reply.
I should have given more details on our client settings but, it is
currently configured to receive responses on a separate transport
channel (asynchronous) and it has WS-addressing enabled (WS-addressing
is enabled in our client, synapse ESB and web service). The transports
used from client to ESB to web service and back are all regular http (no
https). Also, there are no firewalls or anything like that along the way
as we are testing on a test-rig!)
The reason we are looking for a configuration problem within the ESB is
simply because when the client calls the web service directly, no
HttpClient connection loss occurs after 60 secs (no matter how long the
response takes).
Regards,
Diego.
> We are using a Synapse ESB (1.2) to mediate web service calls to a web
> service. In testing, we have an Axis2 client whose requests are sent
> to our Synapse ESB which, then forwards the request to the web
> service. The web service itself can take a long time (10mins+) to send
> a response back. The problem we have is that the client's http
> connection to the ESB is closed after 60 seconds and re-tries to send
> the request up to four times before giving up.
>
This is the default behavior of the Axis2 client side, which uses
HttpClient
> If our client sends the request to the web service directly, the
> client happily waits 10mins+ for a response to come back.
>
Irrespective of the fact that this works or not, I would very strongly
suggest that waiting on a open socket for a synchronous reply for 10
minutes+ does not look like a good approach.. what you should ideally
use is WS-Addressing, and receive the reply on a new channel. With
http/s and real life situations, an http/s connection does not live this
long, and many intermediate nodes may disconnect the connection during
such a long period of inactvity
The information contained in this E-Mail and any subsequent
correspondence is private and is intended solely for the intended
recipient(s). The information in this communication may be
confidential and/or legally privileged. Nothing in this e-mail is
intended to conclude a contract on behalf of QinetiQ or make QinetiQ
subject to any other legally binding commitments, unless the e-mail
contains an express statement to the contrary or incorporates a formal Purchase Order.
For those other than the recipient any disclosure, copying,
distribution, or any action taken or omitted to be taken in reliance
on such information is prohibited and may be unlawful.
Emails and other electronic communication with QinetiQ may be
monitored and recorded for business purposes including security, audit
and archival purposes. Any response to this email indicates consent
to this.
Telephone calls to QinetiQ may be monitored or recorded for quality
control, security and other business purposes.
QinetiQ Limited
Registered in England & Wales: Company Number:3796233
Registered office: 85 Buckingham Gate, London SW1E 6PD, United Kingdom
Trading address: Cody Technology Park, Cody Building, Ively Road, Farnborough, Hampshire, GU14 0LX, United Kingdom
http://www.qinetiq.com/home/notices/legal.html
RE: client http connection to synapse ESB closed four times
every 60 seconds
Posted by Paloschi Diego E <DE...@qinetiq.com>.
Hi Ruwan,
With regards to my initial post, I have realised that our client was not
including setUseSeparateListener(true) as one of its Options properly.
This has now been included and, the client now truly uses separate
channel for request/response.
Having fixed that, we still have problems within the ESB. i.e:
The client sends request to ESB and receives back a 202 accepted
response. But, we also get a 'TransportUtils - Did not find
RequestResponseTransport cannot set response written' debug message (?).
The ESB receives the request from the client and forwards it to the
service. But, after a minute exactly, the ESB gets a 'ERROR_CODE =
00000, ERROR_MESSAGE = Connection timeout' log message.
So, when the service actually sends the response back to the ESB, the
ESB logs a message 'ERROR AxisEngine The endpoint reference (EPR) for
the Operation not found is http:...'
Below is the synapse.xml used:
<definitions xmlns="http://ws.apache.org/ns/synapse">
<log level="full"/>
<sequence name="alt_endpoint">
<send>
<endpoint>
<address
uri="http://localhost:8081/ws-wp82/services/WP82Service"
optimize="mtom">
<enableAddressing
separateListener="true"/>
</address>
</endpoint>
</send>
</sequence>
<in>
<!-- establish which web service we are calling -->
<switch source="get-property('To')">
<case regex=".*WP82Service.*">
<!-- add a SOAP header to preserve the
SOAP request's original 'To' -->
<header name="esb:orig-to"
value="http://192.168.16:8081/ws-wp82/services/WP82Service"
xmlns:prime="http://esb.qinetiq.com"/>
<sequence key="alt_endpoint"/>
</case>
</switch>
<drop/>
</in>
<out>
<property name="enableMTOM" value="true" scope="axis2"/>
<send/>
</out>
</definitions >
Thanx for any pointers on this.
Regards,
Diego.
Assuming that you are using the asynchronous communication over http
using WS-Addressing in between client and ESB as well as ESB and web
service there should not be any timeouts, because the back channel of
the http request will be after the request being sent and the client/ESB
waits for the response over a different channel.
Is there any possibility of attaching the synapse configuration that you
are using? In which case I can have a look at the synapse.xml and find
any issues in the configuration.
You do not need to increase the socket.timeout if you are using separate
channel to receive the response.
Thanks,
Ruwan
Hi Asanka,
Thanks for the quick reply.
I should have given more details on our client settings but, it
is
currently configured to receive responses on a separate
transport
channel (asynchronous) and it has WS-addressing enabled
(WS-addressing
is enabled in our client, synapse ESB and web service). The
transports
used from client to ESB to web service and back are all regular
http (no
https). Also, there are no firewalls or anything like that along
the way
as we are testing on a test-rig!)
The reason we are looking for a configuration problem within the
ESB is
simply because when the client calls the web service directly,
no
HttpClient connection loss occurs after 60 secs (no matter how
long the
response takes).
Regards,
Diego.
> We are using a Synapse ESB (1.2) to mediate web service calls
to a web
> service. In testing, we have an Axis2 client whose requests
are sent
> to our Synapse ESB which, then forwards the request to the web
> service. The web service itself can take a long time (10mins+)
to send
> a response back. The problem we have is that the client's http
> connection to the ESB is closed after 60 seconds and re-tries
to send
> the request up to four times before giving up.
>
This is the default behavior of the Axis2 client side, which
uses
HttpClient
> If our client sends the request to the web service directly,
the
> client happily waits 10mins+ for a response to come back.
>
Irrespective of the fact that this works or not, I would very
strongly
suggest that waiting on a open socket for a synchronous reply
for 10
minutes+ does not look like a good approach.. what you should
ideally
use is WS-Addressing, and receive the reply on a new channel.
With
http/s and real life situations, an http/s connection does not
live this
long, and many intermediate nodes may disconnect the connection
during
such a long period of inactvity
The information contained in this E-Mail and any subsequent
correspondence is private and is intended solely for the intended
recipient(s). The information in this communication may be
confidential and/or legally privileged. Nothing in this e-mail is
intended to conclude a contract on behalf of QinetiQ or make QinetiQ
subject to any other legally binding commitments, unless the e-mail
contains an express statement to the contrary or incorporates a formal Purchase Order.
For those other than the recipient any disclosure, copying,
distribution, or any action taken or omitted to be taken in reliance
on such information is prohibited and may be unlawful.
Emails and other electronic communication with QinetiQ may be
monitored and recorded for business purposes including security, audit
and archival purposes. Any response to this email indicates consent
to this.
Telephone calls to QinetiQ may be monitored or recorded for quality
control, security and other business purposes.
QinetiQ Limited
Registered in England & Wales: Company Number:3796233
Registered office: 85 Buckingham Gate, London SW1E 6PD, United Kingdom
Trading address: Cody Technology Park, Cody Building, Ively Road, Farnborough, Hampshire, GU14 0LX, United Kingdom
http://www.qinetiq.com/home/notices/legal.html
Re: client http connection to synapse ESB closed four times every 60 seconds
Posted by Ruwan Linton <ru...@gmail.com>.
Hi Diego,
Nice to hear that you got it to work... and thanks for informing us about
that.
Thanks,
Ruwan
On Wed, Oct 22, 2008 at 8:13 PM, Paloschi Diego E <DE...@qinetiq.com>wrote:
> Hi Ruwan,
>
> The problem has now been resolved and, it wasn't a Synapse ESB issue
> after all.
>
> After taking a closer look at the web service itself, I have realized
> that the messageReceiver for the IN_OUT MEP operation was using the
> default RawXMLINOutMessageReceiver class which is synchronous. I have
> changed it to use RawXMLINOutAsyncMessageReceiver class (in Axis version
> 1.3) which is indeed asynchronous.
>
> I was always under the impression that no modifications were necessary
> at the service end if a client wishes to make calls to it
> asynchronously, but this doesn't seem to be the case?
>
> Thanks again for your help and time!
>
> Regards,
>
> Diego.
>
> -----Original Message-----
> From: Ruwan Linton [mailto:ruwan.linton@gmail.com]
> Sent: 22 October 2008 12:46
> To: user@synapse.apache.org
> Subject: Re: client http connection to synapse ESB closed four times
> every 60 seconds
>
> Hi Diego,
>
> Can you inspect the message going from synapse to the web service using
> a TCPMon tool and attach the request being sent to the service and what
> you see on the back channel. Ideally you should be seeing a 202 Accepted
> from service to synapse.
>
> Thanks,
> Ruwan
>
> On Wed, Oct 22, 2008 at 4:23 PM, Paloschi Diego E
> <DE...@qinetiq.com>wrote:
>
> > Hi Ruwan,
> >
> > With regards to my initial post, I have realised that our client was
> > not including setUseSeparateListener(true) as one of its Options
> properly.
> > This has now been included and, the client now truly uses separate
> > channel for request/response.
> >
> > Having fixed that, we still have problems within the ESB. i.e:
> >
> > The client sends request to ESB and receives back a 202 accepted
> > response. But, we also get a 'TransportUtils - Did not find
> > RequestResponseTransport cannot set response written' debug message
> (?).
> >
> > The ESB receives the request from the client and forwards it to the
> > service. But, after a minute exactly, the ESB gets a 'ERROR_CODE =
> > 00000, ERROR_MESSAGE = Connection timeout' log message.
> >
> > So, when the service actually sends the response back to the ESB, the
> > ESB logs a message 'ERROR AxisEngine The endpoint reference (EPR) for
> > the Operation not found is http:...'
> >
> > Below is the synapse.xml used:
> >
> > <definitions xmlns="http://ws.apache.org/ns/synapse">
> >
> > <log level="full"/>
> >
> > <sequence name="alt_endpoint">
> > <send>
> > <endpoint>
> > <address
> > uri="http://localhost:8081/ws-wp82/services/WP82Service"
> > optimize="mtom">
> > <enableAddressing
> > separateListener="true"/>
> > </address>
> > </endpoint>
> > </send>
> > </sequence>
> >
> > <in>
> > <!-- establish which web service we are calling -->
> > <switch source="get-property('To')">
> > <case regex=".*WP82Service.*">
> > <!-- add a SOAP header to preserve the
> > SOAP request's original 'To' -->
> > <header name="esb:orig-to"
> > value="http://192.168.16:8081/ws-wp82/services/WP82Service"
> > xmlns:prime="http://esb.qinetiq.com"/>
> >
> > <sequence key="alt_endpoint"/>
> > </case>
> > </switch>
> > <drop/>
> > </in>
> >
> > <out>
> > <property name="enableMTOM" value="true"
> scope="axis2"/>
> > <send/>
> > </out>
> > </definitions >
> >
> > Thanx for any pointers on this.
> >
> > Regards,
> >
> > Diego.
> >
> >
> > Assuming that you are using the asynchronous communication over http
> > using WS-Addressing in between client and ESB as well as ESB and web
> > service there should not be any timeouts, because the back channel of
> > the http request will be after the request being sent and the
> > client/ESB waits for the response over a different channel.
> >
> > Is there any possibility of attaching the synapse configuration that
> > you are using? In which case I can have a look at the synapse.xml and
> > find any issues in the configuration.
> >
> > You do not need to increase the socket.timeout if you are using
> > separate channel to receive the response.
> >
> > Thanks,
> > Ruwan
> >
> >
> >
> > Hi Asanka,
> >
> > Thanks for the quick reply.
> >
> > I should have given more details on our client settings but, it
>
> > is
> > currently configured to receive responses on a separate
> > transport
> > channel (asynchronous) and it has WS-addressing enabled
> > (WS-addressing
> > is enabled in our client, synapse ESB and web service). The
> > transports
> > used from client to ESB to web service and back are all regular
>
> > http (no
> > https). Also, there are no firewalls or anything like that
> > along the way
> > as we are testing on a test-rig!)
> >
> > The reason we are looking for a configuration problem within
> > the ESB is
> > simply because when the client calls the web service directly,
> > no
> > HttpClient connection loss occurs after 60 secs (no matter how
> > long the
> > response takes).
> >
> > Regards,
> >
> > Diego.
> >
> >
> > > We are using a Synapse ESB (1.2) to mediate web service calls
>
> > to a web
> >
> > > service. In testing, we have an Axis2 client whose requests
> > are sent
> > > to our Synapse ESB which, then forwards the request to the
> web
> > > service. The web service itself can take a long time
> > (10mins+) to send
> >
> > > a response back. The problem we have is that the client's
> http
> > > connection to the ESB is closed after 60 seconds and re-tries
>
> > to send
> > > the request up to four times before giving up.
> > >
> > This is the default behavior of the Axis2 client side, which
> > uses
> > HttpClient
> > > If our client sends the request to the web service directly,
> > the
> > > client happily waits 10mins+ for a response to come back.
> > >
> > Irrespective of the fact that this works or not, I would very
> > strongly
> > suggest that waiting on a open socket for a synchronous reply
> > for 10
> > minutes+ does not look like a good approach.. what you should
> > ideally
> > use is WS-Addressing, and receive the reply on a new channel.
> > With
> > http/s and real life situations, an http/s connection does not
> > live this
> > long, and many intermediate nodes may disconnect the connection
>
> > during
> > such a long period of inactvity
> >
> > The information contained in this E-Mail and any subsequent
> > correspondence is private and is intended solely for the intended
> > recipient(s). The information in this communication may be
> > confidential and/or legally privileged. Nothing in this e-mail is
> > intended to conclude a contract on behalf of QinetiQ or make QinetiQ
> > subject to any other legally binding commitments, unless the e-mail
> > contains an express statement to the contrary or incorporates a formal
>
> > Purchase Order.
> >
> > For those other than the recipient any disclosure, copying,
> > distribution, or any action taken or omitted to be taken in reliance
> > on such information is prohibited and may be unlawful.
> >
> > Emails and other electronic communication with QinetiQ may be
> > monitored and recorded for business purposes including security, audit
>
> > and archival purposes. Any response to this email indicates consent
> > to this.
> >
> > Telephone calls to QinetiQ may be monitored or recorded for quality
> > control, security and other business purposes.
> >
> > QinetiQ Limited
> > Registered in England & Wales: Company Number:3796233 Registered
> > office: 85 Buckingham Gate, London SW1E 6PD, United Kingdom Trading
> > address: Cody Technology Park, Cody Building, Ively Road, Farnborough,
>
> > Hampshire, GU14 0LX, United Kingdom
> > http://www.qinetiq.com/home/notices/legal.html
> >
>
>
>
> --
> Ruwan Linton
> http://wso2.org - "Oxygenating the Web Services Platform"
> http://ruwansblog.blogspot.com/
> The QinetiQ e-mail privacy policy and company information is detailed
> elsewhere in the body of this email.
>
--
Ruwan Linton
http://wso2.org - "Oxygenating the Web Services Platform"
http://ruwansblog.blogspot.com/
RE: client http connection to synapse ESB closed four times
every 60 seconds
Posted by Paloschi Diego E <DE...@qinetiq.com>.
Hi Ruwan,
The problem has now been resolved and, it wasn't a Synapse ESB issue
after all.
After taking a closer look at the web service itself, I have realized
that the messageReceiver for the IN_OUT MEP operation was using the
default RawXMLINOutMessageReceiver class which is synchronous. I have
changed it to use RawXMLINOutAsyncMessageReceiver class (in Axis version
1.3) which is indeed asynchronous.
I was always under the impression that no modifications were necessary
at the service end if a client wishes to make calls to it
asynchronously, but this doesn't seem to be the case?
Thanks again for your help and time!
Regards,
Diego.
-----Original Message-----
From: Ruwan Linton [mailto:ruwan.linton@gmail.com]
Sent: 22 October 2008 12:46
To: user@synapse.apache.org
Subject: Re: client http connection to synapse ESB closed four times
every 60 seconds
Hi Diego,
Can you inspect the message going from synapse to the web service using
a TCPMon tool and attach the request being sent to the service and what
you see on the back channel. Ideally you should be seeing a 202 Accepted
from service to synapse.
Thanks,
Ruwan
On Wed, Oct 22, 2008 at 4:23 PM, Paloschi Diego E
<DE...@qinetiq.com>wrote:
> Hi Ruwan,
>
> With regards to my initial post, I have realised that our client was
> not including setUseSeparateListener(true) as one of its Options
properly.
> This has now been included and, the client now truly uses separate
> channel for request/response.
>
> Having fixed that, we still have problems within the ESB. i.e:
>
> The client sends request to ESB and receives back a 202 accepted
> response. But, we also get a 'TransportUtils - Did not find
> RequestResponseTransport cannot set response written' debug message
(?).
>
> The ESB receives the request from the client and forwards it to the
> service. But, after a minute exactly, the ESB gets a 'ERROR_CODE =
> 00000, ERROR_MESSAGE = Connection timeout' log message.
>
> So, when the service actually sends the response back to the ESB, the
> ESB logs a message 'ERROR AxisEngine The endpoint reference (EPR) for
> the Operation not found is http:...'
>
> Below is the synapse.xml used:
>
> <definitions xmlns="http://ws.apache.org/ns/synapse">
>
> <log level="full"/>
>
> <sequence name="alt_endpoint">
> <send>
> <endpoint>
> <address
> uri="http://localhost:8081/ws-wp82/services/WP82Service"
> optimize="mtom">
> <enableAddressing
> separateListener="true"/>
> </address>
> </endpoint>
> </send>
> </sequence>
>
> <in>
> <!-- establish which web service we are calling -->
> <switch source="get-property('To')">
> <case regex=".*WP82Service.*">
> <!-- add a SOAP header to preserve the
> SOAP request's original 'To' -->
> <header name="esb:orig-to"
> value="http://192.168.16:8081/ws-wp82/services/WP82Service"
> xmlns:prime="http://esb.qinetiq.com"/>
>
> <sequence key="alt_endpoint"/>
> </case>
> </switch>
> <drop/>
> </in>
>
> <out>
> <property name="enableMTOM" value="true"
scope="axis2"/>
> <send/>
> </out>
> </definitions >
>
> Thanx for any pointers on this.
>
> Regards,
>
> Diego.
>
>
> Assuming that you are using the asynchronous communication over http
> using WS-Addressing in between client and ESB as well as ESB and web
> service there should not be any timeouts, because the back channel of
> the http request will be after the request being sent and the
> client/ESB waits for the response over a different channel.
>
> Is there any possibility of attaching the synapse configuration that
> you are using? In which case I can have a look at the synapse.xml and
> find any issues in the configuration.
>
> You do not need to increase the socket.timeout if you are using
> separate channel to receive the response.
>
> Thanks,
> Ruwan
>
>
>
> Hi Asanka,
>
> Thanks for the quick reply.
>
> I should have given more details on our client settings but, it
> is
> currently configured to receive responses on a separate
> transport
> channel (asynchronous) and it has WS-addressing enabled
> (WS-addressing
> is enabled in our client, synapse ESB and web service). The
> transports
> used from client to ESB to web service and back are all regular
> http (no
> https). Also, there are no firewalls or anything like that
> along the way
> as we are testing on a test-rig!)
>
> The reason we are looking for a configuration problem within
> the ESB is
> simply because when the client calls the web service directly,
> no
> HttpClient connection loss occurs after 60 secs (no matter how
> long the
> response takes).
>
> Regards,
>
> Diego.
>
>
> > We are using a Synapse ESB (1.2) to mediate web service calls
> to a web
>
> > service. In testing, we have an Axis2 client whose requests
> are sent
> > to our Synapse ESB which, then forwards the request to the
web
> > service. The web service itself can take a long time
> (10mins+) to send
>
> > a response back. The problem we have is that the client's
http
> > connection to the ESB is closed after 60 seconds and re-tries
> to send
> > the request up to four times before giving up.
> >
> This is the default behavior of the Axis2 client side, which
> uses
> HttpClient
> > If our client sends the request to the web service directly,
> the
> > client happily waits 10mins+ for a response to come back.
> >
> Irrespective of the fact that this works or not, I would very
> strongly
> suggest that waiting on a open socket for a synchronous reply
> for 10
> minutes+ does not look like a good approach.. what you should
> ideally
> use is WS-Addressing, and receive the reply on a new channel.
> With
> http/s and real life situations, an http/s connection does not
> live this
> long, and many intermediate nodes may disconnect the connection
> during
> such a long period of inactvity
>
> The information contained in this E-Mail and any subsequent
> correspondence is private and is intended solely for the intended
> recipient(s). The information in this communication may be
> confidential and/or legally privileged. Nothing in this e-mail is
> intended to conclude a contract on behalf of QinetiQ or make QinetiQ
> subject to any other legally binding commitments, unless the e-mail
> contains an express statement to the contrary or incorporates a formal
> Purchase Order.
>
> For those other than the recipient any disclosure, copying,
> distribution, or any action taken or omitted to be taken in reliance
> on such information is prohibited and may be unlawful.
>
> Emails and other electronic communication with QinetiQ may be
> monitored and recorded for business purposes including security, audit
> and archival purposes. Any response to this email indicates consent
> to this.
>
> Telephone calls to QinetiQ may be monitored or recorded for quality
> control, security and other business purposes.
>
> QinetiQ Limited
> Registered in England & Wales: Company Number:3796233 Registered
> office: 85 Buckingham Gate, London SW1E 6PD, United Kingdom Trading
> address: Cody Technology Park, Cody Building, Ively Road, Farnborough,
> Hampshire, GU14 0LX, United Kingdom
> http://www.qinetiq.com/home/notices/legal.html
>
--
Ruwan Linton
http://wso2.org - "Oxygenating the Web Services Platform"
http://ruwansblog.blogspot.com/
The QinetiQ e-mail privacy policy and company information is detailed elsewhere in the body of this email.
Re: client http connection to synapse ESB closed four times every 60 seconds
Posted by Ruwan Linton <ru...@gmail.com>.
Hi Diego,
Can you inspect the message going from synapse to the web service using a
TCPMon tool and attach the request being sent to the service and what you
see on the back channel. Ideally you should be seeing a 202 Accepted from
service to synapse.
Thanks,
Ruwan
On Wed, Oct 22, 2008 at 4:23 PM, Paloschi Diego E <DE...@qinetiq.com>wrote:
> Hi Ruwan,
>
> With regards to my initial post, I have realised that our client was not
> including setUseSeparateListener(true) as one of its Options properly.
> This has now been included and, the client now truly uses separate
> channel for request/response.
>
> Having fixed that, we still have problems within the ESB. i.e:
>
> The client sends request to ESB and receives back a 202 accepted
> response. But, we also get a 'TransportUtils - Did not find
> RequestResponseTransport cannot set response written' debug message (?).
>
> The ESB receives the request from the client and forwards it to the
> service. But, after a minute exactly, the ESB gets a 'ERROR_CODE =
> 00000, ERROR_MESSAGE = Connection timeout' log message.
>
> So, when the service actually sends the response back to the ESB, the
> ESB logs a message 'ERROR AxisEngine The endpoint reference (EPR) for
> the Operation not found is http:...'
>
> Below is the synapse.xml used:
>
> <definitions xmlns="http://ws.apache.org/ns/synapse">
>
> <log level="full"/>
>
> <sequence name="alt_endpoint">
> <send>
> <endpoint>
> <address
> uri="http://localhost:8081/ws-wp82/services/WP82Service"
> optimize="mtom">
> <enableAddressing
> separateListener="true"/>
> </address>
> </endpoint>
> </send>
> </sequence>
>
> <in>
> <!-- establish which web service we are calling -->
> <switch source="get-property('To')">
> <case regex=".*WP82Service.*">
> <!-- add a SOAP header to preserve the
> SOAP request's original 'To' -->
> <header name="esb:orig-to"
> value="http://192.168.16:8081/ws-wp82/services/WP82Service"
> xmlns:prime="http://esb.qinetiq.com"/>
>
> <sequence key="alt_endpoint"/>
> </case>
> </switch>
> <drop/>
> </in>
>
> <out>
> <property name="enableMTOM" value="true" scope="axis2"/>
> <send/>
> </out>
> </definitions >
>
> Thanx for any pointers on this.
>
> Regards,
>
> Diego.
>
>
> Assuming that you are using the asynchronous communication over http
> using WS-Addressing in between client and ESB as well as ESB and web
> service there should not be any timeouts, because the back channel of
> the http request will be after the request being sent and the client/ESB
> waits for the response over a different channel.
>
> Is there any possibility of attaching the synapse configuration that you
> are using? In which case I can have a look at the synapse.xml and find
> any issues in the configuration.
>
> You do not need to increase the socket.timeout if you are using separate
> channel to receive the response.
>
> Thanks,
> Ruwan
>
>
>
> Hi Asanka,
>
> Thanks for the quick reply.
>
> I should have given more details on our client settings but, it
> is
> currently configured to receive responses on a separate
> transport
> channel (asynchronous) and it has WS-addressing enabled
> (WS-addressing
> is enabled in our client, synapse ESB and web service). The
> transports
> used from client to ESB to web service and back are all regular
> http (no
> https). Also, there are no firewalls or anything like that along
> the way
> as we are testing on a test-rig!)
>
> The reason we are looking for a configuration problem within the
> ESB is
> simply because when the client calls the web service directly,
> no
> HttpClient connection loss occurs after 60 secs (no matter how
> long the
> response takes).
>
> Regards,
>
> Diego.
>
>
> > We are using a Synapse ESB (1.2) to mediate web service calls
> to a web
>
> > service. In testing, we have an Axis2 client whose requests
> are sent
> > to our Synapse ESB which, then forwards the request to the web
> > service. The web service itself can take a long time (10mins+)
> to send
>
> > a response back. The problem we have is that the client's http
> > connection to the ESB is closed after 60 seconds and re-tries
> to send
> > the request up to four times before giving up.
> >
> This is the default behavior of the Axis2 client side, which
> uses
> HttpClient
> > If our client sends the request to the web service directly,
> the
> > client happily waits 10mins+ for a response to come back.
> >
> Irrespective of the fact that this works or not, I would very
> strongly
> suggest that waiting on a open socket for a synchronous reply
> for 10
> minutes+ does not look like a good approach.. what you should
> ideally
> use is WS-Addressing, and receive the reply on a new channel.
> With
> http/s and real life situations, an http/s connection does not
> live this
> long, and many intermediate nodes may disconnect the connection
> during
> such a long period of inactvity
>
> The information contained in this E-Mail and any subsequent
> correspondence is private and is intended solely for the intended
> recipient(s). The information in this communication may be
> confidential and/or legally privileged. Nothing in this e-mail is
> intended to conclude a contract on behalf of QinetiQ or make QinetiQ
> subject to any other legally binding commitments, unless the e-mail
> contains an express statement to the contrary or incorporates a formal
> Purchase Order.
>
> For those other than the recipient any disclosure, copying,
> distribution, or any action taken or omitted to be taken in reliance
> on such information is prohibited and may be unlawful.
>
> Emails and other electronic communication with QinetiQ may be
> monitored and recorded for business purposes including security, audit
> and archival purposes. Any response to this email indicates consent
> to this.
>
> Telephone calls to QinetiQ may be monitored or recorded for quality
> control, security and other business purposes.
>
> QinetiQ Limited
> Registered in England & Wales: Company Number:3796233
> Registered office: 85 Buckingham Gate, London SW1E 6PD, United Kingdom
> Trading address: Cody Technology Park, Cody Building, Ively Road,
> Farnborough, Hampshire, GU14 0LX, United Kingdom
> http://www.qinetiq.com/home/notices/legal.html
>
--
Ruwan Linton
http://wso2.org - "Oxygenating the Web Services Platform"
http://ruwansblog.blogspot.com/
Re: client http connection to synapse ESB closed four times every 60 seconds
Posted by Ruwan Linton <ru...@gmail.com>.
Hi Diego,
Assuming that you are using the asynchronous communication over http using
WS-Addressing in between client and ESB as well as ESB and web service there
should not be any timeouts, because the back channel of the http request
will be after the request being sent and the client/ESB waits for the
response over a different channel.
Is there any possibility of attaching the synapse configuration that you are
using? In which case I can have a look at the synapse.xml and find any
issues in the configuration.
You do not need to increase the socket.timeout if you are using separate
channel to receive the response.
Thanks,
Ruwan
On Wed, Oct 22, 2008 at 12:11 AM, Paloschi Diego E
<DE...@qinetiq.com>wrote:
> Hi Asanka,
>
> Thanks for the quick reply.
>
> I should have given more details on our client settings but, it is
> currently configured to receive responses on a separate transport
> channel (asynchronous) and it has WS-addressing enabled (WS-addressing
> is enabled in our client, synapse ESB and web service). The transports
> used from client to ESB to web service and back are all regular http (no
> https). Also, there are no firewalls or anything like that along the way
> as we are testing on a test-rig!)
>
> The reason we are looking for a configuration problem within the ESB is
> simply because when the client calls the web service directly, no
> HttpClient connection loss occurs after 60 secs (no matter how long the
> response takes).
>
> Regards,
>
> Diego.
>
> > We are using a Synapse ESB (1.2) to mediate web service calls to a web
>
> > service. In testing, we have an Axis2 client whose requests are sent
> > to our Synapse ESB which, then forwards the request to the web
> > service. The web service itself can take a long time (10mins+) to send
>
> > a response back. The problem we have is that the client's http
> > connection to the ESB is closed after 60 seconds and re-tries to send
> > the request up to four times before giving up.
> >
> This is the default behavior of the Axis2 client side, which uses
> HttpClient
> > If our client sends the request to the web service directly, the
> > client happily waits 10mins+ for a response to come back.
> >
> Irrespective of the fact that this works or not, I would very strongly
> suggest that waiting on a open socket for a synchronous reply for 10
> minutes+ does not look like a good approach.. what you should ideally
> use is WS-Addressing, and receive the reply on a new channel. With
> http/s and real life situations, an http/s connection does not live this
> long, and many intermediate nodes may disconnect the connection during
> such a long period of inactvity
> The information contained in this E-Mail and any subsequent
> correspondence is private and is intended solely for the intended
> recipient(s). The information in this communication may be
> confidential and/or legally privileged. Nothing in this e-mail is
> intended to conclude a contract on behalf of QinetiQ or make QinetiQ
> subject to any other legally binding commitments, unless the e-mail
> contains an express statement to the contrary or incorporates a formal
> Purchase Order.
>
> For those other than the recipient any disclosure, copying,
> distribution, or any action taken or omitted to be taken in reliance
> on such information is prohibited and may be unlawful.
>
> Emails and other electronic communication with QinetiQ may be
> monitored and recorded for business purposes including security, audit
> and archival purposes. Any response to this email indicates consent
> to this.
>
> Telephone calls to QinetiQ may be monitored or recorded for quality
> control, security and other business purposes.
>
> QinetiQ Limited
> Registered in England & Wales: Company Number:3796233
> Registered office: 85 Buckingham Gate, London SW1E 6PD, United Kingdom
> Trading address: Cody Technology Park, Cody Building, Ively Road,
> Farnborough, Hampshire, GU14 0LX, United Kingdom
> http://www.qinetiq.com/home/notices/legal.html
>
--
Ruwan Linton
http://wso2.org - "Oxygenating the Web Services Platform"
http://ruwansblog.blogspot.com/