Hi Eric,
Oh sorry for the confusion. The out of memory was not on the esb side.
It was on the client side and not unexpected at all.
So ESB works as expected... :-)
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
Anyhow here comes the output of tcpdump. It looks like Tomcat (JBoss)
wrappes the HessianProtocolException (special IOException) into an
HTML-error report and responds with an HTTP 500 reply.
I think this is wrong because we do not send an Accept HTTP header the
server should reply with the input content type, since there is no
content type even on a successful hessian response this behavior is not
a surprise ;-) . Or may be we should send an Accept header with
x-application/hessian content type. I will try this out.
Here is the response:
-----------------------------------------------------------------------
HTTP/1.1 500 Internal Server Error
Server: Apache-Coyote/1.1
Content-Type: text/html;charset=utf-8
Content-Length: 2160
Date: Wed, 26 Mar 2008 14:32:20 GMT
Connection: close
<html><head><title>JBossWeb/2.0.0.GA_CP05 - Error
report</title><style><!--H1
{font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D7
6;font-size:22px;} H2
{font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D7
6;font-size:16px;} H3
{font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D7
6;font-size:14px;} BODY
{font-family:Tahoma,Arial,sans-serif;color:black;background-color:white;
} B
{font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D7
6;} P
{font-family:Tahoma,Arial,sans-serif;background:white;color:black;font-s
ize:12px;}A {color : black;}A.name {color : black;}HR {color :
#525D76;}--></style> </head><body><h1>HTTP Status 500 - </h1><HR
size="1" noshade="noshade"><p><b>type</b> Exception
report</p><p><b>message</b> <u></u></p><p><b>description</b> <u>The
server encountered an internal error () that prevented it from
fulfilling this request.</u></p><p><b>exception</b>
<pre>javax.servlet.ServletException:
com.caucho.hessian.io.HessianProtocolException:
findAlbumsNewReleases__6: expected long at 83
com.caucho.hessian.server.HessianServlet.service(HessianServlet.java:373
)
org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilte
r.java:96)
</pre></p><p><b>root cause</b>
<pre>com.caucho.hessian.io.HessianProtocolException:
findAlbumsNewReleases__6: expected long at 83
com.caucho.hessian.io.Hessian2Input.error(Hessian2Input.java:2408)
com.caucho.hessian.io.Hessian2Input.expect(Hessian2Input.java:2402)
com.caucho.hessian.io.Hessian2Input.readLong(Hessian2Input.java:815)
com.caucho.hessian.io.BasicDeserializer.readObject(BasicDeserializer.jav
a:167)
com.caucho.hessian.io.Hessian2Input.readObject(Hessian2Input.java)
com.caucho.hessian.server.HessianSkeleton.invoke(HessianSkeleton.java:15
0)
com.caucho.hessian.server.HessianServlet.service(HessianServlet.java:365
)
org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilte
r.java:96)
</pre></p><p><b>note</b> <u>The full stack trace of the root cause is
available in the JBossWeb/2.0.0.GA_CP05 logs.</u></p><HR size="1"
noshade="noshade"><h3>JBossWeb/2.0.0.GA_CP05</h3></body></html>
-----------------------------------------------------------------------
So you are right about the content-type and HTML-issue.
Yeah, it seems so :-)
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. Well I will work
on this and find a workaround for this within this week.
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.
Thanks,
Ruwan
Regards,
Eric
_______________________________________________
Esb-java-dev mailing list
[email protected]
http://wso2.org/cgi-bin/mailman/listinfo/esb-java-dev
