[jira] Created: (JETTY-586) Input stream is corrupted when reading via a spawned thread with jetty thread in suspended state.

classic Classic list List threaded Threaded
36 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[jira] Created: (JETTY-586) Input stream is corrupted when reading via a spawned thread with jetty thread in suspended state.

JIRA jira@codehaus.org
Input stream is corrupted when reading via a spawned thread with jetty thread in suspended state.
-------------------------------------------------------------------------------------------------

                 Key: JETTY-586
                 URL: http://jira.codehaus.org/browse/JETTY-586
             Project: Jetty
          Issue Type: Bug
          Components: Continuations
            Reporter: Jan Bartel


From the jetty mailing lists:

I'm seeing an odd issue with Jetty 6.1.x with continuations and select-style NIO when a client is sending a chunked request that consists of a few chunks.  The intended use case is that request processing occurs in the background, so the implementation forks a thread to consume the InputStream from the request and then suspend() is called on the continuation.


--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

[jira] Commented: (JETTY-586) Input stream is corrupted when reading via a spawned thread with jetty thread in suspended state.

JIRA jira@codehaus.org

    [ http://jira.codehaus.org/browse/JETTY-586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=136579#action_136579 ]

Jan Bartel commented on JETTY-586:
----------------------------------

More info from the list:


Here's a stack trace:

Exception in thread "pool-1-thread-1" java.lang.RuntimeException: java.io.IOException: bad chunk char: 61
    at us.ifario.mult.EchoServlet$Printer.run(EchoServlet.java:65)
    at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
    at java.lang.Thread.run(Thread.java:637)
Caused by: java.io.IOException: bad chunk char: 61
    at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:694)
    at org.mortbay.jetty.HttpParser$Input.blockForContent(HttpParser.java:1038)
    at org.mortbay.jetty.HttpParser$Input.read(HttpParser.java:999)
    at java.io.InputStream.read(InputStream.java:85)
    at us.ifario.mult.EchoServlet$Printer.run(EchoServlet.java:59)

With enough runs, you'll also see equivalent exceptions with different characters causing the chunking failure instead of '&' ('1', 'p', etc.).  These (and variants) may also show up:

java.io.IOException: FULL
    at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:266)
    at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:205)
    at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:380)
    at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:395)
    at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:488)

Or

java.lang.IllegalArgumentException
    at java.nio.Buffer.position(Buffer.java:218)
    at org.mortbay.io.nio.ChannelEndPoint.fill(ChannelEndPoint.java:121)
    at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:282)
    at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:205)
    at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:380)
    at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:395)
    at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:488)

For the last one, the issue is that NIOBuffer is trying to move the underlying ByteBuffer to a negative position.

And then with a little luck, you'll get this kind of failure:

Malformed hunk from request 1177: pp676=0123456789
Malformed hunk from request 1002: p1001=0123456789490=0123456789
Malformed hunk from request 1011: p1010=012345678956789

I've posted a minimal test case here:

    http://mult.ifario.us/files/jetty-bug.tbz2

To run it:

    mvn -Dmaven.test.skip jetty:run-exploded

And then to use Commons HttpClient's client:

    mvn -Dtest=C* test

or to use HttpComponents' client:

    mvn -Dtest=H* test

until you get something interesting.  On my development box, things usually blow up in the 1400-1600 range, but it's possible that the test run will complete without an issue.


> Input stream is corrupted when reading via a spawned thread with jetty thread in suspended state.
> -------------------------------------------------------------------------------------------------
>
>                 Key: JETTY-586
>                 URL: http://jira.codehaus.org/browse/JETTY-586
>             Project: Jetty
>          Issue Type: Bug
>          Components: Continuations
>            Reporter: Jan Bartel
>
> From the jetty mailing lists:
> I'm seeing an odd issue with Jetty 6.1.x with continuations and select-style NIO when a client is sending a chunked request that consists of a few chunks.  The intended use case is that request processing occurs in the background, so the implementation forks a thread to consume the InputStream from the request and then suspend() is called on the continuation.

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

[jira] Updated: (JETTY-586) Input stream is corrupted when reading via a spawned thread with jetty thread in suspended state.

