Delay in starting of Connectors

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

Delay in starting of Connectors

Silvio Bierman
Hello all,

I am running an embedded Jetty 6.1.5 on a Debian 4 server. For some
reason when I restart my processes (currently I have five processes
embedding Jetty running concurrently) and I watch the console outputs I
see this:

2008-03-12 10:28:02.482::INFO:  Logging to STDERR via
org.mortbay.log.StdErrLog
2008-03-12 10:28:02.503::INFO:  jetty-6.1.5
2008-03-12 10:31:52.469::INFO:  Started SelectChannelConnector@0.0.0.0:5030

or in the case of a SocketConnector

2008-03-12 10:44:15.189::INFO:  Logging to STDERR via
org.mortbay.log.StdErrLog
2008-03-12 10:44:15.211::INFO:  jetty-6.1.5
2008-03-12 10:48:12.517::INFO:  Started SocketConnector@0.0.0.0:5030

As you can see the SelectChannelListener does not become active until
about four minutes after starting the server. Of course the listener has
been added to the server before starting it in the first place and I
have never seen this behavior before.

I suspected DNS so I checked but the server has a (DHCP) network
connection and can do DNS lookups promptly.

After a couple of minutes (sometimes up to ten) all listeners are active
and everything works. However, in my start scripts I trigger some HTTP
GET actions after a wait of about 10-30 seconds to initialize stuff in
several of these processes. These now fail leaving the processes
uninitialized. That results in first-access failure later on when users
access the system.


This currently is the only server where this happens. Does anyone have
an idea what might cause this?

Thanks in advance,

Silvio Bierman


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Jetty-support mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-support
Reply | Threaded
Open this post in threaded view
|

Re: Delay in starting of Connectors

Silvio Bierman
Additional info: even if I start the same service twice with the port
already bound it does not fail immediately but takes more than a minute
to raise the 'java.net.BindException: Address already in use'.

???


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Jetty-support mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-support
Reply | Threaded
Open this post in threaded view
|

Re: Delay in starting of Connectors

Jesse McConnell
when you say this is the only server you are seeing this on, are you saying its the only jetty server in the cluster running concurrently that is flakey, or the only box that you see this behavior on and the same setup is working on other machines/environments..?

and yes, dns would be my first suspect too, how odd.

jesse

On Thu, Mar 13, 2008 at 7:14 AM, Silvio Bierman <[hidden email]> wrote:
Additional info: even if I start the same service twice with the port
already bound it does not fail immediately but takes more than a minute
to raise the 'java.net.BindException: Address already in use'.

???


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Jetty-support mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-support



--
jesse mcconnell
[hidden email]
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Jetty-support mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-support
Reply | Threaded
Open this post in threaded view
|

Re: Delay in starting of Connectors

Silvio Bierman
Jesse McConnell wrote:

> when you say this is the only server you are seeing this on, are you saying
> its the only jetty server in the cluster running concurrently that is
> flakey, or the only box that you see this behavior on and the same setup is
> working on other machines/environments..?
>
> and yes, dns would be my first suspect too, how odd.
>
> jesse
>
> On Thu, Mar 13, 2008 at 7:14 AM, Silvio Bierman <[hidden email]>
> wrote:
>
>  
It is the only box that does this, all server apps running on it show
the same behavior.

The only thing odd about the server is that it only has one primary nic
which currently is configured to use DHCP. The box is currently in our
office LAN and will be moved to a customers server location next week.
It will then probably be reconfigured to a hard IP address. Perhaps this
will then all go away but I would like to make sure before I hand them
the box.

I thought of DNS but when that is an issue logging in with SSH usually
stalls on a reverse DNS lookup as well. This box behaves absolutely fine
apart from this weird thing. I tuned up the ogging with -DDEBUG but no
suspects show up other then creation of the connector.

Regards,


Silvio


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Jetty-support mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-support
Reply | Threaded
Open this post in threaded view
|

