You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-user@axis.apache.org by Torben Riis <ri...@multi-support.com> on 2009/06/30 15:01:24 UTC
Async service retrieving MTOM message -> Socket closed
Hi,
I'm struggling with an Axis2 client sending a MTOM message to an Axis2 service. The service returns a socket closed exception.
The client uses separate listeners (addressing) and sends a soap message containing several MTOM attachments.
The client and service works perfectly if MTOM is disabled and uses the fallback to Base64 encoded content or if just anonymous addressing is used instead (no asynchronous).
The service is configured with a "RawXMLINOutMessageReceiver" message receiver and the parameter "messageReceiver.invokeOnSeparateThread" set to true.
During debugging I noticed that the problem only occurred when the service returns with the HTTP status coded 202 before the business logic has called getDataHandler() on OMText element.
For my implementation the socket closed exception first happens for the second or third attachment, but this can variate a lot.
If I set a breakpoint in AbstractMessageReceiver#receive() where AsyncMessageReceiverWorker is created as a new thread and ensures that the business logic is invoked before AbstractMessageReceiver#receive() returns with http status coded 202 everything works as designed. I noticed as well that messageCtx.getEnvelope().build() in the same method detects that the message context contains all 3 MTOM attachments correctly.
AbstractMessageReceiver#receive()
...
if ((!WSDLUtil.isOutputPresentForMEP(mep))
|| (replyTo != null && !replyTo.hasAnonymousAddress())) {
AsyncMessageReceiverWorker worker = new AsyncMessageReceiverWorker(
messageCtx);
messageCtx.getEnvelope().build();
messageCtx.getConfigurationContext().getThreadPool().execute(
worker);
return;
}
And the funny part here is, that it seems to work on Jetty but not on Tomcat 5.5, Tomcat 6 or Websphere 6.1.
As I see it, the reason why the socket closed exceptions occurs, is due to that some servers closes the connection when the service returns with status 202.
But I'm not 100% sure.
Any help would be appreciated, a lot. :)
Regards
Multi-Support R&D A/S
Torben Riis
http://www.multi-support.com
http://www.linkedin.com/in/mrtorbenriis
SV: Async service retrieving MTOM message -> Socket closed
Posted by Torben Riis <ri...@multi-support.com>.
Hi,
I see it the exact same way. I'll create a local patch for our self that works for asynchronous MTOM requests only.
Do you have any smart suggestions for preventing the call to TransportUtils#deleteAttachments(MessageContext) from AxisServlet?
For my situation it would be nice if I only had to change the message receiver, I could for instance override the receive method and execute my own implementation of an asynchronous worker that calls TransportUtils#deleteAttachments() right after the business logic is invoked...
Should I open a new JIRA?
I'll unfortunately be offline the next 3 weeks (vacation), so I'll not be able create the JIRA right away.
/Torben
-----Oprindelig meddelelse-----
Fra: Andreas Veithen [mailto:andreas.veithen@gmail.com]
Sendt: 1. juli 2009 21:57
Til: axis-user@ws.apache.org
Emne: Re: Async service retrieving MTOM message -> Socket closed
I think there are several problems in the Axis2 architecture here:
- Calling just build() and not buildWithAttachments() is definitely a
bug. However, even buildWithAttachments() is not enough, because it
would work for MTOM, but not for SwA (in MTOM, attachments are always
linked to OMText nodes in the tree, but this is not the case for SwA).
- AxisServlet calls TransportUtils#deleteAttachments(MessageContext)
after the request has been injected into the Axis engine. This is
incorrect if the engine processes the request asynchronously in a
different thread (that is one of the problems you experience). On the
other hand, it seems to be the only transport implementation using
that method, meaning that other transports will not free the temporary
files (in a timely manner).
- LifeCycleManager is too tightly coupled to attachments. This is not
relevant for your problem, but we will run into that issue once we
implement the planned improvements to the message builder/formatter
framework. E.g. if we want to support binary/octet-stream, then we
should also be able to offload large payloads to a temporary file.
Since these are not attachments, LifeCycleManager and
TransportUtils#deleteAttachments(MessageContext) is of no use here.
Probably this will not be fixed in the near future.
Andreas
On Wed, Jul 1, 2009 at 07:21, Torben Riis<ri...@multi-support.com> wrote:
>
> Hi,
>
> It helped a lot now the attachments are fully downloaded before the service returns with the http status code 202.
> But unfortunately if file caching is enabled, buildWithAttachments() also adds the attachments to the LifeCycleManager (deleteOnExit) and that triggers a delete when the service returns. And the attachments will therefore be gone before the business logic is invoked...
>
> But for attachments stored in memory it works perfect.
>
> I'm wondering, wouldn't it be more correct if AbstractMessageReceiver#receive() in general invoked buildWithAttachments() instead of just build() in the part that handles asynchronous requests, in my opinion it doesn't make sense to return before the service has retrieved the whole http message...
>
> Or will the performance penalty be too high???
>
> Torben Riis
>
> -----Oprindelig meddelelse-----
> Fra: Andreas Veithen [mailto:andreas.veithen@gmail.com]
> Sendt: 30. juni 2009 19:35
> Til: axis-user@ws.apache.org
> Emne: Re: Async service retrieving MTOM message -> Socket closed
>
>
> I think the problem is that messageCtx.getEnvelope().build() is not
> enough in this case. It makes sure that the message has been entirely
> parsed, but not the attachments. Can you replace build() by
> buildWithAttachments() and retry this?
>
> Andreas
>
> On Tue, Jun 30, 2009 at 15:01, Torben Riis<ri...@multi-support.com> wrote:
>> Hi,
>>
>>
>>
>> I'm struggling with an Axis2 client sending a MTOM message to an Axis2
>> service. The service returns a socket closed exception.
>>
>> The client uses separate listeners (addressing) and sends a soap message
>> containing several MTOM attachments.
>>
>>
>>
>> The client and service works perfectly if MTOM is disabled and uses the
>> fallback to Base64 encoded content or if just anonymous addressing is used
>> instead (no asynchronous).
>>
>>
>>
>> The service is configured with a "RawXMLINOutMessageReceiver" message
>> receiver and the parameter "messageReceiver.invokeOnSeparateThread" set to
>> true.
>>
>>
>>
>> During debugging I noticed that the problem only occurred when the service
>> returns with the HTTP status coded 202 before the business logic has called
>> getDataHandler() on OMText element.
>>
>> For my implementation the socket closed exception first happens for the
>> second or third attachment, but this can variate a lot.
>>
>> If I set a breakpoint in AbstractMessageReceiver#receive() where
>> AsyncMessageReceiverWorker is created as a new thread and ensures that the
>> business logic is invoked before AbstractMessageReceiver#receive() returns
>> with http status coded 202 everything works as designed. I noticed as well
>> that messageCtx.getEnvelope().build() in the same method detects that the
>> message context contains all 3 MTOM attachments correctly.
>>
>>
>>
>> AbstractMessageReceiver#receive()
>>
>> .
>>
>> if ((!WSDLUtil.isOutputPresentForMEP(mep))
>>
>> || (replyTo != null && !replyTo.hasAnonymousAddress())) {
>>
>> AsyncMessageReceiverWorker worker = new AsyncMessageReceiverWorker(
>>
>> messageCtx);
>>
>> messageCtx.getEnvelope().build();
>>
>> messageCtx.getConfigurationContext().getThreadPool().execute(
>>
>> worker);
>>
>> return;
>>
>> }
>>
>>
>>
>> And the funny part here is, that it seems to work on Jetty but not on Tomcat
>> 5.5, Tomcat 6 or Websphere 6.1.
>>
>>
>>
>> As I see it, the reason why the socket closed exceptions occurs, is due to
>> that some servers closes the connection when the service returns with status
>> 202.
>>
>> But I'm not 100% sure.
>>
>>
>>
>> Any help would be appreciated, a lot. J
>>
>>
>>
>> Regards
>>
>> Multi-Support R&D A/S
>>
>>
>>
>> Torben Riis
>>
>> http://www.multi-support.com
>>
>> http://www.linkedin.com/in/mrtorbenriis
>
Re: Async service retrieving MTOM message -> Socket closed
Posted by Andreas Veithen <an...@gmail.com>.
I think there are several problems in the Axis2 architecture here:
- Calling just build() and not buildWithAttachments() is definitely a
bug. However, even buildWithAttachments() is not enough, because it
would work for MTOM, but not for SwA (in MTOM, attachments are always
linked to OMText nodes in the tree, but this is not the case for SwA).
- AxisServlet calls TransportUtils#deleteAttachments(MessageContext)
after the request has been injected into the Axis engine. This is
incorrect if the engine processes the request asynchronously in a
different thread (that is one of the problems you experience). On the
other hand, it seems to be the only transport implementation using
that method, meaning that other transports will not free the temporary
files (in a timely manner).
- LifeCycleManager is too tightly coupled to attachments. This is not
relevant for your problem, but we will run into that issue once we
implement the planned improvements to the message builder/formatter
framework. E.g. if we want to support binary/octet-stream, then we
should also be able to offload large payloads to a temporary file.
Since these are not attachments, LifeCycleManager and
TransportUtils#deleteAttachments(MessageContext) is of no use here.
Probably this will not be fixed in the near future.
Andreas
On Wed, Jul 1, 2009 at 07:21, Torben Riis<ri...@multi-support.com> wrote:
>
> Hi,
>
> It helped a lot now the attachments are fully downloaded before the service returns with the http status code 202.
> But unfortunately if file caching is enabled, buildWithAttachments() also adds the attachments to the LifeCycleManager (deleteOnExit) and that triggers a delete when the service returns. And the attachments will therefore be gone before the business logic is invoked...
>
> But for attachments stored in memory it works perfect.
>
> I'm wondering, wouldn't it be more correct if AbstractMessageReceiver#receive() in general invoked buildWithAttachments() instead of just build() in the part that handles asynchronous requests, in my opinion it doesn't make sense to return before the service has retrieved the whole http message...
>
> Or will the performance penalty be too high???
>
> Torben Riis
>
> -----Oprindelig meddelelse-----
> Fra: Andreas Veithen [mailto:andreas.veithen@gmail.com]
> Sendt: 30. juni 2009 19:35
> Til: axis-user@ws.apache.org
> Emne: Re: Async service retrieving MTOM message -> Socket closed
>
>
> I think the problem is that messageCtx.getEnvelope().build() is not
> enough in this case. It makes sure that the message has been entirely
> parsed, but not the attachments. Can you replace build() by
> buildWithAttachments() and retry this?
>
> Andreas
>
> On Tue, Jun 30, 2009 at 15:01, Torben Riis<ri...@multi-support.com> wrote:
>> Hi,
>>
>>
>>
>> I'm struggling with an Axis2 client sending a MTOM message to an Axis2
>> service. The service returns a socket closed exception.
>>
>> The client uses separate listeners (addressing) and sends a soap message
>> containing several MTOM attachments.
>>
>>
>>
>> The client and service works perfectly if MTOM is disabled and uses the
>> fallback to Base64 encoded content or if just anonymous addressing is used
>> instead (no asynchronous).
>>
>>
>>
>> The service is configured with a "RawXMLINOutMessageReceiver" message
>> receiver and the parameter "messageReceiver.invokeOnSeparateThread" set to
>> true.
>>
>>
>>
>> During debugging I noticed that the problem only occurred when the service
>> returns with the HTTP status coded 202 before the business logic has called
>> getDataHandler() on OMText element.
>>
>> For my implementation the socket closed exception first happens for the
>> second or third attachment, but this can variate a lot.
>>
>> If I set a breakpoint in AbstractMessageReceiver#receive() where
>> AsyncMessageReceiverWorker is created as a new thread and ensures that the
>> business logic is invoked before AbstractMessageReceiver#receive() returns
>> with http status coded 202 everything works as designed. I noticed as well
>> that messageCtx.getEnvelope().build() in the same method detects that the
>> message context contains all 3 MTOM attachments correctly.
>>
>>
>>
>> AbstractMessageReceiver#receive()
>>
>> .
>>
>> if ((!WSDLUtil.isOutputPresentForMEP(mep))
>>
>> || (replyTo != null && !replyTo.hasAnonymousAddress())) {
>>
>> AsyncMessageReceiverWorker worker = new AsyncMessageReceiverWorker(
>>
>> messageCtx);
>>
>> messageCtx.getEnvelope().build();
>>
>> messageCtx.getConfigurationContext().getThreadPool().execute(
>>
>> worker);
>>
>> return;
>>
>> }
>>
>>
>>
>> And the funny part here is, that it seems to work on Jetty but not on Tomcat
>> 5.5, Tomcat 6 or Websphere 6.1.
>>
>>
>>
>> As I see it, the reason why the socket closed exceptions occurs, is due to
>> that some servers closes the connection when the service returns with status
>> 202.
>>
>> But I'm not 100% sure.
>>
>>
>>
>> Any help would be appreciated, a lot. J
>>
>>
>>
>> Regards
>>
>> Multi-Support R&D A/S
>>
>>
>>
>> Torben Riis
>>
>> http://www.multi-support.com
>>
>> http://www.linkedin.com/in/mrtorbenriis
>
SV: Async service retrieving MTOM message -> Socket closed
Posted by Torben Riis <ri...@multi-support.com>.
Hi,
It helped a lot now the attachments are fully downloaded before the service returns with the http status code 202.
But unfortunately if file caching is enabled, buildWithAttachments() also adds the attachments to the LifeCycleManager (deleteOnExit) and that triggers a delete when the service returns. And the attachments will therefore be gone before the business logic is invoked...
But for attachments stored in memory it works perfect.
I'm wondering, wouldn't it be more correct if AbstractMessageReceiver#receive() in general invoked buildWithAttachments() instead of just build() in the part that handles asynchronous requests, in my opinion it doesn't make sense to return before the service has retrieved the whole http message...
Or will the performance penalty be too high???
Torben Riis
-----Oprindelig meddelelse-----
Fra: Andreas Veithen [mailto:andreas.veithen@gmail.com]
Sendt: 30. juni 2009 19:35
Til: axis-user@ws.apache.org
Emne: Re: Async service retrieving MTOM message -> Socket closed
I think the problem is that messageCtx.getEnvelope().build() is not
enough in this case. It makes sure that the message has been entirely
parsed, but not the attachments. Can you replace build() by
buildWithAttachments() and retry this?
Andreas
On Tue, Jun 30, 2009 at 15:01, Torben Riis<ri...@multi-support.com> wrote:
> Hi,
>
>
>
> I'm struggling with an Axis2 client sending a MTOM message to an Axis2
> service. The service returns a socket closed exception.
>
> The client uses separate listeners (addressing) and sends a soap message
> containing several MTOM attachments.
>
>
>
> The client and service works perfectly if MTOM is disabled and uses the
> fallback to Base64 encoded content or if just anonymous addressing is used
> instead (no asynchronous).
>
>
>
> The service is configured with a "RawXMLINOutMessageReceiver" message
> receiver and the parameter "messageReceiver.invokeOnSeparateThread" set to
> true.
>
>
>
> During debugging I noticed that the problem only occurred when the service
> returns with the HTTP status coded 202 before the business logic has called
> getDataHandler() on OMText element.
>
> For my implementation the socket closed exception first happens for the
> second or third attachment, but this can variate a lot.
>
> If I set a breakpoint in AbstractMessageReceiver#receive() where
> AsyncMessageReceiverWorker is created as a new thread and ensures that the
> business logic is invoked before AbstractMessageReceiver#receive() returns
> with http status coded 202 everything works as designed. I noticed as well
> that messageCtx.getEnvelope().build() in the same method detects that the
> message context contains all 3 MTOM attachments correctly.
>
>
>
> AbstractMessageReceiver#receive()
>
> .
>
> if ((!WSDLUtil.isOutputPresentForMEP(mep))
>
> || (replyTo != null && !replyTo.hasAnonymousAddress())) {
>
> AsyncMessageReceiverWorker worker = new AsyncMessageReceiverWorker(
>
> messageCtx);
>
> messageCtx.getEnvelope().build();
>
> messageCtx.getConfigurationContext().getThreadPool().execute(
>
> worker);
>
> return;
>
> }
>
>
>
> And the funny part here is, that it seems to work on Jetty but not on Tomcat
> 5.5, Tomcat 6 or Websphere 6.1.
>
>
>
> As I see it, the reason why the socket closed exceptions occurs, is due to
> that some servers closes the connection when the service returns with status
> 202.
>
> But I'm not 100% sure.
>
>
>
> Any help would be appreciated, a lot. J
>
>
>
> Regards
>
> Multi-Support R&D A/S
>
>
>
> Torben Riis
>
> http://www.multi-support.com
>
> http://www.linkedin.com/in/mrtorbenriis
Re: Async service retrieving MTOM message -> Socket closed
Posted by Andreas Veithen <an...@gmail.com>.
I think the problem is that messageCtx.getEnvelope().build() is not
enough in this case. It makes sure that the message has been entirely
parsed, but not the attachments. Can you replace build() by
buildWithAttachments() and retry this?
Andreas
On Tue, Jun 30, 2009 at 15:01, Torben Riis<ri...@multi-support.com> wrote:
> Hi,
>
>
>
> I’m struggling with an Axis2 client sending a MTOM message to an Axis2
> service. The service returns a socket closed exception.
>
> The client uses separate listeners (addressing) and sends a soap message
> containing several MTOM attachments.
>
>
>
> The client and service works perfectly if MTOM is disabled and uses the
> fallback to Base64 encoded content or if just anonymous addressing is used
> instead (no asynchronous).
>
>
>
> The service is configured with a “RawXMLINOutMessageReceiver” message
> receiver and the parameter “messageReceiver.invokeOnSeparateThread” set to
> true.
>
>
>
> During debugging I noticed that the problem only occurred when the service
> returns with the HTTP status coded 202 before the business logic has called
> getDataHandler() on OMText element.
>
> For my implementation the socket closed exception first happens for the
> second or third attachment, but this can variate a lot.
>
> If I set a breakpoint in AbstractMessageReceiver#receive() where
> AsyncMessageReceiverWorker is created as a new thread and ensures that the
> business logic is invoked before AbstractMessageReceiver#receive() returns
> with http status coded 202 everything works as designed. I noticed as well
> that messageCtx.getEnvelope().build() in the same method detects that the
> message context contains all 3 MTOM attachments correctly.
>
>
>
> AbstractMessageReceiver#receive()
>
> …
>
> if ((!WSDLUtil.isOutputPresentForMEP(mep))
>
> || (replyTo != null && !replyTo.hasAnonymousAddress())) {
>
> AsyncMessageReceiverWorker worker = new AsyncMessageReceiverWorker(
>
> messageCtx);
>
> messageCtx.getEnvelope().build();
>
> messageCtx.getConfigurationContext().getThreadPool().execute(
>
> worker);
>
> return;
>
> }
>
>
>
> And the funny part here is, that it seems to work on Jetty but not on Tomcat
> 5.5, Tomcat 6 or Websphere 6.1.
>
>
>
> As I see it, the reason why the socket closed exceptions occurs, is due to
> that some servers closes the connection when the service returns with status
> 202.
>
> But I’m not 100% sure.
>
>
>
> Any help would be appreciated, a lot. J
>
>
>
> Regards
>
> Multi-Support R&D A/S
>
>
>
> Torben Riis
>
> http://www.multi-support.com
>
> http://www.linkedin.com/in/mrtorbenriis
SV: Async service retrieving MTOM message -> Socket closed
Posted by Torben Riis <ri...@multi-support.com>.
I just found that the problem occurs for Jetty as well. I increased the size of the files a bit, and Jetty complains as well.
/Torben Riis
Fra: Torben Riis
Sendt: 30. juni 2009 15:01
Til: axis-user@ws.apache.org
Emne: Async service retrieving MTOM message -> Socket closed
Hi,
I'm struggling with an Axis2 client sending a MTOM message to an Axis2 service. The service returns a socket closed exception.
The client uses separate listeners (addressing) and sends a soap message containing several MTOM attachments.
The client and service works perfectly if MTOM is disabled and uses the fallback to Base64 encoded content or if just anonymous addressing is used instead (no asynchronous).
The service is configured with a "RawXMLINOutMessageReceiver" message receiver and the parameter "messageReceiver.invokeOnSeparateThread" set to true.
During debugging I noticed that the problem only occurred when the service returns with the HTTP status coded 202 before the business logic has called getDataHandler() on OMText element.
For my implementation the socket closed exception first happens for the second or third attachment, but this can variate a lot.
If I set a breakpoint in AbstractMessageReceiver#receive() where AsyncMessageReceiverWorker is created as a new thread and ensures that the business logic is invoked before AbstractMessageReceiver#receive() returns with http status coded 202 everything works as designed. I noticed as well that messageCtx.getEnvelope().build() in the same method detects that the message context contains all 3 MTOM attachments correctly.
AbstractMessageReceiver#receive()
...
if ((!WSDLUtil.isOutputPresentForMEP(mep))
|| (replyTo != null && !replyTo.hasAnonymousAddress())) {
AsyncMessageReceiverWorker worker = new AsyncMessageReceiverWorker(
messageCtx);
messageCtx.getEnvelope().build();
messageCtx.getConfigurationContext().getThreadPool().execute(
worker);
return;
}
And the funny part here is, that it seems to work on Jetty but not on Tomcat 5.5, Tomcat 6 or Websphere 6.1.
As I see it, the reason why the socket closed exceptions occurs, is due to that some servers closes the connection when the service returns with status 202.
But I'm not 100% sure.
Any help would be appreciated, a lot. :)
Regards
Multi-Support R&D A/S
Torben Riis
http://www.multi-support.com
http://www.linkedin.com/in/mrtorbenriis