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.
Summary: | Support for Interruption of Long Running RP.Tasks | ||
---|---|---|---|
Product: | platform | Reporter: | Jaroslav Tulach <jtulach> |
Component: | -- Other -- | Assignee: | Jaroslav Tulach <jtulach> |
Status: | RESOLVED FIXED | ||
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
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 |