Issue with .NET ws clients

[palin]

We have some .NET ws clients using our ws endpoint implemented on jbossws 1.0.3.SP1 (patched with http://jira.jboss.com/jira/browse/JBWS-1178). They sometimes (not always?!) get an error while calling us:

Exception: System.InvalidOperationException
Message: Client found response content type of '', but expected 'text/xml"

At the same time, on the server side, we get the following exception:

2006-12-09 19:49:20,898 ERROR [org.jboss.ws.server.StandardEndpointServlet] Error processing web service request
java.lang.IllegalStateException: Cannot create a session after the response has been committed
 at org.apache.catalina.connector.Request.doGetSession(Request.java:2214)
 at org.apache.catalina.connector.Request.getSession(Request.java:2024)
 at org.apache.catalina.connector.RequestFacade.getSession(RequestFacade.java:831)
 at org.apache.catalina.connector.RequestFacade.getSession(RequestFacade.java:842)
 at org.jboss.ws.server.ServletEndpointContextImpl.getHttpSession(ServletEndpointContextImpl.java:57)
 at org.jboss.ws.server.ServiceEndpointManager.processSOAPRequest(ServiceEndpointManager.java:375)
 at org.jboss.ws.server.StandardEndpointServlet.doPost(StandardEndpointServlet.java:115)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
 at org.jboss.ws.server.StandardEndpointServlet.service(StandardEndpointServlet.java:76)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
 at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
 at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
 at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
 at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
 at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
 at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
 at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
 at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:175)
 at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:524)
 at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:74)
 at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
 at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
 at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
 at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
 at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
 at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
 at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
 at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
 at java.lang.Thread.run(Thread.java:595)

Did anybody ever had the same problem? Or at least know why jbossws could try to open a session after the response has been commited?
Thank you
Alessio Soldano
http://www.javalinux.it/blogs

[heiko.braun]

Did you look at tomcat forums as well? Currently i cannot see that this relates to JBossWS.

[heiko.braun]

Sorry, forget my previous statement. I should have read the stacktrace more carefully.

[heiko.braun]

Looking at it more carefully doesn't reveal anything at JBossWS processing level. That piece of code prepares the SOAPMessageContext upon receiving the HTTPRequest InputStream.

My 2 cents:
In this case i'd say that the servlet engine probably has written something back to .NET client without notice. Do you have any HTTP logs available at the client side? A look at the jboss-tomcat logs might help as well.

[maeste]

Looking at it more carefully doesn't reveal anything at JBossWS processing level. That piece of code prepares the SOAPMessageContext upon receiving the HTTPRequest InputStream.

Yes, it seems the HTTPRequest InputStream is already closed when jbossws try to use it. One more thing to clarify the situation: it happens with unpredictable frequency...it seems a problem with server overload or concurrency (just a smell of them, I'm not sure, but a lot of tests in test environment can't reproduce error)

My 2 cents:
In this case i'd say that the servlet engine probably has written something back to .NET client without notice.

and closes the connection.

Do you have any HTTP logs available at the client side?

No of course.........it's a .NET client :)

A look at the jboss-tomcat logs might help as well.

Some classes suspected? We can't enable all jboss-tomcat logs in production environment processing many requests per second.

A little OT: please take a look to my last post in Design Forum ;)

[pbowker]

Maeste,

Are your .NET clients using .NET3.0/WCF or the older .NET (2.0 or before) web services?

[maeste]

"pbowker" wrote:
Maeste,

Are your .NET clients using .NET3.0/WCF or the older .NET (2.0 or before) web services?

mmh sincerely I don't know...is not MY clients :)
I'll ask to my partner, but please explain me why you are asking. Are there some known problem using one of them with jbossws?
If I have some hints is easier for me to point my partner on the problem...remember he is a .NET programmer :)

[pbowker]

It's known problems that I'm looking for myself and why I was attracted to your initial post.

I am at the start of such a project but using the latest WCF .NET 3.0 technology from MS on the client. My server is JBoss 4.0.5 plus (at the moment) the JBossWS 1.0.4 stack.

If you could find out which technology your .NET client uses I'd be very grateful so I know whether or not I need to look out for this problem.

At the moment we're at the prototyping stage and whilst we have no show stoppers most of the issues so far have been with the Eclipse/JbossWS tooling/process.