JIRA jira@codehaus.org
In reply to this post by JIRA jira@codehaus.org

     [ http://jira.codehaus.org/browse/JETTY-586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Bartel updated JETTY-586:
-----------------------------

    Attachment: jetty-bug.tar

> Input stream is corrupted when reading via a spawned thread with jetty thread in suspended state.
> -------------------------------------------------------------------------------------------------
>
>                 Key: JETTY-586
>                 URL: http://jira.codehaus.org/browse/JETTY-586
>             Project: Jetty
>          Issue Type: Bug
>          Components: Continuations
>            Reporter: Jan Bartel
>         Attachments: jetty-bug.tar
>
>
> From the jetty mailing lists:
> I'm seeing an odd issue with Jetty 6.1.x with continuations and select-style NIO when a client is sending a chunked request that consists of a few chunks.  The intended use case is that request processing occurs in the background, so the implementation forks a thread to consume the InputStream from the request and then suspend() is called on the continuation.

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

[jira] Assigned: (JETTY-586) Input stream is corrupted when reading via a spawned thread with jetty thread in suspended state.

JIRA jira@codehaus.org
In reply to this post by JIRA jira@codehaus.org

     [ http://jira.codehaus.org/browse/JETTY-586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Bartel reassigned JETTY-586:
--------------------------------

    Assignee: David Yu

> Input stream is corrupted when reading via a spawned thread with jetty thread in suspended state.
> -------------------------------------------------------------------------------------------------
>
>                 Key: JETTY-586
>                 URL: http://jira.codehaus.org/browse/JETTY-586
>             Project: Jetty
>          Issue Type: Bug
>          Components: Continuations
>            Reporter: Jan Bartel
>            Assignee: David Yu
>         Attachments: jetty-bug.tar
>
>
> From the jetty mailing lists:
> I'm seeing an odd issue with Jetty 6.1.x with continuations and select-style NIO when a client is sending a chunked request that consists of a few chunks.  The intended use case is that request processing occurs in the background, so the implementation forks a thread to consume the InputStream from the request and then suspend() is called on the continuation.

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

[jira] Commented: (JETTY-586) Input stream is corrupted when reading via a spawned thread with jetty thread in suspended state.

JIRA jira@codehaus.org
In reply to this post by JIRA jira@codehaus.org

    [ http://jira.codehaus.org/browse/JETTY-586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=136980#action_136980 ]

David Yu commented on JETTY-586:
--------------------------------

From the mailing list:


Hi, Jetty folk --

I'm seeing an odd issue with Jetty 6.1.x with continuations and select-style NIO when a client is sending a chunked request that consists of a few chunks.  The intended use case is that request processing occurs in the background, so the implementation forks a thread to consume the InputStream from the request and then suspend() is called on the continuation.

The issue is that the request InputStream gets corrupted when suspend() is called.  Anyone experienced something similar?

Thanks in advance.

-- Paul

===========================================================================

Paul,

I am not sure you can manage continuation in a separated thread as the basic of continuation.suspend is to
throw an exception to roughly stop the end-point thread. Jesse to confirm that point.

Fred

===========================================================================

Paul,

Just to clarify - you're spawning a thread to read the input stream, and then
calling suspend() from the original request-processing thread, yes?

If so, you should be able to use a forked thread to read the IO stream.

Have you got more precise information on what is going wrong, such as a
stack trace? Also, if you had a little test rig that demonstrated the problem
that would be helpful.

cheers
Jan

===========================================================================

Hi, Jan --

> Just to clarify - you're spawning a thread to read the input stream, and then
> calling suspend() from the original request-processing thread, yes?

That's correct, with the additional caveat that the issue only occurs:

1) If the client is using chunked transfer encoding.
2) If it's *not* the first request sent to the container.
3) If the request splits into several chunks; very small or very large requests seem OK.

> If so, you should be able to use a forked thread to read the IO stream.

Cool!  I was hoping that it was a supported use case.  The documentation for the select-based endpoint makes it clear that the request body won't be available for the second pass but doesn't say anything about the interim.

> Have you got more precise information on what is going wrong, such as a
> stack trace? Also, if you had a little test rig that demonstrated the problem
> that would be helpful.

I'll see if I can cook up a little test rig.

I spent a good amount of time debugging the issue (to eliminate CXF, internal code, etc.), and here's a summary.  The forked thread contains an StAX parser, and I plumbed a CountDownLatch into the system so that I could trigger the continuation's suspend() after some amount of processing on the web service's background thread.  I watched the text look-ahead that's part of the HttpParser within the servlet request.  Up until the point where the continuation is triggered, it contains the expected "<soap:envelope>...", but once I release the latch and the continuation is triggered (but before the parser has started reading) the buffer jumps ahead and the buffer contains something like "oo>bar</foo>..." from the middle of the message.

I'll file a Jira once I can get Ben to reset my password.  Codehaus Jira isn't emailing me for some reason.

-- Paul

===========================================================================


Hi, Jan --

On May 26, 2008, at 2:41 PM, Jan Bartel wrote:
> Have you got more precise information on what is going wrong, such as a
> stack trace? Also, if you had a little test rig that demonstrated the problem
> that would be helpful.

Here's a stack trace:

Exception in thread "pool-1-thread-1" java.lang.RuntimeException: java.io.IOException: bad chunk char: 61
    at us.ifario.mult.EchoServlet$Printer.run(EchoServlet.java:65)
    at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
    at java.lang.Thread.run(Thread.java:637)
Caused by: java.io.IOException: bad chunk char: 61
    at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:694)
    at org.mortbay.jetty.HttpParser$Input.blockForContent(HttpParser.java:1038)
    at org.mortbay.jetty.HttpParser$Input.read(HttpParser.java:999)
    at java.io.InputStream.read(InputStream.java:85)
    at us.ifario.mult.EchoServlet$Printer.run(EchoServlet.java:59)

With enough runs, you'll also see equivalent exceptions with different characters causing the chunking failure instead of '&' ('1', 'p', etc.).  These (and variants) may also show up:

java.io.IOException: FULL
    at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:266)
    at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:205)
    at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:380)
    at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:395)
    at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:488)

Or

java.lang.IllegalArgumentException
    at java.nio.Buffer.position(Buffer.java:218)
    at org.mortbay.io.nio.ChannelEndPoint.fill(ChannelEndPoint.java:121)
    at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:282)
    at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:205)
    at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:380)
    at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:395)
    at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:488)

For the last one, the issue is that NIOBuffer is trying to move the underlying ByteBuffer to a negative position.

And then with a little luck, you'll get this kind of failure:

