com.ctc.wstx.exc.WstxUnexpectedCharException:

1,675 views
Skip to first unread message

Klabusterbaerchen

unread,
Apr 19, 2013, 3:35:47 AM4/19/13
to membrane...@googlegroups.com
Hi,

I`ve been using on a remote server.

Membrane Version is 3.5.8

The server-configuration contains the web-console (Memory Exchange Store), File-Exchangestore and a JDBCStatisticsInterceptor.
Server is running Linux, calling client is a Windows system.

The Metro JBoss is starting to behave lately.
I
 see massive amounts of:

        at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:598)
        at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
        at java.lang.Thread.run(Thread.java:662)
Caused by: com.sun.xml.ws.streaming.XMLStreamReaderException: XML reader error: com.ctc.wstx.exc.WstxUnexpectedCharException: Unexpected character 't' (code 116) in prolog; expected '<'
 at [row,col {unknown-source}]: [1,1]
        at com.sun.xml.ws.streaming.XMLStreamReaderUtil.wrapException(XMLStreamReaderUtil.java:267)
        at com.sun.xml.ws.streaming.XMLStreamReaderUtil.next(XMLStreamReaderUtil.java:95)
        at com.sun.xml.ws.streaming.XMLStreamReaderUtil.nextContent(XMLStreamReaderUtil.java:110)
        at com.sun.xml.ws.streaming.XMLStreamReaderUtil.nextElementContent(XMLStreamReaderUtil.java:100)
        at com.sun.xml.ws.encoding.StreamSOAPCodec.decode(StreamSOAPCodec.java:175)
        at com.sun.xml.ws.encoding.StreamSOAPCodec.decode(StreamSOAPCodec.java:303)
        at com.sun.xml.ws.encoding.StreamSOAPCodec.decode(StreamSOAPCodec.java:129)
        at com.sun.xml.ws.encoding.SOAPBindingCodec.decode(SOAPBindingCodec.java:360)
        ... 30 more
Caused by: com.ctc.wstx.exc.WstxUnexpectedCharException: Unexpected character 't' (code 116) in prolog; expected '<'
 at [row,col {unknown-source}]: [1,1]
        at com.ctc.wstx.sr.StreamScanner.throwUnexpectedChar(StreamScanner.java:648)
        at com.ctc.wstx.sr.BasicStreamReader.nextFromProlog(BasicStreamReader.java:2047)
        at com.ctc.wstx.sr.BasicStreamReader.next(BasicStreamReader.java:1069)
        at com.sun.xml.ws.util.xml.XMLStreamReaderFilter.next(XMLStreamReaderFilter.java:92)
        at com.sun.xml.ws.streaming.XMLStreamReaderUtil.next(XMLStreamReaderUtil.java:76)
        ... 36 more

Any idea what might be the root of this problem or where to start looking?

Tobias Polley

unread,
Apr 19, 2013, 3:51:17 AM4/19/13
to membrane...@googlegroups.com
Hi Klabusterbaerchen,

you could add <log /> right before the <target/> in proxies.xml . Resubmit the request and check the log file.

Best, Tobias

Klabusterbaerchen

unread,
Apr 19, 2013, 5:25:42 AM4/19/13
to membrane...@googlegroups.com
Hi Tobias,

thanks for your remark.

Usually when a user resubmits the request it passes membrane and the metro stack without errors.
Sad thing is, that the error seem's to be hard to reproduce.

On the membrane console I see:
POST /com/myWebService HTTP/1.1
Content-Type: text/xml; charset=utf-8
SOAPAction: "http://com.testproject/IMyWebService/MyAction"
Host: membrane-server:8180
Content-Length: 13637
Accept-Encoding: gzip, deflate
X-Forwarded-For: 10.129.57.33
java.net.SocketException: Broken pipe
        at java.net.SocketOutputStream.socketWrite0(Native Method)
        at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92)
        at java.net.SocketOutputStream.write(SocketOutputStream.java:136)
        at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:65)
        at java.io.BufferedOutputStream.write(BufferedOutputStream.java:109)
        at com.predic8.membrane.core.http.PlainBodyTransferrer.write(PlainBodyTransferrer.java:27)
        at com.predic8.membrane.core.http.Body.writeNotRead(Body.java:81)
        at com.predic8.membrane.core.http.AbstractBody.write(AbstractBody.java:67)
        at com.predic8.membrane.core.http.Message.write(Message.java:161)
        at com.predic8.membrane.core.transport.http.HttpClient.doCall(HttpClient.java:206)
        at com.predic8.membrane.core.transport.http.HttpClient.call(HttpClient.java:149)
        at com.predic8.membrane.core.interceptor.HTTPClientInterceptor.handleRequest(HTTPClientInterceptor.java:58)
        at com.predic8.membrane.core.interceptor.InterceptorFlowController.invokeRequestHandlers(InterceptorFlowController.java:94)
        at com.predic8.membrane.core.interceptor.InterceptorFlowController.invokeHandlers(InterceptorFlowController.java:60)
        at com.predic8.membrane.core.transport.http.AbstractHttpHandler.invokeHandlers(AbstractHttpHandler.java:69)
        at com.predic8.membrane.core.transport.http.HttpServerHandler.process(HttpServerHandler.java:182)
        at com.predic8.membrane.core.transport.http.HttpServerHandler.run(HttpServerHandler.java:87)
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
        at java.lang.Thread.run(Thread.java:662)

...but I guess that's just a consequence from the problem in METRO.

Altering proxies.xml requires a restart of membrane?

I haveven't integrated it into the jboss, but use the memrouter.sh....

Klabusterbaerchen

unread,
Apr 19, 2013, 1:29:46 PM4/19/13
to membrane...@googlegroups.com
Hi Tobias,

after I added the </log> entry into proxies.xml the error didn't occure any more :-(

As i said already the error doesn't always occure and definetly hasn't occured before we enabled membrane on the server.

Unsure if the faulty request (as i'd guess a faulty response caused by membrane influence) is recorded in the database or as a file at all. Wasn't able to identify it so far, but i'll have to check that in more detail. Resending is not guarenteed to reproduce the behaviour as a second call to the same webservice with identical request usually passes.

I have the feeling the error might be related to large base64 encoded strings (> 2 mb) But we also got the error in messages which containef no base64 encoded information at all :-/

Probablly it is also caused by multiple users creating traffic simultanesly....

I'll try to reproduce the error with soapUI.
Still some ideas on what to test first would be appreciated :-/

Sincerely,

Stephan

Reply all
Reply to author
Forward
Message has been deleted
0 new messages