Re: Delay in starting of Connectors

Jesse McConnell
what happens when you bring up just one of the embedded jetty instances?  does it exhibit the same behavior?

jesse

On Thu, Mar 13, 2008 at 8:44 AM, Silvio Bierman <[hidden email]> wrote:
Jesse McConnell wrote:
> when you say this is the only server you are seeing this on, are you saying
> its the only jetty server in the cluster running concurrently that is
> flakey, or the only box that you see this behavior on and the same setup is
> working on other machines/environments..?
>
> and yes, dns would be my first suspect too, how odd.
>
> jesse
>
> On Thu, Mar 13, 2008 at 7:14 AM, Silvio Bierman <[hidden email]>
> wrote:
>
>
It is the only box that does this, all server apps running on it show
the same behavior.

The only thing odd about the server is that it only has one primary nic
which currently is configured to use DHCP. The box is currently in our
office LAN and will be moved to a customers server location next week.
It will then probably be reconfigured to a hard IP address. Perhaps this
will then all go away but I would like to make sure before I hand them
the box.

I thought of DNS but when that is an issue logging in with SSH usually
stalls on a reverse DNS lookup as well. This box behaves absolutely fine
apart from this weird thing. I tuned up the ogging with -DDEBUG but no
suspects show up other then creation of the connector.

Regards,


Silvio


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Jetty-support mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-support



--
jesse mcconnell
[hidden email]
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Jetty-support mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-support
Reply | Threaded
Open this post in threaded view
|

Re: Delay in starting of Connectors

Silvio Bierman


Jesse McConnell wrote:
> what happens when you bring up just one of the embedded jetty instances?
> does it exhibit the same behavior?
>
> jesse
>
>  
Good call. That makes a lot of difference, delays are about 5-10 seconds
instead of several minutes. What does that mean? They all try to bind to
different ports.

Regards,

Silvio


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Jetty-support mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-support
Reply | Threaded
Open this post in threaded view
|

Re: Delay in starting of Connectors

Greg Wilkins
In reply to this post by Silvio Bierman

Silvio,

I suspect that it is the random number generator.  Jetty uses securerandom
which in turn uses the operating systems source on real entropy.

It is possible that your systems are too tranquil and thus you consume all
the available entropy and the OS waits for more interrupts, disk IO, network
traffic, or whatever else generates entropy on it.

Can you get a thread dump of one of the slow processes to see if it is
indeed starting the session manager  ID generation?






--
Greg Wilkins<[hidden email]>                       US:  +1  3104915462
http://www.webtide.com           UK: +44(0)2079932589 AU: +61(0)417786631

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Jetty-support mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-support
Reply | Threaded
Open this post in threaded view
|

Re: Delay in starting of Connectors

Silvio Bierman
Greg Wilkins wrote:

> Silvio,
>
> I suspect that it is the random number generator.  Jetty uses securerandom
> which in turn uses the operating systems source on real entropy.
>
> It is possible that your systems are too tranquil and thus you consume all
> the available entropy and the OS waits for more interrupts, disk IO, network
> traffic, or whatever else generates entropy on it.
>
> Can you get a thread dump of one of the slow processes to see if it is
> indeed starting the session manager  ID generation?
>
>
>
>
>
>
>  
Hello Greg,

Sounds plausible. What do you mean by tranquil? The system is completely
idle and seems to perform quite well. During the delay processor usage
never reaches 5% and the load averages stay at 0.00.

What particular resource is it that securerandom relies so heavily on?
Any additional stuff I should install or configure?

And most important: how do I make that thread dump? I can start the
processes via separate shell scripts. Usually they are stopped/started
from a single restart script that uses some basic home-brew
named-service-alike mechanism based on the screen package. Starting them
from the command line shows similar behavior so I will have ample time
to do a magic trick and get a thread dump.

Thanks,

Silvio