Malformed hunk from request 1177: pp676=0123456789
Malformed hunk from request 1002: p1001=0123456789490=0123456789
Malformed hunk from request 1011: p1010=012345678956789

I've posted a minimal test case here:

    http://mult.ifario.us/files/jetty-bug.tbz2

To run it:

    mvn -Dmaven.test.skip jetty:run-exploded

And then to use Commons HttpClient's client:

    mvn -Dtest=C* test

or to use HttpComponents' client:

    mvn -Dtest=H* test

until you get something interesting.  On my development box, things usually blow up in the 1400-1600 range, but it's possible that the test run will complete without an issue.

Cheers.

-- Paul

===========================================================================

Paul,

FYI, I've raised a Jetty issue for this:

http://jira.codehaus.org/browse/JETTY-586

cheers
Jan

===========================================================================

Hi Paul,

What OS did you use with the test?  I was not able to replicate this on a windows xp box.

Cheers

===========================================================================

Hi, David --

I ran the tests on Mac OS X (10.5.2, Intel, Java 6), but the original issue occurred on Mac OS X, Linux, and on Windows.  (In some cases, Jetty was running "embedded" in Maven but in others it was running bare.)  You may have to run several runs to get the issue to occur with the little harness I provided.  Also, the machines producing the issue are relatively modern (multi-core, fast), and it's possible that it might not occur on older hardware.

Best.

-- Paul

===========================================================================

Hi Paul,

I'm beginning to think this is an java1.6 related issue.  Tried this many times on windows xp and fc7(java 1.5), and the test completed without errors.
Can you try testing against java 1.5 and see if you're still getting the error?

Thanks

===========================================================================

Hi, David --

I just tried with Java5 on my Mac, and the issue occurs after a few repetitions of

    mvn -Dtest=C* test

The trace in this case is the same as some of them on Java6:

2008-05-29 21:28:40.635::WARN:  handle failed
java.lang.IndexOutOfBoundsException: -6630
    at java.nio.DirectByteBuffer.get(DirectByteBuffer.java:209)
    at org.mortbay.io.nio.NIOBuffer.peek(NIOBuffer.java:86)
    at org.mortbay.io.AbstractBuffer.peek(AbstractBuffer.java:306)
    at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:656)

FWIW, I'm not able to provoke the issue by running the tests in sequence (mvn test), so try repeated runs of either test with a single client implementation.

-- Paul

> Input stream is corrupted when reading via a spawned thread with jetty thread in suspended state.
> -------------------------------------------------------------------------------------------------
>
>                 Key: JETTY-586
>                 URL: http://jira.codehaus.org/browse/JETTY-586
>             Project: Jetty
>          Issue Type: Bug
>          Components: Continuations
>            Reporter: Jan Bartel
>            Assignee: David Yu
>         Attachments: jetty-bug.tar
>
>
> From the jetty mailing lists:
> I'm seeing an odd issue with Jetty 6.1.x with continuations and select-style NIO when a client is sending a chunked request that consists of a few chunks.  The intended use case is that request processing occurs in the background, so the implementation forks a thread to consume the InputStream from the request and then suspend() is called on the continuation.

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

[jira] Assigned: (JETTY-586) Input stream is corrupted when reading via a spawned thread with jetty thread in suspended state.

