Community
Participate
Working Groups
Have a dstore connection connected. Quit RSE, stop the remote server or make it unavailable. Restart RSE, it will try to reconnect (Preference setting restore tree). Quit RSE while connect is still ongoing. Observe InterruptedException in the PDE Errorlog: these exceptions should not be shown. For correctly dealing with InterruptedException, see http://michaelscharf.blogspot.com/2006/09/dont-swallow-interruptedexception-call.html When addressing this, all RSE code should be searched for how InterruptedException is treated. Mind that in many cases, exception handlers will just catch(Exception e) which is harder to find but just as bad. java.lang.InterruptedException at org.eclipse.rse.core.subsystems.AbstractConnectorService.promptForPassword(AbstractConnectorService.java:577) at org.eclipse.rse.connectorservice.dstore.DStoreConnectorService$2.run(DStoreConnectorService.java:1045) at org.eclipse.ui.internal.UILockListener.doPendingWork(UILockListener.java:155) at org.eclipse.ui.internal.UISynchronizer$2.run(UISynchronizer.java:125) at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35) at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:123) at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3467) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3107) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2264) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2228) at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2103) at org.eclipse.ui.internal.Workbench$4.run(Workbench.java:457) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:289) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:452) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149) at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:101) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:146) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:106) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:76) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:354) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:169) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:476) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:416) at org.eclipse.equinox.launcher.Main.run(Main.java:1124) at org.eclipse.equinox.launcher.Main.main(Main.java:1099) -----------Enter bugs above this line----------- installation : eclipse-SDK-3.3M5 (I20070209-1006) RSE install : RSE-SDK 2.0M5 java.runtime : Sun 1.5.0_11 os.name: : Windows XP 5.1, Service Pack 2 ------------------------------------------------ systemtype : Unix-ssh / Linux-dstore (REXEC Launcher) targetos : Red Hat Enterprise Linux WS release 4 (Nahant Update 3) targetuname : Linux parser.takefive.co.at 2.6.9-34.EL #1 Fri Feb 24 16:44:51 EST 2006 i686 athlon i386 GNU/Linux targetvm : Sun Java HotSpot(TM) Client VM (build 1.4.2_13-b06, mixed mode) ------------------------------------------------
The prompting connector service stuff has changed quite a bit since this defect was created. Is this still a problem?
The real problem here is, that RSE uses InterruptedException instead of OperationCanceledException in order to report user cancellation - see bug #190750. Because of this, we cannot know whether an InterruptedException we catch is due to the Thread actually being interrupted e.g. as part of a shutdown sequence, or due to normal user cancellation. The blog entry mentioned in the description only applies for thread interruption, which is by far less likely than user cancellation. Therefore, I think that for now we should just catch InterruptedException without logging it, as discussed in bug #190803. When this is done, the exception should no longer be logged (should be verified) and this bug can be marked fixed. We will deal with correct handling of InterruptedException through bug #190750 in the Future.
> > Therefore, I think that for now we should just catch InterruptedException > without logging it, as discussed in bug #190803. When this is done, the > exception should no longer be logged (should be verified) and this bug can be > marked fixed. We will deal with correct handling of InterruptedException > through bug #190750 in the Future. > Right now, the DStoreConnectorService does not catch the InterruptedExceptions. It ends up throwing them as does the AbstractConnectorService. Beyond this, the exception handling lies in the hands of clients. I'm not sure whether you're looking for additional logging in the connector service before throwing/passing on the exceptions or whether you want to use this defect to change the clients that actually catch the exceptions.
Since the connector service now just throws the interrupted exceptions to clients, I think this is invalid.
[target cleanup] 2.0 RC3 was the original target milestone for this bug
