NoSuchMethod in 9ea-b30 getRawHostnameSE
by Bernd Eckenfels
Hello JDK security team,
(cced the Undertow guys cause I mentioned this on the IRC channel)
when trying to run the JBoss Undertow build tests with JDK9ea-b30 a lot
of tests fail with the same "NosuchMethodError", and I am not sure why.
It looks like an internal inconsitency in the JSSE? However I tries the simple SSLEngine demo code and that one compiles and runs.
Undertow master 79daf29
https://github.com/undertow-io/undertow/tree/79daf29322940f93a42f736a2cd9...
maven 3.2.3 Windows x64 7
this is using xnio-api and xnio-nio 3.3.0.Beta3 (from jboss-public-repository-group)
One of the observed exceptions (but not related to SPDY IMHO):
03:26:29,211 ERROR (XNIO-1 I/O-2) [org.xnio.listener] <ChannelListeners.java:94> XNIO001007: A channel event listener threw an exception:
java.lang.NoSuchMethodError: sun.security.ssl.ClientHandshaker.getRawHostnameSE()Ljava/lang/String;
at sun.security.ssl.ClientHandshaker.getKickstartMessage(ClientHandshaker.java:1294)
at sun.security.ssl.Handshaker.kickstart(Handshaker.java:972)
at sun.security.ssl.SSLEngineImpl.kickstartHandshake(SSLEngineImpl.java:728)
at sun.security.ssl.SSLEngineImpl.beginHandshake(SSLEngineImpl.java:750)
at org.xnio.ssl.JsseSslConduitEngine.beginHandshake(JsseSslConduitEngine.java:177)
at org.xnio.ssl.JsseSslStreamConnection.startHandshake(JsseSslStreamConnection.java:85)
at io.undertow.client.spdy.SpdyClientProvider.handlePotentialSpdyConnection(SpdyClientProvider.java:222)
at io.undertow.client.http.HttpClientProvider.handleConnected(HttpClientProvider.java:132)
at io.undertow.client.http.HttpClientProvider.access$000(HttpClientProvider.java:49)
at io.undertow.client.http.HttpClientProvider$2.handleEvent(HttpClientProvider.java:123)
at io.undertow.client.http.HttpClientProvider$2.handleEvent(HttpClientProvider.java:120)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at org.xnio.ssl.JsseXnioSsl$StreamConnectionChannelListener.handleEvent(JsseXnioSsl.java:283)
at org.xnio.ssl.JsseXnioSsl$StreamConnectionChannelListener.handleEvent(JsseXnioSsl.java:265)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at org.xnio.nio.WorkerThread$ConnectHandle.handleReady(WorkerThread.java:324)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:539)
As xnio (the NIO abstraction used by undertow) uses asm and some
unsafe functions it might not be the cleanest test, however the
stacktrace looks like the problem is all inside javax.ssl / JSSE?
I am not sure where to look for the right JDK source version, is this before or after the modular split? The latest code does not seem to match the stacktrace:
http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/40c3a5ce8047/src/java.base/...
Gruss
Bernd
11 years, 1 month
Async sending of NIO objects thru a ServletOutputStream?
by Jim Crossley
Hi guys,
I'm looking to promote Undertow as a preferred alternative to Jetty for the
Pedestal [1] framework.
One Jetty feature it relies on is the async sending of ByteBuffers and
ReadableByteChannels in Jetty's impl of ServletOutputStream [2]. Two
methods, in particular: sendContent(ByteBuffer, Callback) and
sendContent(ReadableByteChannel, Callback).
I was hoping someone might point me in the right direction of replicating
this behavior with Undertow's ServletOutputStreamImpl. It does have a
write(ByteBuffer) method, but it appears to be blocking. And I was hoping
there might be some XNIO abstraction for dealing with the
ReadableByteChannel, perhaps some example code somewhere?
Any and all help/advice is appreciated!
Jim
[1]: https://github.com/pedestal/pedestal
[2]:
http://grepcode.com/file/repo1.maven.org/maven2/org.eclipse.jetty/jetty-s...
11 years, 1 month
Does ClassPathResourceManager work to serve a html file which is inside a packaged jar
by Venkatesha T R
Hi,
I am seeing this behavior in undertow - I have written a simple web
application using undertow which processes 3 requests and provides a single
(may be two in future) page (s) to see. These pages are just html pages and
3 requests are GET/POST requests. I am using ClassPathResourceManager class
to serve the index.html file which is present inside classpath in one of my
package (I am using a maven project). It works fine when I run this
application in the Eclipse environment (where there is no jar used for
running). But when I package this application as a jar file and run it in
standalone mode, ClassPathResourceManager fails to pick the resource and
serve it.
ClassPathResourceManager reports Resource instance, but I see a blank page
(404) error when I see it in browser. If somebody has any clue about what
is going on, or knows about this possible bug, please let me know. It will
help me a lot.
Thanks in advance..
--
*Thanks and Regards*
*--------------------------------------------------------------------------------------------------------------------*
*Venkatesh T R*
*9945040858*
A Man with Many Dimensions...
11 years, 1 month
InMemorySessionManager.java performance
by Andrew Schmidt
My company is currently switching from jboss 4 => wildfly 8.1, jsf + hibernate + richfaces. (We develop on Windows)
After profiling our application, I've found some major performance penalties in the InMemorySessionManager.java in undertow. Specifically in the bumpTimeout() that gets called on every getAttribute call. Each of these calls takes 15 ms, which when called 100 times during the course of a jsf request, adds up. (The 15 ms occurs when the execute.executeAfter in netty tries to wake up another thread)
Looking over the code:
io/undertow/server/session/InMemorySessionManager.java
-- snip
synchronized void bumpTimeout() {
final int maxInactiveInterval = getMaxInactiveInterval();
if (maxInactiveInterval > 0) {
long newExpireTime = System.currentTimeMillis() + (maxInactiveInterval * 1000);
if(timerCancelKey != null && (newExpireTime < expireTime)) {
// We have to re-schedule as the new maxInactiveInterval is lower than the old one
if (!timerCancelKey.remove()) {
return;
}
timerCancelKey = null;
}
expireTime = newExpireTime;
if(timerCancelKey == null) {
//+1 second, to make sure that the time has actually expired
//we don't re-schedule every time, as it is expensive
//instead when it expires we check if the timeout has been bumped, and if so we re-schedule
timerCancelKey = executor.executeAfter(cancelTask, maxInactiveInterval + 1, TimeUnit.SECONDS);
-- snip
If the time changes by 1ms, then the expiration task is cancelled and a new one is scheduled. But this new scheduling takes 15ms. Therefore every call to getAttribute (which in turn calls bumpTimeout) will constantly cancel and reschedule the expiration tasks. This seems heavy handed. Also the comment seems to imply that the developer who wrote this was aware that rescheduling is expensive, yet it happens on every call.
Disabling session expiration causes our application to run twice as fast. (5.5 second page load goes down to 2.5)
11 years, 1 month
Checking if an exchange has been dispatched
by Shannon Lloyd
Hi,
If I dispatch an exchange within a handler, and later confirm that it is
being executed by one of the "task" threads, should I expect
exchange.isDispatched() to return true?
Because I'm not seeing this behaviour (using 1.0.15.Final). If I pause
execution in the debugger, I can see that the executing thread is XNIO-1
task-1, but exchange.isDispatched() returns false. If it helps,
exchange.state == 151752.
Does isDispatched() not mean what I think it means (i.e. that execution has
actually commenced via the task pool)?
Thanks,
Shannon
11 years, 2 months
