-
1. Re: Remoting periodic exception.
samdoyle Dec 3, 2007 8:38 PM (in response to samdoyle)Anyone see this before?
-
2. Re: Remoting periodic exception.
shane.bryzak Dec 4, 2007 11:15 AM (in response to samdoyle)I haven't seen this before. Are there any Javascript errors when this occurs? I suggest you turn on debug mode so that you can examine the request packets that are being sent to the server to confirm that they are complete. Debug mode is turned on like this:
Seam.Remoting.setDebug(true)
-
3. Re: Remoting periodic exception.
samdoyle Dec 4, 2007 1:37 PM (in response to samdoyle)No JavaScript errors. I'll check it out with debugging enabled.
S.D. -
4. Re: Remoting periodic exception.
samdoyle Dec 4, 2007 2:07 PM (in response to samdoyle)The following produced the error, doesn't look unusual. It is the same as the several succeeding requests before it.
Tue Dec 4 11:01:57 PST 2007: Request packet: <envelope><header><context><conversationId>41</conversationId></context></header><body><call component="incidentAccessor" method="getIncidents" id="17"> <params></params><refs></refs></call></body></envelope>
As a result of this it is generating a error 400 poup dialog which as a result of the current way remoting works doesn't appear to be trappable.
Some questions though.
1.) Why are each of the response packets incrementing in conversation id?
2.) Why do sometimes when I make a request it appears I get pack an empty response followed by a valid response?"shane.bryzak@jboss.com" wrote:
I haven't seen this before. Are there any Javascript errors when this occurs? I suggest you turn on debug mode so that you can examine the request packets that are being sent to the server to confirm that they are complete. Debug mode is turned on like this:Seam.Remoting.setDebug(true)
-
-
6. Re: Remoting periodic exception.
shane.bryzak Dec 4, 2007 8:28 PM (in response to samdoyle)The request packet looks well-formed and complete, it's not clear why the exception is being thrown. Just to try something different, I've wrapped the request's InputStream in an InputStreamReader for the parsing of the xml. You can try this in the latest CVS version.
"samdoyle" wrote:
Some questions though.
1.) Why are each of the response packets incrementing in conversation id?
2.) Why do sometimes when I make a request it appears I get pack an empty response followed by a valid response?
1. Unless you explicitly set the conversation ID yourself (see the remoting docs) then whatever conversation ID is current at the end of the request will be sent back in the remoting response.
2. I've never seen anything like this, could you give me an example? -
7. Re: Remoting periodic exception.
samdoyle Dec 4, 2007 9:13 PM (in response to samdoyle)I lost our demo box again until tomorrow but what happens sometimes is that in the debug output window it just says empty response immediately followed by the expected response. Seemed odd.
S.D. -
8. Re: Remoting periodic exception.
samdoyle Dec 5, 2007 4:57 PM (in response to samdoyle)Hello Shane, latest build from CVS still generates this error periodically.
[#|2007-12-05T13:48:50.106-0500|SEVERE|sun-appserver9.1|org.jboss.seam.remoting.Remoting|_ThreadID=20;_ThreadName=httpSSLWorkerThread-38080-1;_RequestID=b24ed108-c908-43e6-81c5-bbf9ccc60b3b;|Error org.dom4j.DocumentException: Error on line 1 of document : Premature end of file. Nested exception: Premature end of file. at org.dom4j.io.SAXReader.read(SAXReader.java:482) at org.dom4j.io.SAXReader.read(SAXReader.java:365) at org.jboss.seam.remoting.ExecutionHandler.handle(ExecutionHandler.java:57) at org.jboss.seam.remoting.Remoting.getResource(Remoting.java:111) at org.jboss.seam.servlet.SeamResourceServlet.doGet(SeamResourceServlet.java:75) at org.jboss.seam.servlet.SeamResourceServlet.doPost(SeamResourceServlet.java:92)
"shane.bryzak@jboss.com" wrote:
The request packet looks well-formed and complete, it's not clear why the exception is being thrown. Just to try something different, I've wrapped the request's InputStream in an InputStreamReader for the parsing of the xml. You can try this in the latest CVS version."samdoyle" wrote:
Some questions though.
1.) Why are each of the response packets incrementing in conversation id?
2.) Why do sometimes when I make a request it appears I get pack an empty response followed by a valid response?
1. Unless you explicitly set the conversation ID yourself (see the remoting docs) then whatever conversation ID is current at the end of the request will be sent back in the remoting response.
2. I've never seen anything like this, could you give me an example? -
9. Re: Remoting periodic exception.
shane.bryzak Dec 5, 2007 8:00 PM (in response to samdoyle)I've modified the code a little further to pre-cache the request data before parsing it as XML. It is also logged as a debug message, so you should be able to see the exact XML that is being parsed.
-
10. Re: Remoting periodic exception.
samdoyle Dec 5, 2007 9:16 PM (in response to samdoyle)Cool and thanks, I'll checkout and build again.
S.D. -
11. Re: Remoting periodic exception.
samdoyle Dec 6, 2007 2:54 PM (in response to samdoyle)Hey so I don't see the exception being propagated to the browser now which is great. I see the exceptions in the log but I have set the logging in the app. server to finest and still do not see the debug messages. What is required to enable the log debugging?
S.D. -
12. Re: Remoting periodic exception.
shane.bryzak Dec 6, 2007 6:41 PM (in response to samdoyle)You need to set the log4j threshold to DEBUG for org.jboss.seam.remoting.ExecutionHandler. If you're using JBossAS, it comes configured by default to log debug messages.