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<[email protected]> 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

Reply via email to