This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 33467

Summary: Support for Interruption of Long Running RP.Tasks
Product: platform Reporter: Jaroslav Tulach <jtulach>
Component: -- Other --Assignee: Jaroslav Tulach <jtulach>
Severity: blocker CC: apireviews, jglick, mryzl, pkuzel, pnejedly
Priority: P2 Keywords: API, API_REVIEW_FAST, THREAD
Version: 3.x   
Hardware: PC   
OS: Linux   
Issue Type: ENHANCEMENT Exception Reporter:
Bug Depends on:    
Bug Blocks: 35753, 58530    
Attachments: Implementation with a test
New version suitable for main trunk that addresses reviewers comments
WizardDescriptor patch
Let's try once more: Here is new compatible version, can you review it?

Description Jaroslav Tulach 2003-05-07 14:50:27 UTC
There shall be a way how to interrupt long running
tasks posted in the request processor.

The standard Java way for checking for
interruption in using Thread.interrupted() or
InterruptedException. I suggest to enhance
RP.Task.cancel() is when the task is running its
thread is sent to interrupted state and the task's
runnable can check the Thread.interrupted() value
and exit promptly.
Comment 1 Jaroslav Tulach 2003-05-07 14:50:56 UTC
Created attachment 10245 [details]
Implementation with a test
Comment 2 Jesse Glick 2003-05-07 15:22:36 UTC
Sounds good to me.
Comment 3 Petr Nejedly 2003-05-12 09:14:20 UTC
One little possible problem may be with those ugly inlined tasks:
Posted A, x1, x2, B, A waits for B -> B is executed from inside
A's run()
Now A gets cancelled but the interrupt flag is set inside B's
context -> B may stop processing.
But the B may be started by different condition than A's request
and A may only need latest B's results by a coincidence,
so it will break the other B's client (who originally posted it)
Comment 4 Jaroslav Tulach 2003-05-13 08:04:09 UTC
To implement Petr's comment I have branched RequestProcessor and
RequestProcessorTest. Use

cvs upd -f -r interrupt_33467 openide

to get the current version
Comment 5 Jesse Glick 2003-08-25 23:01:04 UTC
Probably this is better handled as a part of issue #27403. The simple
support in java.lang.Thread does not handle a lot of the things we
might need.
Comment 6 Jaroslav Tulach 2003-10-17 13:25:11 UTC
Not working on it right now.
Comment 7 _ pkuzel 2005-05-09 13:47:20 UTC
Thread.interrupted() is needed if thread performs I/O operations. Without
interrupt() thead may block forever (if code uses sockets without timeouts).

Introducing issue #58530 dependency, this semantics would allow me to use
RequestProcessor.Task instead of plain Thread for background wizard validation.
Comment 8 Jaroslav Tulach 2005-05-09 16:35:00 UTC
Ok, this seems like a good reason to implement this issue. [btw. you have not 
confirmed that the patch works for you]. I'll polish it a bit and ask for 
review, in a month or so. 
Comment 9 Jaroslav Tulach 2005-06-02 21:39:11 UTC
Created attachment 22461 [details]
New version suitable for main trunk that addresses reviewers comments
Comment 10 Jaroslav Tulach 2005-06-02 21:42:07 UTC
to pkuzel: verify that this change works for you. 
to pnejedly: inlined tasks shall be correctly handled, see the last two tests. 
to jglick: progress api is good, but as shows pkuzel's case, this is desirable anyway. 
to reviewers: please speak up if you have some comments. As soon as pkuzel 
confirms and a review period is gone, I'd like to integrate. 
Comment 11 Petr Nejedly 2005-06-03 10:13:12 UTC
Looks good to me. It took me a while to see where do you interrupt the original
task in case cancel() comes while an inlined task is running, but it is covered
by the test so I reread the source and got it...

