Re: [jetty-users] Jetty hanging after upgrade from 6.1.14 to 7.1.15

[Nick Pellow <npellow@xxxxxxxxxxxxx>]

Also - we configure Jetty like so:

	 mServer = new Server();
        BoundedThreadPool threadPool = new BoundedThreadPool();
        threadPool.setMaxThreads(wsConfig.getMaxThreads().intValue());
        threadPool.setMinThreads(wsConfig.getMinThreads().intValue());
        mServer.setThreadPool(threadPool);
        mServer.addConnector(jspConnector);

        ProxyInfo proxyInfo = new ProxyInfo(http);
        SelectChannelConnector connector = new  
ProxyPassingSelectChannelConnector(proxyInfo.proxyScheme,  
proxyInfo.proxyHost, proxyInfo.proxyPort);
        setupBind(connector, http.getBind());
        setupCustomBufferHeaderSize(connector);
        mServer.addConnector(connector);
        desc.add(http.getBind() + " (http)");


   //check for a custom header buffer size
    private void setupCustomBufferHeaderSize(Connector connector) {
        String headerBufferSize =  
System.getProperty("jetty.http.headerbuffersize");
        if (headerBufferSize != null) {
            try {
                  
connector.setHeaderBufferSize(Integer.parseInt(headerBufferSize));
            } catch (NumberFormatException e) {
                Logs.APP_LOG.warn("Could not parse  
jetty.http.headerbuffersize: " + headerBufferSize);
            }
        }
    }

    private void setupBind(Connector connector, String bindSpec)  
throws UnknownHostException {
        InetAddrPort bind = new InetAddrPort(bindSpec);
        if (!bind.getHost().equals(InetAddrPort.WILDCARD_0_0_0_0)) {
            connector.setHost(bind.getHost());
        }
        connector.setPort(bind.getPort());
    }

I am fairly sure this problem is caused by the fact we are starting  
and stopping Jetty between our tests, and for some reason the thread  
that handles ProxyPassingSelectChannelConnector is not being started,  
or is crashing.

Cheers,
Nick

On 19/07/2010, at 4:22 PM, Greg Wilkins wrote:

> Nick,
>
> I had a quick look, but cannot follow what you have said/sent.
> I cannot see any SelectChannelConnectors in your thread dump.  All I
> see is a LocalConnector:
>
>    [junit] "qtp1177106648-212 - Acceptor0 LocalConnector@0.0.0.0:0"
> prio=5 tid=17970d000 nid=0x16cf9b000 waiting on condition [16cf9a000]
>    [junit]    java.lang.Thread.State: WAITING (parking)
>    [junit] 	at sun.misc.Unsafe.park(Native Method)
>    [junit] 	- parking to wait for  <10fb31178> (a
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
>    [junit] 	at
> java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)
>    [junit] 	at
> java.util.concurrent.locks.AbstractQueuedSynchronizer 
> $ConditionObject.await(AbstractQueuedSynchronizer.java:1925)
>    [junit] 	at
> java 
> .util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java: 
> 399)
>    [junit] 	at
> org.eclipse.jetty.server.LocalConnector.accept(LocalConnector.java:59)
>    [junit] 	at
> org.eclipse.jetty.server.AbstractConnector 
> $Acceptor.run(AbstractConnector.java:793)
>    [junit] 	at
> org.eclipse.jetty.util.thread.QueuedThreadPool 
> $2.run(QueuedThreadPool.java:436)
>    [junit] 	at java.lang.Thread.run(Thread.java:637)
>
>
> can you clarify what your configuration was, and perhaps raise an
> issue in the jetty JIRA
>
> Note that 7.1.5 did have a few problems (though nothing obviously
> related), so try 7.1.6 now.
>
> regards
>
>
>
>
>
>
>
>
>
> On 14 July 2010 10:11, Nick Pellow <npellow@xxxxxxxxxxxxx> wrote:
> > Hi,
> > We start and stop Jetty during the setUp() and tearDown() methods  
> > in some of
> > our tests.
> > We recently tried upgrading from Jetty 6.1.14, to Jetty 7.1.15 -  
> > however had
> > to revert this for the time being because some of our tests started  
> > randomly
> > hanging.
> >
> > After Jetty starts, our tests use HttpClient to make requests to  
> > FishEye
> > running inside Jetty.
> > It is one of these client requests that hang, indefinitely. From  
> > what I can
> > tell, this is more easily reproducable on machines that run quite  
> > slow, and
> > have few (<3) cores. (e.g a mac-mini, but not a 8-core MacPro)
> >
> > It appears that the SelectChannelConnector we configure Jetty with  
> > to handle
> > remote requests is no longer running (or was never started?) when  
> > the hang
> > occurs.
> >
> > There are three DEBUG logs, including thread dumps, attached
> > to http://jira.atlassian.com/browse/CRUC-3721, showing:
> >
> > a build that hangs using a SelectChannelConnector
> > a build that doesn't hang using a SelectChannelConnector (only a  
> > single test
> > is run)
> > a built that hangs using a normal (non-nio) SocketConnector.
> >
> > Has anyone seen similar behaviour using Jetty 7 before, or does  
> > anything in
> > the logs standout as a candidate for causing Jetty to hang?
> >
> > Is there anything else we can enable to try and detect what could  
> > be going
> > on?
> >
> > Cheers,
> >
> > Nick
> >
> > _______________________________________________
> > jetty-users mailing list
> > jetty-users@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/jetty-users
> _______________________________________________
> jetty-users mailing list
> jetty-users@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/jetty-users