[jira] Created: (JETTY-331) Jetty HashSessionIdManager hangs on startup

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

[jira] Created: (JETTY-331) Jetty HashSessionIdManager hangs on startup

JIRA jira@codehaus.org
Jetty HashSessionIdManager hangs on startup
-------------------------------------------

                 Key: JETTY-331
                 URL: http://jira.codehaus.org/browse/JETTY-331
             Project: Jetty
          Issue Type: Bug
          Components: Security and SSL, Servlet
    Affects Versions: 6.1.1, 6.1.2rc4
         Environment: JDK 1.5, 1.6
tested with Jetty 6.1.1, 6.1.1rc4, 6.1.1rc5
User Mode Linux
Linux XXXXX 2.6.20-XXXXX #1 Mon Feb 19 20:31:43 EST 2007 i686 i686 i386 GNU/Linux

            Reporter: Aaron Hamid


In my Linux environment, the HashSessionIdManager in its default configuration hangs on startup, preventing Jetty from starting up (and binding to a port, etc.).  As inspected through JConsole, the SessionIdManager is in the 'starting' state, but  never reaches the 'started' state.  The stack trace of the 'main' thread is as follows:

#
Stack trace:
#
java.io.FileInputStream.readBytes(Native Method)
#
java.io.FileInputStream.read(FileInputStream.java:199)
#
java.io.BufferedInputStream.read1(BufferedInputStream.java:256)
#
java.io.BufferedInputStream.read(BufferedInputStream.java:317)
#
java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
#
java.io.BufferedInputStream.read1(BufferedInputStream.java:258)
#
java.io.BufferedInputStream.read(BufferedInputStream.java:317)
#
sun.security.provider.SeedGenerator$URLSeedGenerator.getSeedByte(SeedGenerator.java:453)
#
sun.security.provider.SeedGenerator.getSeedBytes(SeedGenerator.java:123)
#
sun.security.provider.SeedGenerator.generateSeed(SeedGenerator.java:118)
#
sun.security.provider.SecureRandom.engineGenerateSeed(SecureRandom.java:114)
#
sun.security.provider.SecureRandom.engineNextBytes(SecureRandom.java:171)
#
java.security.SecureRandom.nextBytes(SecureRandom.java:433)
#
java.security.SecureRandom.next(SecureRandom.java:455)
#
java.util.Random.nextLong(Random.java:284)
#
org.mortbay.jetty.servlet.HashSessionIdManager.doStart(HashSessionIdManager.java:105)
#
org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40)
#
org.mortbay.jetty.servlet.AbstractSessionManager.doStart(AbstractSessionManager.java:166)
#
org.mortbay.jetty.servlet.HashSessionManager.doStart(HashSessionManager.java:53)


Some googling revealed that there was a known issue with SecureRandom on Linux in prior versions of the JDK, which was configured to read from /dev/random, which is blocking on Linux.  Indeed /dev/random does block, however under 1.5 and 1.6, the configuration has changed to use /dev/urandom.  I also tested explicitly setting the java.security.egd property to file:/dev/urandom.  Neither of these solve the problem.  Ultimately I found a solution: explicitly passing a java.util.Random (NOT a java.security.SecureRandom) to the HashSessionIdManager:

<Set name="sessionIdManager">
      <New class="org.mortbay.jetty.servlet.HashSessionIdManager">
        <Arg>
          <!-- MUST explicitly set to java.util.Random -->
          <New class="java.util.Random"/>
        </Arg>
        <Set name="workerName">node1</Set>
      </New>
    </Set>

There are several possible issues here:

1. Maybe User Mode Linux is somehow interfering with the JDK SecureRandom API.  Despite all settings appearing to be correct (and a test case using SecureRandom appearing to work), HashSessionIdManager still hangs by default.
2. HashSessionIdManager (or some other jetty code) is doing something nefarious...like trying to read /dev/random and blocking (interestingly, JConsole indicated that the main thread was not blocked, but running...)
3. This is simply "known behavior" that is not documented anywhere.  If so, it should be documented because it is very difficult to diagnose.

I can reproduce this on-demand if needed.

Thank you

