[RIVER-62] Mahalo's destroying processing should cause blocking calls to end early

• Type: Improvement
• Status: Open
• Priority: Minor
• Resolution: Unresolved
• Affects Version/s: jtsk_2.1
• Component/s: com_sun_jini_mahalo
• Bugtraq ID: 6261378
• Assignee: Unassigned
• Reporter: Robert Resendes
• Created: 26/Jul/07 16:18
• Updated: 26/Jul/07 16:18

Description

Bugtraq ID 6261378

Blocking, in-progress calls (e.g. commit w/ timeout) cause the service to survive its destroy processing. The blocking calls' timeouts are respected so Mahalo will survive its destroy call until the last blocking call completes. In the extreme case, a "forever" timeout will cause Mahalo to hang around forever (assuming the transaction can't complete because, for example, a participant can't be contacted).

There's also the issue of stopping/interrupting transactions that are supposed to go to completion (e.g. committed transactions that still need to contact participants). Need to think about when it's OK to give up on these.

Notes:

• The "forever" timeout case can occur without explicitly requesting it. For example, mahalo currently has the code in its TxnManagerTransaction:commit processing:
  synchronized (jobLock) {
  if ((job instanceof PrepareJob) ||
  (job instanceof PrepareAndCommitJob)) {
  try {
  if (job.isCompleted(Long.MAX_VALUE)) {
  This last line will cause the call to block indefinitely if the "prepare" processing can't proceed (e.g. bad participant).

Contributing factors:

• The "forced" unexport (under JERI at least) doesn't seem to cause in-progress calls to terminate, so the client ends up waiting on the commit call past any declared timeout value.
• The destroy processing kills the task manager which prevents the Prepare*Task from being retried. Since the retries are what cause the "notify" and maxTries checks to occur, the "wait" call never times out.