On Thu, 24 Oct 2019 at 18:38, Jonas Konrad <
me@yawk.at> wrote:
What do you mean exactly by "not thread safe"?
It's my understanding that you'd use dispatch() in the handler, and then
proceed processing on the other thread. Is the problem that both your
own "worker" code and the parent http handlers could interact with the
exchange concurrently, which is solved by the dispatch(Executor,
Runnable) methods by delaying execution until the current handler is done?
Exactly this. Undertow avoids any synchronisation on the exchange, but instead enforces thread safety by ensuring that only a single thread is active at any point with a hand off mechanism.
In general any time you would like to use the no arg version of dispatch() you should use SameThreadExecutor instead, which will just run your task when the handler chain is done without handing off to a 'real' executor. In your case though it sounds like you actually want a real executor so just dispatch with the executor you want to use.
Stuart
yawkat
On 10/24/19 12:21 AM, Stuart Douglas wrote:
>
>
> On Thu, 24 Oct 2019 at 01:23, Pavel Shirshov <pshirshov@gmail.com
> <mailto:pshirshov@gmail.com>> wrote:
>
> Hi guys,
>
> Could you give me a hint if there is a way to write asynchronous
> handlers?
> So, I have my own asynchronous runtime (namely ZIO) and I wish
> undertow's worker thread to do something while it's waiting for
> request completion after a `dispatch` in my handler.
>
> Is there an API allowing me to return a Future or undertow's
> IOFuture so I may write an adaptor for my primitives?..
>
> From what I can see there is that zero-arg `.dispatch()` method
> which just changes internal flag. So, from what I can understand I
> may just set that flag and then complete my request totally
> asynchronously. Though that method is marked deprecated without an
> alternative - other versions also wait for a `Runnable`.
>
>
> In general you should not used the no arg version of dispatch(), it has
> been deprecated as it is not thread safe.
>
> If you want to just dispatch some work to a worker using the version
> that takes a runnable sounds like exactly what you are after, as it will
> run the runnable in a worker thread.
>
> Stuart
>
>
> --
> Thanks,
> Pavel
> _______________________________________________
> undertow-dev mailing list
> undertow-dev@lists.jboss.org <mailto:undertow-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/undertow-dev
>
>
> _______________________________________________
> undertow-dev mailing list
> undertow-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev
>
_______________________________________________
undertow-dev mailing list
undertow-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/undertow-dev