JIRA jira@codehaus.org
In reply to this post by JIRA jira@codehaus.org

     [ http://jira.codehaus.org/browse/JETTY-586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Bartel reassigned JETTY-586:
--------------------------------

    Assignee: Jesse McConnell  (was: David Yu)

Jesse,

As the owner of a mac, could you do the suggested tests and see if you can reproduce the failure? We haven't been able to reproduce on linux or various windows flavours.

thanks!
Jan

> Input stream is corrupted when reading via a spawned thread with jetty thread in suspended state.
> -------------------------------------------------------------------------------------------------
>
>                 Key: JETTY-586
>                 URL: http://jira.codehaus.org/browse/JETTY-586
>             Project: Jetty
>          Issue Type: Bug
>          Components: Continuations
>            Reporter: Jan Bartel
>            Assignee: Jesse McConnell
>         Attachments: jetty-bug.tar
>
>
> From the jetty mailing lists:
> I'm seeing an odd issue with Jetty 6.1.x with continuations and select-style NIO when a client is sending a chunked request that consists of a few chunks.  The intended use case is that request processing occurs in the background, so the implementation forks a thread to consume the InputStream from the request and then suspend() is called on the continuation.

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

[jira] Updated: (JETTY-586) Input stream is corrupted when reading via a spawned thread with jetty thread in suspended state.

JIRA jira@codehaus.org
In reply to this post by JIRA jira@codehaus.org

     [ http://jira.codehaus.org/browse/JETTY-586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesse McConnell updated JETTY-586:
----------------------------------

    Fix Version/s:     (was: 7.0.0pre3)
                   7.0.0pre4

> Input stream is corrupted when reading via a spawned thread with jetty thread in suspended state.
> -------------------------------------------------------------------------------------------------
>
>                 Key: JETTY-586
>                 URL: http://jira.codehaus.org/browse/JETTY-586
>             Project: Jetty
>          Issue Type: Bug
>          Components: Continuations
>            Reporter: Jan Bartel
>            Assignee: Jesse McConnell
>             Fix For: 7.0.0pre4, 6.1.12
>
>         Attachments: jetty-bug.tar
>
>
> From the jetty mailing lists:
> I'm seeing an odd issue with Jetty 6.1.x with continuations and select-style NIO when a client is sending a chunked request that consists of a few chunks.  The intended use case is that request processing occurs in the background, so the implementation forks a thread to consume the InputStream from the request and then suspend() is called on the continuation.

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

[jira] Commented: (JETTY-586) Input stream is corrupted when reading via a spawned thread with jetty thread in suspended state.

JIRA jira@codehaus.org
In reply to this post by JIRA jira@codehaus.org

    [ http://jira.codehaus.org/browse/JETTY-586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=149406#action_149406 ]

Jesse McConnell commented on JETTY-586:
---------------------------------------

hm...

yes, the scenario above does manifest on my mac with both java5 and java6..

java5 kicked out this exception server side:

Exception in thread "pool-1-thread-7" java.lang.RuntimeException: java.io.IOException: bad chunk char: 61
        at us.ifario.mult.EchoServlet$Printer.run(EchoServlet.java:55)
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
        at java.lang.Thread.run(Thread.java:613)
Caused by: java.io.IOException: bad chunk char: 61
        at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:694)
        at org.mortbay.jetty.HttpParser$Input.blockForContent(HttpParser.java:1038)
        at org.mortbay.jetty.HttpParser$Input.read(HttpParser.java:999)
        at java.io.InputStream.read(InputStream.java:89)
        at us.ifario.mult.EchoServlet$Printer.run(EchoServlet.java:49)

> Input stream is corrupted when reading via a spawned thread with jetty thread in suspended state.
> -------------------------------------------------------------------------------------------------
>
>                 Key: JETTY-586
>                 URL: http://jira.codehaus.org/browse/JETTY-586
>             Project: Jetty
>          Issue Type: Bug
>          Components: Continuations
>            Reporter: Jan Bartel
>            Assignee: Jesse McConnell
>             Fix For: 7.0.0pre4, 6.1.12
>
>         Attachments: jetty-bug.tar
>
>
> From the jetty mailing lists:
> I'm seeing an odd issue with Jetty 6.1.x with continuations and select-style NIO when a client is sending a chunked request that consists of a few chunks.  The intended use case is that request processing occurs in the background, so the implementation forks a thread to consume the InputStream from the request and then suspend() is called on the continuation.

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

[jira] Commented: (JETTY-586) Input stream is corrupted when reading via a spawned thread with jetty thread in suspended state.

JIRA jira@codehaus.org
In reply to this post by JIRA jira@codehaus.org

    [ http://jira.codehaus.org/browse/JETTY-586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=149407#action_149407 ]

Jesse McConnell commented on JETTY-586:
---------------------------------------

against 6.1.12.rc2 with java6 this was the server side exception:

Exception in thread "pool-1-thread-4" java.lang.RuntimeException: java.io.IOException: bad chunk char: 61
        at us.ifario.mult.EchoServlet$Printer.run(EchoServlet.java:55)
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
        at java.lang.Thread.run(Thread.java:637)
Caused by: java.io.IOException: bad chunk char: 61
        at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:708)
        at org.mortbay.jetty.HttpParser$Input.blockForContent(HttpParser.java:1058)
        at org.mortbay.jetty.HttpParser$Input.read(HttpParser.java:1019)
        at java.io.InputStream.read(InputStream.java:85)
        at us.ifario.mult.EchoServlet$Printer.run(EchoServlet.java:49)
        ... 3 more

> Input stream is corrupted when reading via a spawned thread with jetty thread in suspended state.
> -------------------------------------------------------------------------------------------------
>
>                 Key: JETTY-586
>                 URL: http://jira.codehaus.org/browse/JETTY-586
>             Project: Jetty
>          Issue Type: Bug
>          Components: Continuations
>            Reporter: Jan Bartel
>            Assignee: Jesse McConnell
>             Fix For: 7.0.0pre4, 6.1.12
>
>         Attachments: jetty-bug.tar
>
>
> From the jetty mailing lists:
> I'm seeing an odd issue with Jetty 6.1.x with continuations and select-style NIO when a client is sending a chunked request that consists of a few chunks.  The intended use case is that request processing occurs in the background, so the implementation forks a thread to consume the InputStream from the request and then suspend() is called on the continuation.

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

[jira] Commented: (JETTY-586) Input stream is corrupted when reading via a spawned thread with jetty thread in suspended state.

JIRA jira@codehaus.org
In reply to this post by JIRA jira@codehaus.org

    [ http://jira.codehaus.org/browse/JETTY-586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=149424#action_149424 ]

Jesse McConnell commented on JETTY-586:
---------------------------------------

I updated this to the 7.0-SNAPSHOT and out pops this exception which seems to be digging in a bit deeper:

[POST /test/]@679408063 HANDLING,initial,timeout
Exception in thread "pool-1-thread-14" java.lang.IndexOutOfBoundsException
        at java.nio.Buffer.checkIndex(Buffer.java:514)
        at java.nio.DirectByteBuffer.get(DirectByteBuffer.java:233)
        at org.mortbay.io.nio.NIOBuffer.peek(NIOBuffer.java:94)
        at org.mortbay.io.AbstractBuffer.peek(AbstractBuffer.java:308)
        at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:672)
        at org.mortbay.jetty.HttpParser$Input.blockForContent(HttpParser.java:1060)
        at org.mortbay.jetty.HttpParser$Input.read(HttpParser.java:1021)
        at java.io.InputStream.read(InputStream.java:85)
        at us.ifario.mult.EchoServlet$Printer.run(EchoServlet.java:49)
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
        at java.lang.Thread.run(Thread.java:637)

> Input stream is corrupted when reading via a spawned thread with jetty thread in suspended state.
> -------------------------------------------------------------------------------------------------
>
>                 Key: JETTY-586
>                 URL: http://jira.codehaus.org/browse/JETTY-586
>             Project: Jetty
>          Issue Type: Bug
>          Components: Continuations
>            Reporter: Jan Bartel
>            Assignee: Jesse McConnell
>             Fix For: 7.0.0pre4, 6.1.12
>
>         Attachments: jetty-bug.tar
>
>
> From the jetty mailing lists:
> I'm seeing an odd issue with Jetty 6.1.x with continuations and select-style NIO when a client is sending a chunked request that consists of a few chunks.  The intended use case is that request processing occurs in the background, so the implementation forks a thread to consume the InputStream from the request and then suspend() is called on the continuation.

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

[jira] Commented: (JETTY-586) Input stream is corrupted when reading via a spawned thread with jetty thread in suspended state.

JIRA jira@codehaus.org
In reply to this post by JIRA jira@codehaus.org

    [ http://jira.codehaus.org/browse/JETTY-586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=149426#action_149426 ]

Jesse McConnell commented on JETTY-586:
---------------------------------------

http://www.nabble.com/JDK-1.5,-1.6-and-FreeBSD-td18890186.html

that looks to be a somewhat related issue, someone having issues uploading content through jetty and having activemq process it...

> Input stream is corrupted when reading via a spawned thread with jetty thread in suspended state.
> -------------------------------------------------------------------------------------------------
>
>                 Key: JETTY-586
>                 URL: http://jira.codehaus.org/browse/JETTY-586
>             Project: Jetty
>          Issue Type: Bug
>          Components: Continuations
>            Reporter: Jan Bartel
>            Assignee: Jesse McConnell
>             Fix For: 7.0.0pre4, 6.1.12
>
>         Attachments: jetty-bug.tar
>
>
> From the jetty mailing lists:
> I'm seeing an odd issue with Jetty 6.1.x with continuations and select-style NIO when a client is sending a chunked request that consists of a few chunks.  The intended use case is that request processing occurs in the background, so the implementation forks a thread to consume the InputStream from the request and then suspend() is called on the continuation.

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

[jira] Updated: (JETTY-586) Input stream is corrupted when reading via a spawned thread with jetty thread in suspended state.

JIRA jira@codehaus.org
In reply to this post by JIRA jira@codehaus.org

     [ http://jira.codehaus.org/browse/JETTY-586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesse McConnell updated JETTY-586:
----------------------------------

    Fix Version/s:     (was: 7.0.0pre4)
                   7.0.0.pre6

> Input stream is corrupted when reading via a spawned thread with jetty thread in suspended state.
> -------------------------------------------------------------------------------------------------
>
>                 Key: JETTY-586
>                 URL: http://jira.codehaus.org/browse/JETTY-586
>             Project: Jetty
>          Issue Type: Bug
>          Components: Continuations
>            Reporter: Jan Bartel
>            Assignee: Jesse McConnell
>             Fix For: 7.0.0.pre6, 6.1.12
>
>         Attachments: jetty-bug.tar
>
>
> From the jetty mailing lists:
> I'm seeing an odd issue with Jetty 6.1.x with continuations and select-style NIO when a client is sending a chunked request that consists of a few chunks.  The intended use case is that request processing occurs in the background, so the implementation forks a thread to consume the InputStream from the request and then suspend() is called on the continuation.

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

[jira] Updated: (JETTY-586) Input stream is corrupted when reading via a spawned thread with jetty thread in suspended state.

JIRA jira@codehaus.org
In reply to this post by JIRA jira@codehaus.org

     [ http://jira.codehaus.org/browse/JETTY-586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Greg Wilkins updated JETTY-586:
-------------------------------

    Fix Version/s:     (was: 6.1.12)
                   6.1.13

> Input stream is corrupted when reading via a spawned thread with jetty thread in suspended state.
> -------------------------------------------------------------------------------------------------
>
>                 Key: JETTY-586
>                 URL: http://jira.codehaus.org/browse/JETTY-586
>             Project: Jetty
>          Issue Type: Bug
>          Components: Continuations
>            Reporter: Jan Bartel
>            Assignee: Jesse McConnell
>             Fix For: 7.0.0.pre6, 6.1.14.rc1
>
>         Attachments: jetty-bug.tar
>
>
> From the jetty mailing lists:
> I'm seeing an odd issue with Jetty 6.1.x with continuations and select-style NIO when a client is sending a chunked request that consists of a few chunks.  The intended use case is that request processing occurs in the background, so the implementation forks a thread to consume the InputStream from the request and then suspend() is called on the continuation.

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

[jira] Updated: (JETTY-586) Input stream is corrupted when reading via a spawned thread with jetty thread in suspended state.

JIRA jira@codehaus.org
In reply to this post by JIRA jira@codehaus.org

     [ http://jira.codehaus.org/browse/JETTY-586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Greg Wilkins updated JETTY-586:
-------------------------------

    Fix Version/s:     (was: 6.1.14)
                   6.1.15.pre0

> Input stream is corrupted when reading via a spawned thread with jetty thread in suspended state.
> -------------------------------------------------------------------------------------------------
>
>                 Key: JETTY-586
>                 URL: http://jira.codehaus.org/browse/JETTY-586
>             Project: Jetty
>          Issue Type: Bug
>          Components: Continuations
>            Reporter: Jan Bartel
>            Assignee: Jesse McConnell
>             Fix For: 7.0.0.pre6, 6.1.15.pre0
>
>         Attachments: jetty-bug.tar
>
>
> From the jetty mailing lists:
> I'm seeing an odd issue with Jetty 6.1.x with continuations and select-style NIO when a client is sending a chunked request that consists of a few chunks.  The intended use case is that request processing occurs in the background, so the implementation forks a thread to consume the InputStream from the request and then suspend() is called on the continuation.

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

[jira] Commented: (JETTY-586) Input stream is corrupted when reading via a spawned thread with jetty thread in suspended state.

JIRA jira@codehaus.org
In reply to this post by JIRA jira@codehaus.org

    [ http://jira.codehaus.org/browse/JETTY-586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159920#action_159920 ]

David Yu commented on JETTY-586:
--------------------------------

I just retried the test-case on windows+java1.5+jetty-6.1.10, I got the ff:

Exception in thread "pool-1-thread-3" java.lang.RuntimeException: java.io.IOExce
ption: bad chunk char: 61
        at us.ifario.mult.EchoServlet$Printer.run(EchoServlet.java:55)
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExec
utor.java:650)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor
.java:675)
        at java.lang.Thread.run(Thread.java:595)
Caused by: java.io.IOException: bad chunk char: 61
        at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:694)
        at org.mortbay.jetty.HttpParser$Input.blockForContent(HttpParser.java:10
38)
        at org.mortbay.jetty.HttpParser$Input.read(HttpParser.java:999)
        at java.io.InputStream.read(InputStream.java:89)
        at us.ifario.mult.EchoServlet$Printer.run(EchoServlet.java:49)
        ... 3 more
2009-01-05 16:38:09.691::WARN:  handle failed
java.io.IOException: bad chunk char: 38
        at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:694)
        at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:205)
        at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:380)
        at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.ja
va:395)
        at org.mortbay.jetty.nio.SelectChannelConnector$RetryContinuation.run(Se
lectChannelConnector.java:506)
        at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.j