Maybe just add small line comment about it above this test:
    if (interrupted || todo.item == null) {

Comment 12 _ pkuzel 2005-06-09 10:53:28 UTC
Cool, I got wanted I/O interruption:

INFORMATIONAL *********** Exception occurred ************ at 11:48 AM on Jun 9, 2005
Annotation: Test connection failed, suggesting to use a proxy.
        at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(
        at sun.nio.cs.StreamDecoder$CharsetSD.implRead(
[catch] at
        at org.openide.WizardDescriptor$

Comment 13 _ pkuzel 2005-06-09 10:54:24 UTC
Created attachment 22576 [details]
WizardDescriptor patch
Comment 14 _ pkuzel 2005-06-09 10:55:28 UTC
Please, apply  WD.patch on your integration. Thank you.
Comment 15 Jaroslav Tulach 2005-06-09 14:56:36 UTC
Ok. Let's integrate tomorrow. 
Comment 16 Jaroslav Tulach 2005-06-10 17:15:45 UTC
cvs -q ci -m "#33467: RP.Task.cancel does Thread.interrupt() and allowes the 
Runnables to check for interruptions or exit from blocked io operations" 
Checking in dialogs/src/org/openide/; 
/cvs/openide/dialogs/src/org/openide/,v  <-- 
new revision: 1.6; previous revision: 1.5 
Checking in util/apichanges.xml; 
/cvs/openide/util/apichanges.xml,v  <--  apichanges.xml 
new revision: 1.6; previous revision: 1.5 
Checking in util/; 
/cvs/openide/util/,v  <-- 
new revision: 1.4; previous revision: 1.3 
Checking in util/src/org/openide/util/; 
/cvs/openide/util/src/org/openide/util/,v  <-- 
new revision: 1.2; previous revision: 1.1 
Checking in util/test/unit/src/org/openide/util/; 
new revision: 1.2; previous revision: 1.1 
Comment 17 Petr Nejedly 2005-06-21 12:49:48 UTC
Implementation rolled back because of incompatibility with existing uses.
See #59904, #60313
Comment 18 Maros Sandor 2005-06-21 13:49:20 UTC
Rolling back patch in trunk and QBE200506142000.

/cvs/openide/dialogs/src/org/openide/,v  <--
new revision: 1.7; previous revision: 1.6
/cvs/openide/dialogs/src/org/openide/,v  <--
new revision:; previous revision: 1.6
Comment 19 Jaroslav Tulach 2005-06-22 22:22:31 UTC
Created attachment 22858 [details]
Let's try once more: Here is new compatible version, can you review it?
Comment 20 Maros Sandor 2005-06-23 09:21:33 UTC
I see that all wizards share a single RP ... can more wizards be active at the
same time? If so, it would be better not to share it.
Comment 21 Petr Nejedly 2005-06-24 10:39:09 UTC
I originally thought you'll use marker interface on the runnable/task to have
per-Task control, but per-RP granularity is probably good enough and more

I've never seen more wizards running at once, anyway, should it be a concern, it
is possible to use RP with higher throughput that 1. Moreover, you still have
only one CPU and the background processing is running on a background because
you expect it may take longer or block, right?
Comment 22 Maros Sandor 2005-06-24 11:00:21 UTC
I thought about a usecase where background validation eventually starts another
wizard (e.g. to configure network settings). The risk here is that the second
wizard must not use backgound validation.
Comment 23 Jaroslav Tulach 2005-07-03 14:39:43 UTC
cvs -q ci -m "Another attempt to fix #33467. RP by default keeps 
compatibility, there is new constructor to enable the interrupt() behaviour. 
As requested by msandor, the throughput of WizardDescriptor RP is higher than 
Checking in dialogs/src/org/openide/; 
/cvs/openide/dialogs/src/org/openide/,v  <-- 
new revision: 1.8; previous revision: 1.7 
Checking in util/apichanges.xml; 
/cvs/openide/util/apichanges.xml,v  <--  apichanges.xml 
new revision: 1.7; previous revision: 1.6 
Checking in util/src/org/openide/util/; 
/cvs/openide/util/src/org/openide/util/,v  <-- 
new revision: 1.6; previous revision: 1.5 
Checking in util/test/unit/src/org/openide/util/; 
new revision: 1.4; previous revision: 1.3