--
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

       

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
jetty-discuss mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-discuss
Reply | Threaded
Open this post in threaded view
|

[jira] Commented: (JETTY-331) Jetty HashSessionIdManager hangs on startup

JIRA jira@codehaus.org

    [ http://jira.codehaus.org/browse/JETTY-331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_94722 ]

Greg Wilkins commented on JETTY-331:
------------------------------------

Thanks for the information.   I had not seen this before!
I will leave this issue open until we document on the wiki.



> Jetty HashSessionIdManager hangs on startup
> -------------------------------------------
>
>                 Key: JETTY-331
>                 URL: http://jira.codehaus.org/browse/JETTY-331
>             Project: Jetty
>          Issue Type: Bug
>          Components: Security and SSL, Servlet
>    Affects Versions: 6.1.1, 6.1.2rc4
>         Environment: JDK 1.5, 1.6
> tested with Jetty 6.1.1, 6.1.1rc4, 6.1.1rc5
> User Mode Linux
> Linux XXXXX 2.6.20-XXXXX #1 Mon Feb 19 20:31:43 EST 2007 i686 i686 i386 GNU/Linux
>            Reporter: Aaron Hamid
>
> In my Linux environment, the HashSessionIdManager in its default configuration hangs on startup, preventing Jetty from starting up (and binding to a port, etc.).  As inspected through JConsole, the SessionIdManager is in the 'starting' state, but  never reaches the 'started' state.  The stack trace of the 'main' thread is as follows:
> #
> Stack trace:
> #
> java.io.FileInputStream.readBytes(Native Method)
> #
> java.io.FileInputStream.read(FileInputStream.java:199)
> #
> java.io.BufferedInputStream.read1(BufferedInputStream.java:256)
> #
> java.io.BufferedInputStream.read(BufferedInputStream.java:317)
> #
> java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
> #
> java.io.BufferedInputStream.read1(BufferedInputStream.java:258)
> #
> java.io.BufferedInputStream.read(BufferedInputStream.java:317)
> #
> sun.security.provider.SeedGenerator$URLSeedGenerator.getSeedByte(SeedGenerator.java:453)
> #
> sun.security.provider.SeedGenerator.getSeedBytes(SeedGenerator.java:123)
> #
> sun.security.provider.SeedGenerator.generateSeed(SeedGenerator.java:118)
> #
> sun.security.provider.SecureRandom.engineGenerateSeed(SecureRandom.java:114)
> #
> sun.security.provider.SecureRandom.engineNextBytes(SecureRandom.java:171)
> #
> java.security.SecureRandom.nextBytes(SecureRandom.java:433)
> #
> java.security.SecureRandom.next(SecureRandom.java:455)
> #
> java.util.Random.nextLong(Random.java:284)
> #
> org.mortbay.jetty.servlet.HashSessionIdManager.doStart(HashSessionIdManager.java:105)
> #
> org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40)
> #
> org.mortbay.jetty.servlet.AbstractSessionManager.doStart(AbstractSessionManager.java:166)
> #
> org.mortbay.jetty.servlet.HashSessionManager.doStart(HashSessionManager.java:53)
> Some googling revealed that there was a known issue with SecureRandom on Linux in prior versions of the JDK, which was configured to read from /dev/random, which is blocking on Linux.  Indeed /dev/random does block, however under 1.5 and 1.6, the configuration has changed to use /dev/urandom.  I also tested explicitly setting the java.security.egd property to file:/dev/urandom.  Neither of these solve the problem.  Ultimately I found a solution: explicitly passing a java.util.Random (NOT a java.security.SecureRandom) to the HashSessionIdManager:
> <Set name="sessionIdManager">
>       <New class="org.mortbay.jetty.servlet.HashSessionIdManager">
>         <Arg>
>           <!-- MUST explicitly set to java.util.Random -->
>           <New class="java.util.Random"/>
>         </Arg>
>         <Set name="workerName">node1</Set>
>       </New>
>     </Set>
> There are several possible issues here:
> 1. Maybe User Mode Linux is somehow interfering with the JDK SecureRandom API.  Despite all settings appearing to be correct (and a test case using SecureRandom appearing to work), HashSessionIdManager still hangs by default.
> 2. HashSessionIdManager (or some other jetty code) is doing something nefarious...like trying to read /dev/random and blocking (interestingly, JConsole indicated that the main thread was not blocked, but running...)
> 3. This is simply "known behavior" that is not documented anywhere.  If so, it should be documented because it is very difficult to diagnose.
> I can reproduce this on-demand if needed.
> Thank you