ava:488)

> Input stream is corrupted when reading via a spawned thread with jetty thread in suspended state.
> -------------------------------------------------------------------------------------------------
>
>                 Key: JETTY-586
>                 URL: http://jira.codehaus.org/browse/JETTY-586
>             Project: Jetty
>          Issue Type: Bug
>          Components: Continuations
>            Reporter: Jan Bartel
>            Assignee: Jesse McConnell
>             Fix For: 7.0.0.pre6, 6.1.15.pre0
>
>         Attachments: jetty-bug.tar
>
>
> From the jetty mailing lists:
> I'm seeing an odd issue with Jetty 6.1.x with continuations and select-style NIO when a client is sending a chunked request that consists of a few chunks.  The intended use case is that request processing occurs in the background, so the implementation forks a thread to consume the InputStream from the request and then suspend() is called on the continuation.

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

[jira] Commented: (JETTY-586) Input stream is corrupted when reading via a spawned thread with jetty thread in suspended state.

JIRA jira@codehaus.org
In reply to this post by JIRA jira@codehaus.org

    [ http://jira.codehaus.org/browse/JETTY-586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159921#action_159921 ]

David Yu commented on JETTY-586:
--------------------------------

windows+java1.5+jetty-6.1.14 as well.



> Input stream is corrupted when reading via a spawned thread with jetty thread in suspended state.
> -------------------------------------------------------------------------------------------------
>
>                 Key: JETTY-586
>                 URL: http://jira.codehaus.org/browse/JETTY-586
>             Project: Jetty
>          Issue Type: Bug
>          Components: Continuations
>            Reporter: Jan Bartel
>            Assignee: Jesse McConnell
>             Fix For: 7.0.0.pre6, 6.1.15.pre0
>
>         Attachments: jetty-bug.tar
>
>
> From the jetty mailing lists:
> I'm seeing an odd issue with Jetty 6.1.x with continuations and select-style NIO when a client is sending a chunked request that consists of a few chunks.  The intended use case is that request processing occurs in the background, so the implementation forks a thread to consume the InputStream from the request and then suspend() is called on the continuation.

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

RequestLog and org.mortbay.jetty.Request

Ceki Gulcu

Hello all,

We have developed an implementation of the
org.mortbay.jetty.RequestLog interface, named
ch.qos.logback.access.jetty.RequestLogImpl.  It ships with
logback-access (licensed under LGPL).  This implementation offers very
extensive logging capabilities, such as split logging output according
to dynamic criteria (e.g. per user), logging to a database, syslog
daemon, remote server and much more.

Given its extensive capabilities, our RequestLogImpl maintains a
reference about its internal status in a data structure so that users
can debug problems encountered by RequestLogImpl (typically
configuration problems).

We would like to expose this data structure (containing internal
messages) to an HttpServlet which then print these internal message in
a user-friendly format.

Here is a simplified version of RequestLogImpl code:

package ch.qos.logback.access.jetty;

import org.mortbay.jetty.Request;
import org.mortbay.jetty.RequestLog;
import org.mortbay.jetty.Response;

public class RequestLogImpl implements RequestLog {

       public void log(Request jettyRequest, Response jettyResponse) {
         ServletContext sc = jettyRequest.getContext();
         // servlet context is always null
         if (sc != null) {
           sc.setAttribute("someKey", internalStatusMessages);
         }

         // actual logging code omitted...
       }
}

Actual code for RequestLogImpl can be found at

        http://tinyurl.com/9wxvow


As can be seen above, we could like to push the
"internalStatusMessages" data structure into the ServletContext.
However, the servlet context obtained by calling the getContext()
method of the jettyRequest seems to always return null. We have also
noticed that the RequestLogImpl.log method is called after the http
request has been served (which is OK).

Is there a simple way to pass a data structure from a RequestLog
implementation to a servlet? Note that the RequestLog code can and
will depend on jetty. However, we do not wish to have the servlet
depend on jetty.

Many thanks for your guidance and wishing you all a happy new year.
--
Ceki Gülcü
Logback: The reliable, generic, fast and flexible logging framework for Java.
http://logback.qos.ch

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: RequestLog and org.mortbay.jetty.Request

Jan Bartel
Hi Ceki,

The context will only be set for the length of time that the
request is in the ContextHandler - as part of the finally block
for the exit of that handler it resets the context, which will
be null in this case (if it was a forward or include going back
into the ContextHandler, then it wouldn't be null, but then that
that wouldn't be logged in the request log either).

What about using a Request attribute instead? That's still a
container agnostic mechanism.


Happy New Year to you too!
Jan


Ceki Gulcu wrote:

>
> Hello all,
>
> We have developed an implementation of the
> org.mortbay.jetty.RequestLog interface, named
> ch.qos.logback.access.jetty.RequestLogImpl.  It ships with
> logback-access (licensed under LGPL).  This implementation offers very
> extensive logging capabilities, such as split logging output according
> to dynamic criteria (e.g. per user), logging to a database, syslog
> daemon, remote server and much more.
>
> Given its extensive capabilities, our RequestLogImpl maintains a
> reference about its internal status in a data structure so that users
> can debug problems encountered by RequestLogImpl (typically
> configuration problems).
>
> We would like to expose this data structure (containing internal
> messages) to an HttpServlet which then print these internal message in
> a user-friendly format.
>
> Here is a simplified version of RequestLogImpl code:
>
> package ch.qos.logback.access.jetty;
>
> import org.mortbay.jetty.Request;
> import org.mortbay.jetty.RequestLog;
> import org.mortbay.jetty.Response;
>
> public class RequestLogImpl implements RequestLog {
>
>       public void log(Request jettyRequest, Response jettyResponse) {
>         ServletContext sc = jettyRequest.getContext();
>         // servlet context is always null
>         if (sc != null) {
>           sc.setAttribute("someKey", internalStatusMessages);
>         }
>
>         // actual logging code omitted...
>       }
> }
>
> Actual code for RequestLogImpl can be found at
>
>        http://tinyurl.com/9wxvow
>
>
> As can be seen above, we could like to push the
> "internalStatusMessages" data structure into the ServletContext.
> However, the servlet context obtained by calling the getContext()
> method of the jettyRequest seems to always return null. We have also
> noticed that the RequestLogImpl.log method is called after the http
> request has been served (which is OK).
>
> Is there a simple way to pass a data structure from a RequestLog
> implementation to a servlet? Note that the RequestLog code can and
> will depend on jetty. However, we do not wish to have the servlet
> depend on jetty.
>
> Many thanks for your guidance and wishing you all a happy new year.


--
Jan Bartel, Webtide LLC | [hidden email] | http://www.webtide.com

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: RequestLog and org.mortbay.jetty.Request

Ceki Gulcu
Hi Jan,

Thank you for your response. I tried the Request attribute. Unfortunately, since
the RequestLogImpl.log method is called *after* the http request has been
served, setting the request attribute has no affect (the HttpServlet.service
method does not see the request attribute).

Would you have any other suggestions?

Jan Bartel wrote:

> Hi Ceki,
>
> The context will only be set for the length of time that the
> request is in the ContextHandler - as part of the finally block
> for the exit of that handler it resets the context, which will
> be null in this case (if it was a forward or include going back
> into the ContextHandler, then it wouldn't be null, but then that
> that wouldn't be logged in the request log either).
>
> What about using a Request attribute instead? That's still a
> container agnostic mechanism.
>
>
> Happy New Year to you too!
> Jan
>
>
> Ceki Gulcu wrote:
>> Hello all,
>>
>> We have developed an implementation of the
>> org.mortbay.jetty.RequestLog interface, named
>> ch.qos.logback.access.jetty.RequestLogImpl.  It ships with
>> logback-access (licensed under LGPL).  This implementation offers very
>> extensive logging capabilities, such as split logging output according
>> to dynamic criteria (e.g. per user), logging to a database, syslog
>> daemon, remote server and much more.
>>
>> Given its extensive capabilities, our RequestLogImpl maintains a
>> reference about its internal status in a data structure so that users
>> can debug problems encountered by RequestLogImpl (typically
>> configuration problems).
>>
>> We would like to expose this data structure (containing internal
>> messages) to an HttpServlet which then print these internal message in
>> a user-friendly format.
>>
>> Here is a simplified version of RequestLogImpl code:
>>
>> package ch.qos.logback.access.jetty;
>>
>> import org.mortbay.jetty.Request;
>> import org.mortbay.jetty.RequestLog;
>> import org.mortbay.jetty.Response;
>>
>> public class RequestLogImpl implements RequestLog {
>>
>>       public void log(Request jettyRequest, Response jettyResponse) {
>>         ServletContext sc = jettyRequest.getContext();
>>         // servlet context is always null
>>         if (sc != null) {
>>           sc.setAttribute("someKey", internalStatusMessages);
>>         }
>>
>>         // actual logging code omitted...
>>       }
>> }
>>
>> Actual code for RequestLogImpl can be found at
>>
>>        http://tinyurl.com/9wxvow
>>
>>
>> As can be seen above, we could like to push the
>> "internalStatusMessages" data structure into the ServletContext.
>> However, the servlet context obtained by calling the getContext()
>> method of the jettyRequest seems to always return null. We have also
>> noticed that the RequestLogImpl.log method is called after the http
>> request has been served (which is OK).
>>
>> Is there a simple way to pass a data structure from a RequestLog
>> implementation to a servlet? Note that the RequestLog code can and
>> will depend on jetty. However, we do not wish to have the servlet
>> depend on jetty.
>>
>> Many thanks for your guidance and wishing you all a happy new year.
>
>

--
Ceki Gülcü
Logback: The reliable, generic, fast and flexible logging framework for Java.
http://logback.qos.ch

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: RequestLog and org.mortbay.jetty.Request

Ceki Gulcu

I have also tried setting a session attribute. However, within
RequestLogImpl.log method there seems to be no SessionHandler or SessionManager.
I get:

java.lang.IllegalStateException: No SessionHandler or SessionManager
    at org.mortbay.jetty.Request.getSession(Request.java:1131)
    at org.mortbay.jetty.Request.getSession(Request.java:1121)
    at ch.qos.logback.access.jetty.RequestLogImpl.log(RequestLogImpl.java:120)
    at org.mortbay.jetty.handler.RequestLogHandler.handle(RequestLogHandler.java:51)
    at
org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
    at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
    at org.mortbay.jetty.Server.handle(Server.java:324)
    at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:534)
    at
org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:864)
    at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:533)
    at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:207)
    at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:403)
    at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:409)
    at
