12 Replies Latest reply on Dec 6, 2007 6:41 PM by shane.bryzak

    Remoting periodic exception.

    samdoyle

      Using the JavaScript remoting I will see periodically but quite frequently the following exception. It is a result of simply doing a polled based operation to retrieve the latest available data.

      [#|2007-12-03T12:53:34.110-0500|SEVERE|sun-appserver9.1|org.jboss.seam.remoting.Remoting|_ThreadID=21;_ThreadName=httpSSLWorkerThread-38080-0;_RequestID=d5d7caaf-2e82-41be-b6f7-383164d5a74f;|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:343)
       at org.jboss.seam.remoting.ExecutionHandler.handle(ExecutionHandler.java:59)
       at org.jboss.seam.remoting.Remoting.getResource(Remoting.java:113)
       at org.jboss.seam.servlet.SeamResourceServlet.doGet(SeamResourceServlet.java:69)
       at org.jboss.seam.servlet.SeamResourceServlet.doPost(SeamResourceServlet.java:86)


        • 1. Re: Remoting periodic exception.
          samdoyle

          Anyone see this before?

          • 2. Re: Remoting periodic exception.
            shane.bryzak

            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

              No JavaScript errors. I'll check it out with debugging enabled.

              S.D.

              • 4. Re: Remoting periodic exception.
                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)


                • 5. Re: Remoting periodic exception.
                  samdoyle

                  Anyone?

                  • 6. Re: Remoting periodic exception.
                    shane.bryzak

                    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

                      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

                        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

                          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

                            Cool and thanks, I'll checkout and build again.

                            S.D.

                            • 11. Re: Remoting periodic exception.
                              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

                                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.