--
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

       

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
jetty-discuss mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-discuss
Reply | Threaded
Open this post in threaded view
|

Re: [jira] Created: (JETTY-331) Jetty HashSessionIdManager hangs on startup

Russell Howe
In reply to this post by JIRA jira@codehaus.org
On Tue, May 01, 2007 at 04:35:26PM -0500, Aaron Hamid (JIRA) wrote:

>             Reporter: Aaron Hamid
>
>
> In my Linux environment, the HashSessionIdManager in its default configuration hangs on startup, preventing Jetty from starting up (and binding to a port, etc.).  As inspected through JConsole, the SessionIdManager is in the 'starting' state, but  never reaches the 'started' state.  The stack trace of the 'main' thread is as follows:
>
> #
> Stack trace:
> #
> java.io.FileInputStream.readBytes(Native Method)
> #
> java.io.FileInputStream.read(FileInputStream.java:199)
> #
[snip]

> #
> sun.security.provider.SeedGenerator$URLSeedGenerator.getSeedByte(SeedGenerator.java:453)
> #
> sun.security.provider.SeedGenerator.getSeedBytes(SeedGenerator.java:123)
> #
> sun.security.provider.SeedGenerator.generateSeed(SeedGenerator.java:118)
> #
> sun.security.provider.SecureRandom.engineGenerateSeed(SecureRandom.java:114)
>
> Some googling revealed that there was a known issue with SecureRandom on Linux in prior versions of the JDK, which was configured to read from /dev/random, which is blocking on Linux.  Indeed /dev/random does block, however under 1.5 and 1.6, the configuration has changed to use /dev/urandom.  I also tested explicitly setting the java.security.egd property to file:/dev/urandom.  Neither of these solve the problem.  Ultimately I found a solution: explicitly passing a java.util.Random (NOT a java.security.SecureRandom) to the HashSessionIdManager:

ISTR that when I was using UML I had problems with the kernel not
gathering enough entropy for /dev/random to function. I'm pretty sure
that if you strace java, you'll find it's trying to access /dev/random,
despite what you request.

Not sure what the resolution was - you could be evil and do:

cd /dev && ln -s {u,}random

You /are/ running a recent UML kernel, right? Could be that the bug is
fixed (no doubt the emulated network interface and disk aren't
contributing to the entropy pool). I had a similar problem on a Soekris
embedded box where the relevant entropy-feeding function wasn't being
called by the NIC driver, the filesystem was mounted readonly and
noatime (so activity was minimal) and there was no user input since it
was headless with a serial console. sshd was unable to receive
connections and IPsec would hang waiting for sufficient entropy to
rekey! IIRC the driver for the ethernet chip eventually received a fix
which made it contribute to the entropy pool

--
Russell Howe       | Why be just another cog in the machine,
[hidden email] | when you can be the spanner in the works?

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
jetty-discuss mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-discuss
Reply | Threaded
Open this post in threaded view
|

[jira] Assigned: (JETTY-331) Jetty HashSessionIdManager hangs on startup

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

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

Greg Wilkins reassigned JETTY-331:
----------------------------------

    Assignee: Greg Wilkins

