facundovs
commented
6 years ago I've created this test case to reproduce the issue.
Just clone my fork and run it.
Closed facundovs closed 1 year ago
facundovs
commented
6 years ago I've created this test case to reproduce the issue.
Just clone my fork and run it.
fsgonz
commented
6 years ago I think the problem arises because the completion handler in the connect method in SingleEndpointPool is registered after connect. Internally as there is no completionHandler a default completion handler is used and the read operation is enabled resulting in the race condition (it is possible that the read operation is performed before the write).
This happens here:
I've created a possible fix (but it involves changing the interface), so that the completionHandler can be passed and the future can retrieved to manage the timeout.
https://github.com/fsgonz/grizzly-1/commit/f8edf95a7e404bd147a6b8e36ec53a9209f0f6d8
This also involves changing the AhcEndpoint in ahc.
Let me know what you think about these possible changes.
fsgonz
commented
6 years ago Notice that I don't find a way to avoid the race condition without changing the endpoint abstract class.
Hi guys.
In the Mule ESB we are facing the following sporadic NPEs with the following stack trace:
After some investigation I could discover that:
1) In the scenario when the issue Is reproduced, the non-blocking requestQueue saved in the connection as an atribute returns NULL in this line. This seems to be a race condition what takes place when the writting and the reading are done asynchronously (and the reading occurs faster than the writting, which puts the request packet in the queue after the reading thread polls it).
2) The issue is a consequence of the interaction between Grizzly AHC and the Grizzly Framework:
As you see; the race condition occurs between the requester thread and the selector thread. I was able to reproduce the case, creating a SocketServer that just starts to read the HTTP response when the connection is stablished. I am aware of that writting the response without reading the request first or reading the request and writting the response asynchronously are not the most common scenarios; but shouldn't this cases be contemplated? Anyway, Failing with a NPE is not aceptable... At least a validation with a descriptive error should be added.
Note: I've also see that the read operation is enabled as soon the connection is ready, what is the root cause of the race condition, as you see here.
Thank you very much.