BTW: Adding a 25s pause to the overall script after starting each
service does the trick. Makes for a slow restart of over a minute but
that beats waiting several minutes for all listeners to start. At least
my warm-up GETs are caught as they should. Sounds like you have it
pin-pointed...


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Jetty-support mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-support
Reply | Threaded
Open this post in threaded view
|

Re: Delay in starting of Connectors

Jan Bartel
Silvio,

For thread dumps:

If you have a terminal attached to the process, then you can do ctnrl+backslash.

Otherwise you can use jps to find the pids of the jetty processes, and then use
jstack to get a thread dump.

Also you might want to check out http://jira.codehaus.org/browse/JETTY-331 which
I think is related.

cheers
Jan

Silvio Bierman wrote:

> Greg Wilkins wrote:
>> Silvio,
>>
>> I suspect that it is the random number generator.  Jetty uses securerandom
>> which in turn uses the operating systems source on real entropy.
>>
>> It is possible that your systems are too tranquil and thus you consume all
>> the available entropy and the OS waits for more interrupts, disk IO, network
>> traffic, or whatever else generates entropy on it.
>>
>> Can you get a thread dump of one of the slow processes to see if it is
>> indeed starting the session manager  ID generation?
>>
>>
>>
>>
>>
>>
>>  
> Hello Greg,
>
> Sounds plausible. What do you mean by tranquil? The system is completely
> idle and seems to perform quite well. During the delay processor usage
> never reaches 5% and the load averages stay at 0.00.
>
> What particular resource is it that securerandom relies so heavily on?
> Any additional stuff I should install or configure?
>
> And most important: how do I make that thread dump? I can start the
> processes via separate shell scripts. Usually they are stopped/started
> from a single restart script that uses some basic home-brew
> named-service-alike mechanism based on the screen package. Starting them
> from the command line shows similar behavior so I will have ample time
> to do a magic trick and get a thread dump.
>
> Thanks,
>
> Silvio
>
> BTW: Adding a 25s pause to the overall script after starting each
> service does the trick. Makes for a slow restart of over a minute but
> that beats waiting several minutes for all listeners to start. At least
> my warm-up GETs are caught as they should. Sounds like you have it
> pin-pointed...
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Jetty-support mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/jetty-support
>


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

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Jetty-support mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-support
Reply | Threaded
Open this post in threaded view
|

Re: Delay in starting of Connectors

Silvio Bierman
Hello Jan,

Thanks for this. I will first try if the fix I read about via your link
solves this. If not I will make the thread dump and post it here.

Regards,

Silvio


Jan Bartel wrote:

> Silvio,
>
> For thread dumps:
>
> If you have a terminal attached to the process, then you can do ctnrl+backslash.
>
> Otherwise you can use jps to find the pids of the jetty processes, and then use
> jstack to get a thread dump.
>
> Also you might want to check out http://jira.codehaus.org/browse/JETTY-331 which
> I think is related.
>
> cheers
> Jan
>
> Silvio Bierman wrote:
>  
>> Greg Wilkins wrote:
>>    
>>> Silvio,
>>>
>>> I suspect that it is the random number generator.  Jetty uses securerandom
>>> which in turn uses the operating systems source on real entropy.
>>>
>>> It is possible that your systems are too tranquil and thus you consume all
>>> the available entropy and the OS waits for more interrupts, disk IO, network
>>> traffic, or whatever else generates entropy on it.
>>>
>>> Can you get a thread dump of one of the slow processes to see if it is
>>> indeed starting the session manager  ID generation?
>>>
>>>
>>>
>>>
>>>
>>>
>>>  
>>>      
>> Hello Greg,
>>
>> Sounds plausible. What do you mean by tranquil? The system is completely
>> idle and seems to perform quite well. During the delay processor usage
>> never reaches 5% and the load averages stay at 0.00.
>>
>> What particular resource is it that securerandom relies so heavily on?
>> Any additional stuff I should install or configure?
>>
>> And most important: how do I make that thread dump? I can start the
>> processes via separate shell scripts. Usually they are stopped/started
>> from a single restart script that uses some basic home-brew
>> named-service-alike mechanism based on the screen package. Starting them
>> from the command line shows similar behavior so I will have ample time
>> to do a magic trick and get a thread dump.
>>
>> Thanks,
>>
>> Silvio
>>
>> BTW: Adding a 25s pause to the overall script after starting each
>> service does the trick. Makes for a slow restart of over a minute but
>> that beats waiting several minutes for all listeners to start. At least
>> my warm-up GETs are caught as they should. Sounds like you have it
>> pin-pointed...
>>
>>
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by: Microsoft
>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>> _______________________________________________
>> Jetty-support mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/jetty-support
>>
>>    
>
>
>  


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Jetty-support mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-support
Reply | Threaded
Open this post in threaded view
|