> Jetty HashSessionIdManager hangs on startup
> -------------------------------------------
>
>                 Key: JETTY-331
>                 URL: http://jira.codehaus.org/browse/JETTY-331
>             Project: Jetty
>          Issue Type: Bug
>          Components: Security and SSL, Servlet
>    Affects Versions: 6.1.1, 6.1.2rc4
>         Environment: JDK 1.5, 1.6
> tested with Jetty 6.1.1, 6.1.1rc4, 6.1.1rc5
> User Mode Linux
> Linux XXXXX 2.6.20-XXXXX #1 Mon Feb 19 20:31:43 EST 2007 i686 i686 i386 GNU/Linux
>            Reporter: Aaron Hamid
>            Assignee: Greg Wilkins
>
> In my Linux environment, the HashSessionIdManager in its default configuration hangs on startup, preventing Jetty from starting up (and binding to a port, etc.).  As inspected through JConsole, the SessionIdManager is in the 'starting' state, but  never reaches the 'started' state.  The stack trace of the 'main' thread is as follows:
> #
> Stack trace:
> #
> java.io.FileInputStream.readBytes(Native Method)
> #
> java.io.FileInputStream.read(FileInputStream.java:199)
> #
> java.io.BufferedInputStream.read1(BufferedInputStream.java:256)
> #
> java.io.BufferedInputStream.read(BufferedInputStream.java:317)
> #
> java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
> #
> java.io.BufferedInputStream.read1(BufferedInputStream.java:258)
> #
> java.io.BufferedInputStream.read(BufferedInputStream.java:317)
> #
> sun.security.provider.SeedGenerator$URLSeedGenerator.getSeedByte(SeedGenerator.java:453)
> #
> sun.security.provider.SeedGenerator.getSeedBytes(SeedGenerator.java:123)
> #
> sun.security.provider.SeedGenerator.generateSeed(SeedGenerator.java:118)
> #
> sun.security.provider.SecureRandom.engineGenerateSeed(SecureRandom.java:114)
> #
> sun.security.provider.SecureRandom.engineNextBytes(SecureRandom.java:171)
> #
> java.security.SecureRandom.nextBytes(SecureRandom.java:433)
> #
> java.security.SecureRandom.next(SecureRandom.java:455)
> #
> java.util.Random.nextLong(Random.java:284)
> #
> org.mortbay.jetty.servlet.HashSessionIdManager.doStart(HashSessionIdManager.java:105)
> #
> org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40)
> #
> org.mortbay.jetty.servlet.AbstractSessionManager.doStart(AbstractSessionManager.java:166)
> #
> org.mortbay.jetty.servlet.HashSessionManager.doStart(HashSessionManager.java:53)
> Some googling revealed that there was a known issue with SecureRandom on Linux in prior versions of the JDK, which was configured to read from /dev/random, which is blocking on Linux.  Indeed /dev/random does block, however under 1.5 and 1.6, the configuration has changed to use /dev/urandom.  I also tested explicitly setting the java.security.egd property to file:/dev/urandom.  Neither of these solve the problem.  Ultimately I found a solution: explicitly passing a java.util.Random (NOT a java.security.SecureRandom) to the HashSessionIdManager:
> <Set name="sessionIdManager">
>       <New class="org.mortbay.jetty.servlet.HashSessionIdManager">
>         <Arg>
>           <!-- MUST explicitly set to java.util.Random -->
>           <New class="java.util.Random"/>
>         </Arg>
>         <Set name="workerName">node1</Set>
>       </New>
>     </Set>
> There are several possible issues here:
> 1. Maybe User Mode Linux is somehow interfering with the JDK SecureRandom API.  Despite all settings appearing to be correct (and a test case using SecureRandom appearing to work), HashSessionIdManager still hangs by default.
> 2. HashSessionIdManager (or some other jetty code) is doing something nefarious...like trying to read /dev/random and blocking (interestingly, JConsole indicated that the main thread was not blocked, but running...)
> 3. This is simply "known behavior" that is not documented anywhere.  If so, it should be documented because it is very difficult to diagnose.
> I can reproduce this on-demand if needed.
> Thank you

--
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

       

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
jetty-discuss mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-discuss
Reply | Threaded
Open this post in threaded view
|

[jira] Updated: (JETTY-331) Jetty HashSessionIdManager hangs on startup

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

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

Greg Wilkins updated JETTY-331:
-------------------------------

    Issue Type: Improvement  (was: Bug)

