[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [jetty-users] Jetty hanging after upgrade from 6.1.14 to 7.1.15
|
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