Closed glassfishrobot closed 10 years ago
Reported by umjoshi
umjoshi said: Implemented conditional rejection of out of order message at RMD. Client will get back a SOAP fault with HTTP 500 if an out of order message is sent. This is driven by rejectOutOfOrderMessagesEnabled property on com.sun.xml.ws.rx.rm.api.ReliableMessagingFeature. Default behavior is not changed yet, keeping this bug/issue open to decide if the default behavior should be changed.
umjoshi said: Closing this issue as there is now a boolean on the Metro RM Feature to prevent this from happening. Not changing the default.
Was assigned to umjoshi
This issue was imported from java.net JIRA WSIT-1676
Marked as fixed on Monday, October 28th 2013, 12:53:46 pm
There is a class com.sun.xml.ws.rx.rm.runtime.delivery.InOrderDeliveryQueue used by the com.sun.xml.ws.rx.rm.runtime.ServerTube that makes request messages that are received out of order wait in a postponedMessageQueue (in-memory queue). After some out of order message is retained this way the Fiber is marked as suspended by the ServerTube and is not resumed in the normal course (no wind down, back-channel is not closed, no response goes back to the client). This Fiber will be resumed only if the out-of-order problem gets corrected and the waiting message gets delivered to the application layer. What if some rogue client keeps on sending out-of-order messages (say, message# 2 is withheld for very long and other sent messages are large in size). This is one of the security threats under the category "resource consumption" discussed in the RM spec (see below).
http://docs.oasis-open.org/ws-rx/wsrm/200608/wsrm-1.1-spec-cd-04.html#5.1.2.Resource Consumption Threats|outline
Of course, using SC (SecureConversation) with WS-RM will make sure that no rogue client is entertained like this but still this is a bug that needs to be looked at.
Affected Versions
[current]