> Jetty HashSessionIdManager hangs on startup
> -------------------------------------------
>
>                 Key: JETTY-331
>                 URL: http://jira.codehaus.org/browse/JETTY-331
>             Project: Jetty
>          Issue Type: Improvement
>          Components: Security and SSL, Servlet
>    Affects Versions: 6.1.1, 6.1.2rc4
>         Environment: JDK 1.5, 1.6
> tested with Jetty 6.1.1, 6.1.1rc4, 6.1.1rc5
> User Mode Linux
> Linux XXXXX 2.6.20-XXXXX #1 Mon Feb 19 20:31:43 EST 2007 i686 i686 i386 GNU/Linux
>            Reporter: Aaron Hamid
>            Assignee: Greg Wilkins
>
> In my Linux environment, the HashSessionIdManager in its default configuration hangs on startup, preventing Jetty from starting up (and binding to a port, etc.).  As inspected through JConsole, the SessionIdManager is in the 'starting' state, but  never reaches the 'started' state.  The stack trace of the 'main' thread is as follows:
> #
> Stack trace:
> #
> java.io.FileInputStream.readBytes(Native Method)
> #
> java.io.FileInputStream.read(FileInputStream.java:199)
> #
> java.io.BufferedInputStream.read1(BufferedInputStream.java:256)
> #
> java.io.BufferedInputStream.read(BufferedInputStream.java:317)
> #
> java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
> #
> java.io.BufferedInputStream.read1(BufferedInputStream.java:258)
> #
> java.io.BufferedInputStream.read(BufferedInputStream.java:317)
> #
> sun.security.provider.SeedGenerator$URLSeedGenerator.getSeedByte(SeedGenerator.java:453)
> #
> sun.security.provider.SeedGenerator.getSeedBytes(SeedGenerator.java:123)
> #
> sun.security.provider.SeedGenerator.generateSeed(SeedGenerator.java:118)
> #
> sun.security.provider.SecureRandom.engineGenerateSeed(SecureRandom.java:114)
> #
> sun.security.provider.SecureRandom.engineNextBytes(SecureRandom.java:171)
> #
> java.security.SecureRandom.nextBytes(SecureRandom.java:433)
> #
> java.security.SecureRandom.next(SecureRandom.java:455)
> #
> java.util.Random.nextLong(Random.java:284)
> #
> org.mortbay.jetty.servlet.HashSessionIdManager.doStart(HashSessionIdManager.java:105)
> #
> org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40)
> #
> org.mortbay.jetty.servlet.AbstractSessionManager.doStart(AbstractSessionManager.java:166)
> #
> org.mortbay.jetty.servlet.HashSessionManager.doStart(HashSessionManager.java:53)
> Some googling revealed that there was a known issue with SecureRandom on Linux in prior versions of the JDK, which was configured to read from /dev/random, which is blocking on Linux.  Indeed /dev/random does block, however under 1.5 and 1.6, the configuration has changed to use /dev/urandom.  I also tested explicitly setting the java.security.egd property to file:/dev/urandom.  Neither of these solve the problem.  Ultimately I found a solution: explicitly passing a java.util.Random (NOT a java.security.SecureRandom) to the HashSessionIdManager:
> <Set name="sessionIdManager">
>       <New class="org.mortbay.jetty.servlet.HashSessionIdManager">
>         <Arg>
>           <!-- MUST explicitly set to java.util.Random -->
>           <New class="java.util.Random"/>
>         </Arg>
>         <Set name="workerName">node1</Set>
>       </New>
>     </Set>
> There are several possible issues here:
> 1. Maybe User Mode Linux is somehow interfering with the JDK SecureRandom API.  Despite all settings appearing to be correct (and a test case using SecureRandom appearing to work), HashSessionIdManager still hangs by default.
> 2. HashSessionIdManager (or some other jetty code) is doing something nefarious...like trying to read /dev/random and blocking (interestingly, JConsole indicated that the main thread was not blocked, but running...)
> 3. This is simply "known behavior" that is not documented anywhere.  If so, it should be documented because it is very difficult to diagnose.
> I can reproduce this on-demand if needed.
> Thank you

--
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

       

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
jetty-discuss mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-discuss
Reply | Threaded
Open this post in threaded view
|

[jira] Closed: (JETTY-331) Jetty HashSessionIdManager hangs on startup

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

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

Greg Wilkins closed JETTY-331.
------------------------------

    Resolution: Won't Fix

