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, 8 months
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
10 years, 11 months
Extending io.undertow.servlet.spec.HttpSessionImpl
by Kákonyi István
Hi Team!
I am involved in a github project that try to implement a SIP Application Server under wildfy 8 (check https://github.com/Mobicents/sip-servlets/issues/3 for more detail).
According to SIP Servlet spec we have to implement a ConvergedHttpSession class that provides access to HttpSession related functionality which is only present in a converged HTTP/SIP container. In a converged container, an instance of HttpSession can be cast to ConvergedHttpSession in order to access methods available only to converged applications.
Wildfly 8 uses undertow-servlet project for session handling and I noticed that currently it is not possible to extend io.undertow.servlet.spec.HttpSessionImpl (it has only a private constructor method and a static method for instantiation), so we are stuck in the implementation a little bit because of that limitation.
Do you have any suggestion how to resolve this problem? Is there a chance to change HttpSessionImpl's constructor to "protected" in order to be able to extend it?
Best Regards,
Istvan
10 years, 12 months
Possible session lookup bug when no session cookie present
by Toby Crawley
With this commit[1], calls to Sessions.getOrCreateSession() from
within a handler where no session cookie was sent with the request
result in a new Session being created every time, with the last
Session created actually being the one stored when the exchange is
completed.
This means that the following in a handler results in "foo" not being
in the session on the next request:
Sessions.getOrCreateSession(exchange).setAttribute("foo", "bar");
Sessions.getOrCreateSession(exchange);
Before [1], the second getOrCreateSession() call would return the same
Session object as the first call, not overwriting the one already
attached to the request, and "foo" would be preserved.
I'm not sure if you consider this a bug or not, but wanted to point it
out just in case. We discovered this in an Immutant test when
upgrading from undertow 1.1.0, and we were able to work around it with
a small change to that test. I don't believe this will affect any
Immutant users, since we handle all Session access for them, and call
getOrCreateSession() only once during regular operation.
Let me know if you do consider this a bug, and I'll file a JIRA.
- Toby
[1]: https://github.com/undertow-io/undertow/commit/a97fec29f379fff6cb5a74ae9a...
10 years, 12 months
websocket per-message compression & design q
by peter royal
Hi!
I'm trying to debug the problems I've encountered after enabling
per-message compression on websockets in 1.2,
https://issues.jboss.org/browse/UNDERTOW-508
One thing I've noticed is that there's an entirely different code path
used inside of WebSocket07FrameSinkChannel whenever extensions are
enabled. I was trying to think of how to refactor how extensions are
applied so that it would be a path that is always-on, and thus hopefully
subject to more scrutiny and use.
Conceptually, extensions are transformations to the ByteBuffer that
makes up a message payload. I think the internals might be a bit clearer
if they were treated as that, and then always applied. (the
ExtensionByteBuffer class is something I'd want to eliminate).
From an internal API point of view, calls to write on a websocket are
mostly made via the WebSockets class, and then a couple of places that
use the StreamSinkFrameChannel (SSFC) over a longer period of time for
partial messages and streams in the WS JSR implementation.
For sending, the GatheringByteChannel APIs are used to represent writing
a message. A collection of writes to a single SSFC will result in 1..n
WS message fragments depending on how large the buffers returned from
the allocator are. When using extensions, there are a bunch of
ergonomics regarding the return value from write and remaining bytes in
the provided buffers to enable
For the WebSockets send methods, all the data to send is already in
memory, and the methods just spin or wait over the SSFC writing
fragments until all the data is sent. Then there are the blocking APIs
in the JSR that send a single fragment and wait for it to be flushed.
I think it might be cleaner to push some of that responsibility from the
WebSockets utility class into the WebSocket07FrameSinkChannel. For the
non-blocking cases, that'd be merging the following two lines from
WebSockets into a single call,
StreamSinkFrameChannel channel = wsChannel.send(type, totalData);
WebSockets.sendData(data, wsChannel, callback, channel, null,
timeoutmillis);
The channel can then apply the extensions to data and do the appropriate
thing. Similar changes would happen to the blocking methods.
I realize this is a bit ramble-y, but I wanted to at least get some of
my thoughts out there. I'm eager to get WS extensions working fully, and
thought that re-architecting how the sending of WS messages happen might
make the code less brittle and easier to maintain
-pete
--
(peter.royal|osi)(a)pobox.com - http://fotap.org/~osi
11 years
It is possible to deploy a JAX-RS application?
by Reginaldo Sousa
Hi,
I'm working on a JAX-RS application and would like to use the undertow as
container.
I found only one implementation using RestEasy, but it very degrades
performance.
I tried to use jersey with servlet container but it still fails.
Anyone have any suggestions?
*_________________________________________________________ Reginaldo Sousa*
- software developer
Tw, FB, In: @reginaldosousa
11 years
1.2.9.Final tag missing in git repo
by arjan tijms
Hi,
I'm trying to build WildFly 9.0.1.Final from source. WildFly
9.0.1.Final seems to depend on WildFly core 1.0.1.Final, which on its
turn depends on Undertow 1.2.9.Final.
However, there's no tag 1.2.9.Final at https://github.com/undertow-io/undertow
I see a 1.2.8.Final and a 1.2.10.Final
Am I missing something?
Kind regards,
Arjan Tijms
11 years
How to Access ServletContext?
by Ari King
I've embedded Undertow into a Resteasy (JAX-RS) app. One of the libraries
I'm using requires a servlet context attribute to be set. How can/should I
go about doing so?
If I should use a ServletExtension, to clarify, I need to create a file
named "io.undertow.servlet.ServletExtension" and put it in the
"META-INF/services/" directory?
Within the above mentioned file do I need to provide the fully qualified
name of the implementation class?
Thanks.
Best,
Ari
11 years
Combining encoding handlers with non-encoding handlers
by Girish Sharma
Hi team,
I am trying to have a situation like this:
Path A - response is gzipped,
Path B - response is *not* gzipped.
But from extensive searching, I could only figure out a way to make all
paths as gzipped response.
For example:
Undertow.builder().addHttpListener(8080, "localhost").setHandler(new
EncodingHandler(new ContentEncodingRepository().addEncodingHandler(
"gzip",
new GzipEncodingProvider(),
50,
Predicates.parse("max-content-size[5]")
)
).setNext(Handlers.path()
.addPrefixPath("/pathA", pathA::handle)
.addPrefixPath("/pathB", pathAB::handle
)).build();
will make both Path A and Path B as gzip encoded response.
Any way to make only 1 of them give gzipped response?
Regards
--
Girish Sharma
B.Tech(H), Civil Engineering,
Indian Institute of Technology, Kharagpur
11 years