Re: Delay in starting of Connectors

Silvio Bierman
In reply to this post by Jan Bartel
Hi Jan,

I tried replacing the SessionIdManager with one that uses
java.util.Random makes all the difference. Kind of weird but I am happy
for now.

Thanks again,

Silvio


Jan Bartel wrote:

> Silvio,
>
> For thread dumps:
>
> If you have a terminal attached to the process, then you can do ctnrl+backslash.
>
> Otherwise you can use jps to find the pids of the jetty processes, and then use
> jstack to get a thread dump.
>
> Also you might want to check out http://jira.codehaus.org/browse/JETTY-331 which
> I think is related.
>
> cheers
> Jan
>
> Silvio Bierman wrote:
>  
>> Greg Wilkins wrote:
>>    
>>> Silvio,
>>>
>>> I suspect that it is the random number generator.  Jetty uses securerandom
>>> which in turn uses the operating systems source on real entropy.
>>>
>>> It is possible that your systems are too tranquil and thus you consume all
>>> the available entropy and the OS waits for more interrupts, disk IO, network
>>> traffic, or whatever else generates entropy on it.
>>>
>>> Can you get a thread dump of one of the slow processes to see if it is
>>> indeed starting the session manager  ID generation?
>>>
>>>
>>>
>>>
>>>
>>>
>>>  
>>>      
>> Hello Greg,
>>
>> Sounds plausible. What do you mean by tranquil? The system is completely
>> idle and seems to perform quite well. During the delay processor usage
>> never reaches 5% and the load averages stay at 0.00.
>>
>> What particular resource is it that securerandom relies so heavily on?
>> Any additional stuff I should install or configure?
>>
>> And most important: how do I make that thread dump? I can start the
>> processes via separate shell scripts. Usually they are stopped/started
>> from a single restart script that uses some basic home-brew
>> named-service-alike mechanism based on the screen package. Starting them
>> from the command line shows similar behavior so I will have ample time
>> to do a magic trick and get a thread dump.
>>
>> Thanks,
>>
>> Silvio
>>
>> BTW: Adding a 25s pause to the overall script after starting each
>> service does the trick. Makes for a slow restart of over a minute but
>> that beats waiting several minutes for all listeners to start. At least
>> my warm-up GETs are caught as they should. Sounds like you have it
>> pin-pointed...
>>
>>
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by: Microsoft
>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>> _______________________________________________
>> Jetty-support mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/jetty-support
>>
>>    
>
>
>  


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Jetty-support mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-support
Reply | Threaded
Open this post in threaded view
|

Re: Delay in starting of Connectors

jan_bartel
Just for the benefit of anyone following this thread in the future, there is now a wiki page on this at:
http://docs.codehaus.org/display/JETTY/Connectors+slow+to+startup

cheers
Jan

Silvio Bierman wrote:

> Hi Jan,
>
> I tried replacing the SessionIdManager with one that uses
> java.util.Random makes all the difference. Kind of weird but I am happy
> for now.
>
> Thanks again,
>
> Silvio
>
>
> Jan Bartel wrote:
>> Silvio,
>>
>> For thread dumps:
>>
>> If you have a terminal attached to the process, then you can do ctnrl+backslash.
>>
>> Otherwise you can use jps to find the pids of the jetty processes, and then use
>> jstack to get a thread dump.
>>
>> Also you might want to check out http://jira.codehaus.org/browse/JETTY-331 which
>> I think is related.
>>
>> cheers
>> Jan
>>
>> Silvio Bierman wrote:
>>  
>>> Greg Wilkins wrote:
>>>    
>>>> Silvio,
>>>>
>>>> I suspect that it is the random number generator.  Jetty uses securerandom
>>>> which in turn uses the operating systems source on real entropy.
>>>>
>>>> It is possible that your systems are too tranquil and thus you consume all
>>>> the available entropy and the OS waits for more interrupts, disk IO, network
>>>> traffic, or whatever else generates entropy on it.
>>>>
>>>> Can you get a thread dump of one of the slow processes to see if it is
>>>> indeed starting the session manager  ID generation?
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>  
>>>>      
>>> Hello Greg,
>>>
>>> Sounds plausible. What do you mean by tranquil? The system is completely
>>> idle and seems to perform quite well. During the delay processor usage
>>> never reaches 5% and the load averages stay at 0.00.
>>>
>>> What particular resource is it that securerandom relies so heavily on?
>>> Any additional stuff I should install or configure?
>>>
>>> And most important: how do I make that thread dump? I can start the
>>> processes via separate shell scripts. Usually they are stopped/started
>>> from a single restart script that uses some basic home-brew
>>> named-service-alike mechanism based on the screen package. Starting them
>>> from the command line shows similar behavior so I will have ample time
>>> to do a magic trick and get a thread dump.
>>>
>>> Thanks,
>>>
>>> Silvio
>>>
>>> BTW: Adding a 25s pause to the overall script after starting each
>>> service does the trick. Makes for a slow restart of over a minute but
>>> that beats waiting several minutes for all listeners to start. At least
>>> my warm-up GETs are caught as they should. Sounds like you have it
>>> pin-pointed...
>>>
>>>
>>> -------------------------------------------------------------------------
>>> This SF.net email is sponsored by: Microsoft
>>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>>> _______________________________________________
>>> Jetty-support mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/jetty-support
>>>
>>>    
>>
>>  
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Jetty-support mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/jetty-support
>


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Jetty-support mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-support
Reply | Threaded
Open this post in threaded view
|

Re: Delay in starting of Connectors

Greg Wilkins
In reply to this post by Silvio Bierman

Silvio

by tranquil I mean Idle.  A system that is not getting lots of interrupts
and network packets and disk seeks will not be able to generate a lot of
entropy for the random number generator.

How it does this, is up to the operating system and JVM combination

So you will have to read up on what sort of things you need to do
to generate more entropy.  An fsck might do the trick?

You can get thread dumps by using jstack command on the command
line, or by sending a kill -3 at the process or typing ctrl-\ on
the console.

cheers






Silvio Bierman wrote:

> Greg Wilkins wrote:
>> Silvio,
>>
>> I suspect that it is the random number generator.  Jetty uses securerandom
>> which in turn uses the operating systems source on real entropy.
>>
>> It is possible that your systems are too tranquil and thus you consume all
>> the available entropy and the OS waits for more interrupts, disk IO, network
>> traffic, or whatever else generates entropy on it.
>>
>> Can you get a thread dump of one of the slow processes to see if it is
>> indeed starting the session manager  ID generation?
>>
>>
>>
>>
>>
>>
>>  
> Hello Greg,
>
> Sounds plausible. What do you mean by tranquil? The system is completely
> idle and seems to perform quite well. During the delay processor usage
> never reaches 5% and the load averages stay at 0.00.
>
> What particular resource is it that securerandom relies so heavily on?
> Any additional stuff I should install or configure?
>
> And most important: how do I make that thread dump? I can start the
> processes via separate shell scripts. Usually they are stopped/started
> from a single restart script that uses some basic home-brew
> named-service-alike mechanism based on the screen package. Starting them
> from the command line shows similar behavior so I will have ample time
> to do a magic trick and get a thread dump.
>
> Thanks,
>
> Silvio
>
> BTW: Adding a 25s pause to the overall script after starting each
> service does the trick. Makes for a slow restart of over a minute but
> that beats waiting several minutes for all listeners to start. At least
> my warm-up GETs are caught as they should. Sounds like you have it
> pin-pointed...
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Jetty-support mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/jetty-support
>


