Correctly shutting down a websocket handler
by Robin Anil
When a client disconnects, I see that onClose is not being fired. The only
way this seems to be firing if client sents a close frame.
Is there any way to detect disconnection and immediately close all the
opened resources.
Robin
Robin Anil | Software Engineer
1 year, 2 months
Real path default resolution
by Brad Wood
I'm using Undertow for the deployment of Adobe ColdFusion and Lucee Server
sites, which for historical reasons and convenience, keeps two separate
folders for the WAR/web-inf and the actual web root where content is served
from.
In your typical J2EE setup, the real path "/" is the parent of "/WEB-INF"
but that is not the case for me and we use a custom resource manager with
great success to handle the correct resolution of paths in the server.
We have one issue however in the event of path resolution for non existent
files such as "/WEB-INF/cfform/logs/flex.log" which doesn't exist yet the
first time a server comes up. Since it doesn't exist, my custom resource
manager (who knows where the real WEB-INF lives) returns null as it should
which leaves it up to this line of code:
https://github.com/undertow-io/undertow/blob/ff4c9cf37872cb96070ba6a2fcbb...
to "guess" where the file would exist if it were to be created. Since it
roots it in the real path of "/", it guessing incorrectly in my case and
the result is I have folders and files created in the wrong directory.
This is rather tricky since my custom resource manager would tell the
servlet context exactly where "/WEB-INF" is if it were to ask that
question, but since it asks for "/", a different answer is given.
Interestingly enough, had the example provided in the final comment of this
ticket been followed, it would work for me since it progressively attempts
to resolve the path while peeling back directories one at a time until it
finds one that exists.
https://issues.jboss.org/browse/UNDERTOW-373?focusedCommentId=13036336&pa...
There's no comment on the ticket as to why that solution wasn't used, but I
would presume to avoid additional disk hits. I'm looking for ways that I
can still control how /WEB-INF is resolved with my custom resource manager,
even for non-existent paths. Save the progressive searching I mentioned in
the previous paragraph, the only other solution I can think of is for the
servlet contexts' getRealPath() to detect when a non existent path begins
with /WEB-INF and asking the resource manager to resolve /WEB-INF in that
case instead of / so it can get a more specific answer.
Thoughts?
Thanks!
~Brad
*Developer Advocate*
*Ortus Solutions, Corp *
E-mail: brad(a)coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com
6 years, 2 months
Access control examples
by Brad Wood
Hi, I'm looking for some examples of locking down access to certain
directories, similar to how IIS has "hidden segments". For instance, I'd
like all URLs starting with /CFIDE to be blocked, or perhaps only access to
a certain range of IPs
I swear I had looked at some examples of this about a year ago, but after
quite a lot of Googling today I was coming up empty handed. I found some
basic information on the access control handlers, but couldn't find a
single example of using them.
Thanks!
~Brad
*Developer Advocate*
*Ortus Solutions, Corp *
E-mail: brad(a)coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com
6 years, 2 months
Re: [undertow-dev] how to implement request processing timeout
by Stan Rosenberg
We ended up implementing hard timeout using CAS; no noticeable drop in
throughput or p99 latency.
I thought I'd share in case others on the list may need it. Here is the
code snippet (using Kotlin).
override fun handleRequest(exchange: HttpServerExchange) {
val timeoutWhenTrue = AtomicBoolean(true)
exchange.getIoThread().executeAfter({
if (timeoutWhenTrue.compareAndSet(true, false)) {
// we're first, so end the exchange
exchange.statusCode = StatusCodes.REQUEST_TIME_OUT
exchange.endExchange()
}
}, requestTimeoutMillis, TimeUnit.MILLISECONDS)
exchange.dispatch(SameThreadExecutor.INSTANCE, Runnable { launch {
//
// request servicing logic
//
if (timeoutWhenTrue.compareAndSet(true, false)) {
response.headers.forEach {
exchange.responseHeaders.add(it.key, it.value }
exchange.statusCode = response.statusCode
response.response?.let {
exchange.responseSender.send(response.response) } ?:
exchange.endExchange() }
}})
}
On Sun, Jul 22, 2018 at 2:59 AM Stan Rosenberg <stan.rosenberg(a)gmail.com>
wrote:
> On Sun, Jul 15, 2018 at 7:45 PM, Stuart Douglas <sdouglas(a)redhat.com>
> wrote:
>
>>
>>> Are you using the Servlet API or the HttpServerExchange API? The best
>>>> way to approach this is a bit different depending on what you are doing.
>>>>
>>>
>>> HttpServerExchange API
>>> . Thanks!
>>>
>>
>> This is a bit harder to do in the general case. With Servlet you could
>> just create a thread safe wrapper, where the wrapper basically disconnects
>> from the underlying request on timeout. The Undertow native API is not
>> designed around wrapping though, so it needs cooperation from the
>> application to manage this.
>>
>> If you know the application is only going to be writing data (and not
>> setting headers) then you should be able to make this work via a
>> ConduitFactory implementation that handles the locking, although if this is
>> not the case then you are going to need some kind of external lock.
>>
>>
> Could you please elaborate on the approach using ConduitFactory. Do
> you mean using 'exchange.addResponseWrapper' to intercept writes? That
> would require locking since write can be invoked from a different thread
> concurrently with timeout thread.
>
6 years, 2 months
