This message was deleted.

I need to check the code but it is plausible

can we somehow create a way to have events processed before the response is sent? e.g. finish all events for a serveevent before sending the response and/or having an extra event for "after" sending the response. With the state extension, I run into race conditions as the next request might rely on the state of the previous one.

It makes sense. As well as both sync and Async after-hooks

Yes, that part is necessarily async as Jetty uses non-blocking IO and

afterComplete

only occurs after the response has been fully sent. So there’s no way to make this synchronous unfortunately. Jetty did have a blocking IO connector a few versions ago but they dropped it IIRC. I suggest using

afterMatch

if you can as this is (or should be!) reliably synchronous.

is the response already available in

afterMatch

?

The response definition is. Would that work for you?

will try - should at least minimize the window then

Wonder if we should consider adding

afterResponseRendered

ah right - definition != rendered

I feel like

beforeComplete

is a bit ambiguous i.e. how far before complete are we?

when you e.g. create a new entity in a CRUD API, the response can contain a randomly generated ID. This ID is used in the next GET. One use case of the state extension is to retrieve data based on this ID, therefore I need to have it available for recording a state.

OK, makes sense. I’m looking at adding a new event as we discussed. Think I might call it

beforeResponseSent

as the best place to call it seems to be after response rendering + all other activities have taken place. Does this seem reasonable to you?

sounds good. That event would still be async, wouldn't it?

No, at that point we can still do it synchronously

nice

It’s the pushing bytes out over the (NIO) network connector that’s async

looks good - will give it a try soon

I’ll merge and release it in a new beta build