Resizing undertow thread pool size dynamically
by Mohammed ElGhaouat
Hi,
I would like to know if there is a way to make undertow reducing the size
of the thread pool when the server is less loaded. Is there any
parameter(or other way) that make an idle thread die after some inactivity
time ?
Thanks.
Mohammed.
10 years, 9 months
Frontent Load Balancer with Mod-Cluster using a virtual IP address
by ralf_boogie_blues＠bluewin.ch
Hi
I trying to replace your Apache Httpd with mod_cluster load balancer with Undertow frontend modcluster as part of Wildfly 9.0.1.
It works fine when I define a 'real' IP address defined in /etc/hosts:
127.0.0.1 localhost
10.22.62.40 mdzhrnesir01.standard.six-group.net mdzhrnesir01
But this IP address 10.22.62.117 is not taken by untertow:
ip addr
.
8: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
link/ether 00:17:a4:77:f0:b6 brd ff:ff:ff:ff:ff:ff
inet 10.22.62.40/24 brd 10.22.62.255 scope global bond0
inet 10.22.62.117/24 scope global secondary bond0
I also faced to problem, that running the example presented by Stuart Douglas doesn't work inside a docker container. Even I execute step by step.
Without digging into the source code, what are the criteria under which Undertow frontend modcluster accepts IP address(es)?
Do you also have a proposal for configuring Undertow modcluster to listen to two interfaces? Say an internal IP address and an virtual external IP address?
I think with Apache, we defined 0.0.0.0 and then Apache with mod_cluster was listening on all interfaces, if I remember correctly.
Thanks a lot in advance
Ralf
11 years
Mostly IO, non-blocking workload best practice
by Chris Back
I am writing a server that will need to respond to lots of small web
requests. Most of the requests will come with a small POST payload. Based
on the contents of the payload, the server will either a) respond
immediately, or b) forward the request as is to one of a pool of backend
servers, waiting for a response and forwarding the response back to the
client.
It looks like given the existing undertow code, I have good examples of how
to forward requests to the backend. What isn't as clear is how to handle
the getting the POST data. Is there a way of doing that without blocking?
Ideally, my handler flow would be:
1. Non-blocking request handler that makes sure all POST data is in.
2. A non-blocking handler that decisions based on content of POST data to
3a. Immediately return a response to the client (non-blocking).
or
3b. Dispatch to the worker pool to forward request to backend server and
await response.
90% of my requests will go through path 3a, and I'd like that to be as
quick as possible. When the server decides a request should go through 3b,
only then should it go to the blocking worker pool.
Am I viewing this correctly? What are my options? Based on this thread
http://lists.jboss.org/pipermail/undertow-dev/2015-January/001082.html
it seems like an option could be to get the request channel in step 1
above? Its not clear to me how that would work.
Thanks,
Chris
11 years
backchannel logout in cluster
by Bill Burke
I'm running into a problem implementing SAML backchannel logout. Web
server could receive an on-of-band, non-browser HTTP request to logout
out a specific user and/or session. I would need a way to lookup a
session by Principal and a way to associate and lookup an external key.
SAML doesn't really have any way to push client specific session
information.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
11 years
HttpServerExchange.unDispatch()
by Chris Back
I noticed an undocumented (as far as I can tell) public method on the
exchange, unDispatch(). How is this supposed to be used? Is it to move a
process back into the IO thread pool?
I ask because I have written a ChannelListener that reads in the entire
http entity before passing the request through to the next HttpHandler. I
have noticed sometimes without my dispatching the request the exchange gets
dispatched on it own. I assume this is some side effect calling
channel.resumeReads().
Is it safe to use exchange.unDispatch() like dispatch() (only in reverse)?
-Chris
11 years
SSE and close stacktrace
by Cédric Tran-Xuan
Hello,
We are using the SSE handler to post at interval some events.
Every time a user closes its browser tab, we've got the following exception:
java.nio.channels.ClosedChannelException: null
at
io.undertow.server.protocol.framed.AbstractFramedStreamSinkChannel.safeToSend(AbstractFramedStreamSinkChannel.java:441)
~[classes/:na]
at
io.undertow.server.protocol.framed.AbstractFramedStreamSinkChannel.write(AbstractFramedStreamSinkChannel.java:395)
~[classes/:na]
at
org.xnio.conduits.StreamSinkChannelWrappingConduit.write(StreamSinkChannelWrappingConduit.java:57)
~[xnio-api-3.3.1.Final.jar:3.3.1.Final]
at
org.xnio.conduits.ConduitStreamSinkChannel.write(ConduitStreamSinkChannel.java:150)
~[xnio-api-3.3.1.Final.jar:3.3.1.Final]
at
io.undertow.channels.DetachableStreamSinkChannel.write(DetachableStreamSinkChannel.java:240)
~[classes/:na]
at
io.undertow.server.HttpServerExchange$WriteDispatchChannel.write(HttpServerExchange.java:1980)
~[classes/:na]
at
io.undertow.server.handlers.sse.ServerSentEventConnection$SseWriteListener.handleEvent(ServerSentEventConnection.java:456)
~[classes/:na]
at
io.undertow.server.handlers.sse.ServerSentEventConnection$2.run(ServerSentEventConnection.java:210)
[classes/:na]
at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:560)
[xnio-nio-3.3.1.Final.jar:3.3.1.Final]
at org.xnio.nio.WorkerThread.run(WorkerThread.java:462)
[xnio-nio-3.3.1.Final.jar:3.3.1.Final]
We guess it comes from the fact that the buffer is not empty at the time
the browser closes the connection. Having this stacktrace in the log files,
for every connection closed is a bit cumbersome for us. So, we were
wondering whether there was a mean to handle this special stacktrace. From
what we have seen, it is a log from a xnio WorkerThread but we don't wish
to mute all the error logs from this class. And we haven't seen any way to
catch the exception too.
Any ideas would be appreciated.
Thanks in advance.
Cédric.
PS: The example to reproduce the « issue » can be the one in attachment of
https://issues.jboss.org/browse/UNDERTOW-535.
You can run the example, open a browser at https://localhost:8443/sse and
close the browser tab. The stacktrace should appear.
11 years
org.jboss.remoting3.NotOpenException with java.lang.IllegalStateException while server shutting
by Kákonyi István
Hi Team!
I would like to ask your help about a strange behaviour/issue which occurs when stopping a wildfly 8.2.0 server instance:
When stopping a Wildfly 8.2.0 server instance, the following line appeared in the log:
2015-09-04 11:07:39,810 ERROR [org.jboss.remotingjmx.protocol.v2.ServerCommon] org.jboss.remoting3.NotOpenException: Writes closed
Also there is an IllegalStateException right before that ERROR line:
2015-09-04 11:07:39,806 WARN [org.jboss.remotingjmx.protocol.v2.ServerCommon] Unexpected internal error: java.lang.IllegalStateException
at org.jboss.as.patching.installation.InstallationManagerService.getValue(InstallationManagerService.java:87) [wildfly-patching-8.2.0.Final.jar:8.2.0.Final]
at org.jboss.as.patching.installation.InstallationManagerService.getValue(InstallationManagerService.java:28) [wildfly-patching-8.2.0.Final.jar:8.2.0.Final]
at org.jboss.msc.service.ServiceControllerImpl.getValue(ServiceControllerImpl.java:1158) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
at org.jboss.as.patching.management.PatchResource$ElementProviderResourceProvider.children(PatchResource.java:139) [wildfly-patching-8.2.0.Final.jar:8.2.0.Final]
at org.jboss.as.patching.management.PatchResource$ElementProviderResourceProvider.hasChildren(PatchResource.java:134) [wildfly-patching-8.2.0.Final.jar:8.2.0.Final]
at org.jboss.as.controller.registry.AbstractModelResource.hasChildren(AbstractModelResource.java:81) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
at org.jboss.as.controller.registry.AbstractModelResource$DelegateResource.hasChildren(AbstractModelResource.java:279) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
at org.jboss.as.jmx.model.RootResourceIterator.doIterate(RootResourceIterator.java:57) [wildfly-jmx-8.2.0.Final.jar:8.2.0.Final]
at org.jboss.as.jmx.model.RootResourceIterator.doIterate(RootResourceIterator.java:61) [wildfly-jmx-8.2.0.Final.jar:8.2.0.Final]
at org.jboss.as.jmx.model.RootResourceIterator.iterate(RootResourceIterator.java:43) [wildfly-jmx-8.2.0.Final.jar:8.2.0.Final]
at org.jboss.as.jmx.model.ModelControllerMBeanHelper.getMBeanCount(ModelControllerMBeanHelper.java:105) [wildfly-jmx-8.2.0.Final.jar:8.2.0.Final]
at org.jboss.as.jmx.model.ModelControllerMBeanServerPlugin.getMBeanCount(ModelControllerMBeanServerPlugin.java:157) [wildfly-jmx-8.2.0.Final.jar:8.2.0.Final]
at org.jboss.as.jmx.PluggableMBeanServerImpl.getMBeanCount(PluggableMBeanServerImpl.java:554) [wildfly-jmx-8.2.0.Final.jar:8.2.0.Final]
at org.jboss.as.jmx.BlockingNotificationMBeanServer.getMBeanCount(BlockingNotificationMBeanServer.java:143) [wildfly-jmx-8.2.0.Final.jar:8.2.0.Final]
at org.jboss.remotingjmx.protocol.v2.ServerProxy$GetMBeanCountHandler.handle(ServerProxy.java:655)
at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1$1.run(ServerCommon.java:153)
at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:75) [wildfly-jmx-8.2.0.Final.jar:8.2.0.Final]
at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:70) [wildfly-jmx-8.2.0.Final.jar:8.2.0.Final]
at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.8.0_60]
at javax.security.auth.Subject.doAs(Subject.java:422) [rt.jar:1.8.0_60]
at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:94) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor.handleEvent(ServerInterceptorFactory.java:70) [wildfly-jmx-8.2.0.Final.jar:8.2.0.Final]
at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1.run(ServerCommon.java:149)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_60]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_60]
at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_60]
It seems as if the server was in the process of shutting down its services when a JMX connection was requested. We were able to confirm this by initiating a JMX connection, then almost at the same time we initiated a graceful stop on the server as well, and the aforementioned ERROR appeared in the log.
Is it possible that during the shutdown phase jmx connections are still allowed by the server which finally causes IllegalStateException?
Regards,
Istvan
11 years
HTTP/2.0 and SSE
by Cédric Tran-Xuan
Hello,
We are trying to use both SSE and HTTP/2.0 features of Undertow. The idea
is to open an SSE connection with HTTP/2.0 as protocol.
We've tried with the following piece of code:
____________________________________________
ServerSentEventHandler sseHandler;
sseHandler = new ServerSentEventHandler(new
SseConnectionCallback(source));
String bindAddress = System.getProperty("bind.address",
"localhost");
SSLContext sslContext =
createSSLContext(loadKeyStore("server.keystore"),
loadKeyStore("server.truststore"));
Undertow server = Undertow.builder()
.setServerOption(UndertowOptions.ENABLE_HTTP2, true)
.setServerOption(UndertowOptions.ENABLE_SPDY, true)
.addHttpsListener(8443, bindAddress, sslContext)
.setHandler(path().addPrefixPath("/sse",
sseHandler))
.build();
server.start();
____________________________________________
But when connecting to https://localhost:8443/sse, nothing happens in the
client side while we are sending into the ServerSentEventConnection data
every 5 seconds
We think it is related to the HTTP/2.0 frame stuff but we are not sure
about this hypothesis.
On the other hand, we have modified the ServerSentEventConnection to expose
a flush() method that calls the underlying flush() of its sink.
____________________________________________
public class ServerSentEventConnection implements Channel, Attachable {
...
public boolean flush() throws IOException {
return this.sink.flush();
}
}
____________________________________________
And somewhere in our callback, we do:
____________________________________________
public class SseConnectionCallback implements
ServerSentEventConnectionCallback {
...
if (connection.isOpen()) {
connection.send(data, "data", UUID.randomUUID().toString(),
new ServerSentEventConnection.EventCallback() {
@Override
public void done(ServerSentEventConnection aConnection,
String aData, String aEvent, String aId) {
LOGGER.info("Sent!");
try {
connection.flush();
} catch (IOException e) {
e.printStackTrace();
}
}
@Override
public void failed(ServerSentEventConnection
aConnection, String aData, String aEvent, String aId, IOException e) {
LOGGER.info("failed!");
}
});
}
____________________________________________
And we get the SSE events on the client side. So, we were wondering whether
our solution was right or whether there is another solution for our issue.
Thanks in advance!
Best regards,
Cédric.
11 years
