Hi Ruwan, > So ESB works as expected... :-) Yes! No question. :-)
> > At which location > > do you store the temp file? > > > If you change the log level to DEBUG of package org.apache.synapse in > the log4j.properties file found at $ESB_HOME/webapp/classes/conf > directory, you should be able to see the following debug which specifies > the file > > "Using temporary file $temporaryFile" > > in general it should be under the system temp directory, and a file > starts with tmp_ and having the extension .dat Ah, thanks for the details. > > Well ok, actually there are two issues. One is the blocking behaviour as > > a result of a response with an "unexpected" content and the second issue > > is the one with the interpretation of http 500 responses and getting the > > cause out of it. > > I think there might be always situations were you might encounter an > > HTTP 500 response (no matter if you use SOAP or Hessian). How do you > > currently handle this? What do you think about possible solutions? > > > Well, HTTP 500 Internal Server Error can be handled by the ESB, and the > SOAPFaults are always comes with a HTTP 500 Internal Server Error, with > application/xml as the content type. Here the issue is not the HTTP 500 > message but the content of the message body being HTML. Thanks for clarification. Now I better understand the issue. > Well I will work on this and find a workaround for this within this week. Fine, I'm going to start a wider test scenario on Friday (including different kinds of XFire and Hessian based services). > No matter whether we fix the above issue or not I will guarantee that > ESB wont block for any request, unless there is a serious damage to the > transport reactor ;-) in the coming few days. Definitively, this is the best message of the day. Having fixed this I'm sure I will sleep much better. :-) Regards, Eric _______________________________________________ Esb-java-dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/esb-java-dev
