Possible thread race between the CometSelector and CometContext when adding/resuming CometHandler under high load

[glassfishrobot]

The current cometd-client test fail from time to time and as Shing Wai observed, the test fail because the resumeCometHandler return false (failed resume) instead of true. The issue is caused by a race (produced by the cometd module) where addCometHandler has not finished to execute when resumeCometHandler gets invoked.

Internally the CometTask has not yet been attached to cometKey and hence resume fail. It may also be caused because the same CometHandler is resumed twice.

Environment

Operating System: All Platform: All

Affected Versions

[1.9.8]

[glassfishrobot]

• Issue Imported From: https://github.com/javaee/grizzly/issues/483
• Original Issue Raised By:@glassfishrobot
• Original Issue Assigned To: @glassfishrobot
• Original Issue Closed By:@glassfishrobot

[glassfishrobot]

@glassfishrobot Commented Reported by jfarcand@java.net

[glassfishrobot]

@glassfishrobot Commented jfarcand@java.net said: Possible fix. I suspect there is other corner case this fix isn't covering, hence not closing the issue for now.

Sending comet/src/main/java/com/sun/grizzly/comet/CometContext.java Sending comet/src/main/java/com/sun/grizzly/comet/CometEngine.java Sending comet/src/main/java/com/sun/grizzly/comet/CometSelector.java Transmitting file data ... Committed revision 2644.

[glassfishrobot]

@glassfishrobot Commented jfarcand@java.net said: Fix title

[glassfishrobot]

@glassfishrobot Commented gustav3d@java.net said: Sending java/grizzly/trunk/code/modules/comet/src/main/java/com/sun/grizzly/comet/CometEngine.java Transmitting file data ... Committed revision 2661.

selectionkeys used by comet in grizzly main selector are geting their attachment set to Long within a few ms after cometselector registration, this triggers cometselector idletimeout code path that detects Long attachment in the mainkey and cancels the cometkey and removes its attachment, leading to failed resumes due to cometselector.cancelkey returns false when the attachment already is null.

to mitigate this problem i set the attachment to "comet" instead of null in cometengine.handle so is this a new problem, or has it existed all the way back to when i removed the bannedkey list in grizzly keep alive code ?. its very strange if this has managed to stay undetected for several months, it fails the comet unit tests rather badly.

later today i will be able to test on non linux platforms to see if the recent cometcontext fixes are still needed or not. (cometD-client tests works rather well regardless of these fixes here, comet unit tests however dont)

[glassfishrobot]

@glassfishrobot Commented jfarcand@java.net said: Bump version

[glassfishrobot]

@glassfishrobot Commented jfarcand@java.net said: Bump version

[glassfishrobot]

@glassfishrobot Commented gustav3d@java.net said: this issue is invalid: cometD is completely single threaded so its impossible for it to cause such threadrace.

[glassfishrobot]

@glassfishrobot Commented gustav3d@java.net said: bah, wrong by me !, there is still a chance that servlet post execute will overlap with a resume.

cometD could perhaps wait for onInitialize before making the handler available for cometD operations ?.

[glassfishrobot]

@glassfishrobot Commented jfarcand@java.net said: FYI, The CometSelector runs on another thread so they are still possible racing issue (until we merge your change ) Your recommendation will improve the situation for sure...

[glassfishrobot]

@glassfishrobot Commented jfarcand@java.net said: This is fixed by:

https://grizzly.dev.java.net/issues/show_bug.cgi?id=409

[glassfishrobot]

@glassfishrobot Commented Was assigned to jfarcand@java.net

[glassfishrobot]

@glassfishrobot Commented This issue was imported from java.net JIRA GRIZZLY-483

[glassfishrobot]

@glassfishrobot Commented Marked as fixed on Wednesday, December 16th 2009, 6:13:09 pm