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 <[EMAIL PROTECTED]>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/

Reply via email to