--
Greg Wilkins<[hidden email]>                       US:  +1  3104915462
http://www.webtide.com           UK: +44(0)2079932589 AU: +61(0)417786631

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Jetty-support mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-support
Reply | Threaded
Open this post in threaded view
|

Re: Delay in starting of Connectors

Greg Wilkins
In reply to this post by Silvio Bierman
Silvio Bierman wrote:
> Hi Jan,
>
> I tried replacing the SessionIdManager with one that uses
> java.util.Random makes all the difference. Kind of weird but I am happy
> for now.

Note that Random is not secure and it is possible for an attacker to
use a bit of maths, a fast computer and some captured session IDs to
predict the next session IDs.

So it's not a good solution for production systems with valuable information.

cheers


--
Greg Wilkins<[hidden email]>                       US:  +1  3104915462
http://www.webtide.com           UK: +44(0)2079932589 AU: +61(0)417786631

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Jetty-support mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-support
Reply | Threaded
Open this post in threaded view
|

Re: Delay in starting of Connectors

Silvio Bierman
Greg Wilkins wrote:

> Silvio Bierman wrote:
>  
>> Hi Jan,
>>
>> I tried replacing the SessionIdManager with one that uses
>> java.util.Random makes all the difference. Kind of weird but I am happy
>> for now.
>>    
>
> Note that Random is not secure and it is possible for an attacker to
> use a bit of maths, a fast computer and some captured session IDs to
> predict the next session IDs.
>
> So it's not a good solution for production systems with valuable information.
>
> cheers
>
>
>  
Hello Greg,

I do realize that. In this case I prefer less safety (the server will be
inside a local network mostly for the coming months) over the issues I
had before which directly resulted in diminished availability. However,
I do consider this to be a temporary solution.

Regards,

Silvio


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Jetty-support mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-support
Reply | Threaded
Open this post in threaded view
|

Re: Delay in starting of Connectors

Silvio Bierman
In reply to this post by Greg Wilkins
Greg Wilkins wrote:

> Silvio
>
> by tranquil I mean Idle.  A system that is not getting lots of interrupts
> and network packets and disk seeks will not be able to generate a lot of
> entropy for the random number generator.
>
> How it does this, is up to the operating system and JVM combination
>
> So you will have to read up on what sort of things you need to do
> to generate more entropy.  An fsck might do the trick?
>
> You can get thread dumps by using jstack command on the command
> line, or by sending a kill -3 at the process or typing ctrl-\ on
> the console.
>
> cheers
>
>
>
>
>
>  
Hello Greg,

The server has just been installed and is sitting there mostly idle.
However, I have it close at hand now but in a couple of days it is going
to be taken away by a customer and I will have more trouble getting to
it for doing software updates or configuring stuff.

I do not know how SecureRandom works and why it can't perform an a
mostly idle server. I also do not understand why the random generator
comes into play before the listeners are initialized. I would gladly
sacrifice some session creation performance for enhanced overall
security but the servers coming up this slowly is not acceptable.

As you read in another of my posts replacing SecureRandom by Random
solves the startup delays issue. For now this suffices but I would
prefer not to do this. I will look into SecureRandom and will try to get
it working properly on this server. If I find a solution I will make
sure to post it here.

Regards,

Silvio


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Jetty-support mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-support