org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:451)


I am stumped.

Ceki Gulcu wrote:

> Hi Jan,
>
> Thank you for your response. I tried the Request attribute.
> Unfortunately, since the RequestLogImpl.log method is called *after* the
> http request has been served, setting the request attribute has no
> affect (the HttpServlet.service method does not see the request attribute).
>
> Would you have any other suggestions?
>
> Jan Bartel wrote:
>> Hi Ceki,
>>
>> The context will only be set for the length of time that the request
>> is in the ContextHandler - as part of the finally block
>> for the exit of that handler it resets the context, which will
>> be null in this case (if it was a forward or include going back
>> into the ContextHandler, then it wouldn't be null, but then that
>> that wouldn't be logged in the request log either).
>>
>> What about using a Request attribute instead? That's still a
>> container agnostic mechanism.
>>
>>
>> Happy New Year to you too!
>> Jan
>>
>>
>> Ceki Gulcu wrote:
>>> Hello all,
>>>
>>> We have developed an implementation of the
>>> org.mortbay.jetty.RequestLog interface, named
>>> ch.qos.logback.access.jetty.RequestLogImpl.  It ships with
>>> logback-access (licensed under LGPL).  This implementation offers very
>>> extensive logging capabilities, such as split logging output according
>>> to dynamic criteria (e.g. per user), logging to a database, syslog
>>> daemon, remote server and much more.
>>>
>>> Given its extensive capabilities, our RequestLogImpl maintains a
>>> reference about its internal status in a data structure so that users
>>> can debug problems encountered by RequestLogImpl (typically
>>> configuration problems).
>>>
>>> We would like to expose this data structure (containing internal
>>> messages) to an HttpServlet which then print these internal message in
>>> a user-friendly format.
>>>
>>> Here is a simplified version of RequestLogImpl code:
>>>
>>> package ch.qos.logback.access.jetty;
>>>
>>> import org.mortbay.jetty.Request;
>>> import org.mortbay.jetty.RequestLog;
>>> import org.mortbay.jetty.Response;
>>>
>>> public class RequestLogImpl implements RequestLog {
>>>
>>>       public void log(Request jettyRequest, Response jettyResponse) {
>>>         ServletContext sc = jettyRequest.getContext();
>>>         // servlet context is always null
>>>         if (sc != null) {
>>>           sc.setAttribute("someKey", internalStatusMessages);
>>>         }
>>>
>>>         // actual logging code omitted...
>>>       }
>>> }
>>>
>>> Actual code for RequestLogImpl can be found at
>>>
>>>        http://tinyurl.com/9wxvow
>>>
>>>
>>> As can be seen above, we could like to push the
>>> "internalStatusMessages" data structure into the ServletContext.
>>> However, the servlet context obtained by calling the getContext()
>>> method of the jettyRequest seems to always return null. We have also
>>> noticed that the RequestLogImpl.log method is called after the http
>>> request has been served (which is OK).
>>>
>>> Is there a simple way to pass a data structure from a RequestLog
>>> implementation to a servlet? Note that the RequestLog code can and
>>> will depend on jetty. However, we do not wish to have the servlet
>>> depend on jetty.
>>>
>>> Many thanks for your guidance and wishing you all a happy new year.
>>
>>
>

--
Ceki Gülcü
Logback: The reliable, generic, fast and flexible logging framework for Java.
http://logback.qos.ch

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


12