-
Bug
-
Resolution: Done
-
Major
-
None
-
1.0.0.Beta18
-
None
-
None
Seems that ReadDispatchChannel awaitReadable() has an issue and fails to return when there is more data available to read. I've noticed this on FormEncodedDataParser#parseBlocking() getting stuck, whenever the doParse() doesn't have all the data available at once.
See https://github.com/emmartins/undertow/compare/1.0.0.Beta18...unstuck-read-channel
I did replace the awaitReadable() with the one that times out, and voila, once the timeout occurs then doParse() continues parsing.
Log for the case when all data is available at once:
15:39:12,408 WARN [io.undertow.request] (default task-3) FormEncodedDataParser.doParse() bytes read: 2857
15:39:12,410 WARN [io.undertow.request] (default task-3) FormEncodedDataParser.doParse() bytes read: -1
Log for the case when all data is not available at once:
15:39:52,758 WARN [io.undertow.request] (default task-4) FormEncodedDataParser.doParse() bytes read: 1
15:39:52,758 WARN [io.undertow.request] (default task-4) FormEncodedDataParser.doParse() bytes read: 0
15:39:57,761 WARN [io.undertow.request] (default task-4) FormEncodedDataParser.doParse() bytes read: 2856
15:39:57,762 WARN [io.undertow.request] (default task-4) FormEncodedDataParser.doParse() bytes read: -1
Note the 5 seconds diff between the 2nd and 3rd log messages, it's the awaitReadable() timeout.