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.
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.
Created attachment 10245 [details] Implementation with a test
Sounds good to me.
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)
To implement Petr's comment I have branched RequestProcessor and RequestProcessorTest. Use cvs upd -f -r interrupt_33467 openide to get the current version
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.
Not working on it right now.
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.
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.
Created attachment 22461 [details] New version suitable for main trunk that addresses reviewers comments
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.
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) {
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. java.io.InterruptedIOException at org.netbeans.modules.proxy.InterruptibleInputStream.waitAvailable(InterruptibleInputStream.java:47) at org.netbeans.modules.proxy.InterruptibleInputStream.read(InterruptibleInputStream.java:38) at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:411) at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) at java.io.InputStreamReader.read(InputStreamReader.java:167) at java.io.BufferedReader.fill(BufferedReader.java:136) at java.io.BufferedReader.readLine(BufferedReader.java:299) at java.io.BufferedReader.readLine(BufferedReader.java:362) at org.netbeans.modules.proxy.ClientSocketFactory.getHttpsTunnelSocket(ClientSocketFactory.java:256) at org.netbeans.modules.proxy.ClientSocketFactory.createSocket(ClientSocketFactory.java:459) at org.netbeans.modules.proxy.ClientSocketFactory$1.connect(ClientSocketFactory.java:56) [catch] at org.netbeans.modules.versioning.system.cvss.ui.wizards.CheckoutWizard$RepositoryStep.validateBeforeNext(CheckoutWizard.java:531) at org.netbeans.modules.versioning.system.cvss.ui.wizards.CheckoutWizard$AbstractStep.validate(CheckoutWizard.java:955) at org.openide.WizardDescriptor$4.run(WizardDescriptor.java:1100)
Created attachment 22576 [details] WizardDescriptor patch
Please, apply WD.patch on your integration. Thank you.
Ok. Let's integrate tomorrow.
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/WizardDescriptor.java; /cvs/openide/dialogs/src/org/openide/WizardDescriptor.java,v <-- WizardDescriptor.java new revision: 1.6; previous revision: 1.5 done Checking in util/apichanges.xml; /cvs/openide/util/apichanges.xml,v <-- apichanges.xml new revision: 1.6; previous revision: 1.5 done Checking in util/manifest.mf; /cvs/openide/util/manifest.mf,v <-- manifest.mf new revision: 1.4; previous revision: 1.3 done Checking in util/src/org/openide/util/RequestProcessor.java; /cvs/openide/util/src/org/openide/util/RequestProcessor.java,v <-- RequestProcessor.java new revision: 1.2; previous revision: 1.1 done Checking in util/test/unit/src/org/openide/util/RequestProcessorTest.java; /cvs/openide/util/test/unit/src/org/openide/util/RequestProcessorTest.java,v <-- RequestProcessorTest.java new revision: 1.2; previous revision: 1.1
Implementation rolled back because of incompatibility with existing uses. See #59904, #60313
Rolling back WizardDescriptor.java patch in trunk and QBE200506142000. /cvs/openide/dialogs/src/org/openide/WizardDescriptor.java,v <-- WizardDescriptor.java new revision: 1.7; previous revision: 1.6 /cvs/openide/dialogs/src/org/openide/WizardDescriptor.java,v <-- WizardDescriptor.java new revision: 1.6.2.1; previous revision: 1.6
Created attachment 22858 [details] Let's try once more: Here is new compatible version, can you review it?
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.
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 lightweight. msandor: 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?
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.
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 one" Checking in dialogs/src/org/openide/WizardDescriptor.java; /cvs/openide/dialogs/src/org/openide/WizardDescriptor.java,v <-- WizardDescriptor.java new revision: 1.8; previous revision: 1.7 done Checking in util/apichanges.xml; /cvs/openide/util/apichanges.xml,v <-- apichanges.xml new revision: 1.7; previous revision: 1.6 done Checking in util/src/org/openide/util/RequestProcessor.java; /cvs/openide/util/src/org/openide/util/RequestProcessor.java,v <-- RequestProcessor.java new revision: 1.6; previous revision: 1.5 done Checking in util/test/unit/src/org/openide/util/RequestProcessorTest.java; /cvs/openide/util/test/unit/src/org/openide/util/RequestProcessorTest.java,v <-- RequestProcessorTest.java new revision: 1.4; previous revision: 1.3