> Jetty HashSessionIdManager hangs on startup
> -------------------------------------------
>
>                 Key: JETTY-331
>                 URL: http://jira.codehaus.org/browse/JETTY-331
>             Project: Jetty
>          Issue Type: Improvement
>          Components: Security and SSL, Servlet
>    Affects Versions: 6.1.1, 6.1.2rc4
>         Environment: JDK 1.5, 1.6
> tested with Jetty 6.1.1, 6.1.1rc4, 6.1.1rc5
> User Mode Linux
> Linux XXXXX 2.6.20-XXXXX #1 Mon Feb 19 20:31:43 EST 2007 i686 i686 i386 GNU/Linux
>            Reporter: Aaron Hamid
>            Assignee: Greg Wilkins
>
> In my Linux environment, the HashSessionIdManager in its default configuration hangs on startup, preventing Jetty from starting up (and binding to a port, etc.).  As inspected through JConsole, the SessionIdManager is in the 'starting' state, but  never reaches the 'started' state.  The stack trace of the 'main' thread is as follows:
> #
> Stack trace:
> #
> java.io.FileInputStream.readBytes(Native Method)
> #
> java.io.FileInputStream.read(FileInputStream.java:199)
> #
> java.io.BufferedInputStream.read1(BufferedInputStream.java:256)
> #
> java.io.BufferedInputStream.read(BufferedInputStream.java:317)
> #
> java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
> #
> java.io.BufferedInputStream.read1(BufferedInputStream.java:258)
> #
> java.io.BufferedInputStream.read(BufferedInputStream.java:317)
> #
> sun.security.provider.SeedGenerator$URLSeedGenerator.getSeedByte(SeedGenerator.java:453)
> #
> sun.security.provider.SeedGenerator.getSeedBytes(SeedGenerator.java:123)
> #
> sun.security.provider.SeedGenerator.generateSeed(SeedGenerator.java:118)
> #
> sun.security.provider.SecureRandom.engineGenerateSeed(SecureRandom.java:114)
> #
> sun.security.provider.SecureRandom.engineNextBytes(SecureRandom.java:171)
> #
> java.security.SecureRandom.nextBytes(SecureRandom.java:433)
> #
> java.security.SecureRandom.next(SecureRandom.java:455)
> #
> java.util.Random.nextLong(Random.java:284)
> #
> org.mortbay.jetty.servlet.HashSessionIdManager.doStart(HashSessionIdManager.java:105)
> #
> org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40)
> #
> org.mortbay.jetty.servlet.AbstractSessionManager.doStart(AbstractSessionManager.java:166)
> #
> org.mortbay.jetty.servlet.HashSessionManager.doStart(HashSessionManager.java:53)
> Some googling revealed that there was a known issue with SecureRandom on Linux in prior versions of the JDK, which was configured to read from /dev/random, which is blocking on Linux.  Indeed /dev/random does block, however under 1.5 and 1.6, the configuration has changed to use /dev/urandom.  I also tested explicitly setting the java.security.egd property to file:/dev/urandom.  Neither of these solve the problem.  Ultimately I found a solution: explicitly passing a java.util.Random (NOT a java.security.SecureRandom) to the HashSessionIdManager:
> <Set name="sessionIdManager">
>       <New class="org.mortbay.jetty.servlet.HashSessionIdManager">
>         <Arg>
>           <!-- MUST explicitly set to java.util.Random -->
>           <New class="java.util.Random"/>
>         </Arg>
>         <Set name="workerName">node1</Set>
>       </New>
>     </Set>
> There are several possible issues here:
> 1. Maybe User Mode Linux is somehow interfering with the JDK SecureRandom API.  Despite all settings appearing to be correct (and a test case using SecureRandom appearing to work), HashSessionIdManager still hangs by default.
> 2. HashSessionIdManager (or some other jetty code) is doing something nefarious...like trying to read /dev/random and blocking (interestingly, JConsole indicated that the main thread was not blocked, but running...)
> 3. This is simply "known behavior" that is not documented anywhere.  If so, it should be documented because it is very difficult to diagnose.
> I can reproduce this on-demand if needed.
> Thank you

--
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

       

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
jetty-discuss mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-discuss