Community
Participate
Working Groups
1. Open an xml file on Unix 2. Modify and save it The following Exception occurs intermittently. java.lang.IllegalArgumentException: Argument cannot be null at org.eclipse.swt.SWT.error(Unknown Source) at org.eclipse.swt.SWT.error(Unknown Source) at org.eclipse.swt.SWT.error(Unknown Source) at org.eclipse.swt.widgets.Widget.error(Unknown Source) at org.eclipse.swt.widgets.TreeItem.setText(Unknown Source) at org.eclipse.swt.widgets.TreeItem.setText(Unknown Source) at org.eclipse.rse.internal.ui.view.SystemView.doUpdateItem(Unknown Source) at org.eclipse.jface.viewers.AbstractTreeViewer$UpdateItemSafeRunnable.run(Unknown Source) at org.eclipse.core.runtime.SafeRunner.run(Unknown Source) at org.eclipse.ui.internal.JFaceUtil$1.run(Unknown Source) at org.eclipse.jface.util.SafeRunnable.run(Unknown Source) at org.eclipse.jface.viewers.AbstractTreeViewer.doUpdateItem(Unknown Source) at org.eclipse.rse.internal.ui.view.SafeTreeViewer.doUpdateItem(Unknown Source) at org.eclipse.jface.viewers.StructuredViewer$UpdateItemSafeRunnable.run(Unknown Source) at org.eclipse.core.runtime.SafeRunner.run(Unknown Source) at org.eclipse.ui.internal.JFaceUtil$1.run(Unknown Source) at org.eclipse.jface.util.SafeRunnable.run(Unknown Source) at org.eclipse.jface.viewers.StructuredViewer.updateItem(Unknown Source) at org.eclipse.jface.viewers.StructuredViewer.internalUpdate(Unknown Source) at org.eclipse.rse.internal.ui.view.SystemView.update(Unknown Source) at org.eclipse.rse.internal.ui.view.SystemView.updateRemoteObjectProperties(Unknown Source) at org.eclipse.rse.internal.ui.view.SystemView$ResourceChangedJob.runInUIThread(Unknown Source) at org.eclipse.rse.internal.ui.view.SystemView.systemResourceChanged(Unknown Source) at org.eclipse.rse.internal.core.model.SystemResourceChangeManager.notify(Unknown Source) at org.eclipse.rse.internal.core.model.SystemRegistry$NotifyResourceChangedRunnable.run(Unknown Source) at org.eclipse.swt.widgets.RunnableLock.run(Unknown Source) at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Unknown Source) at org.eclipse.swt.widgets.Display.runAsyncMessages(Unknown Source) at org.eclipse.swt.widgets.Display.readAndDispatch(Unknown Source) at org.eclipse.ui.internal.Workbench.runEventLoop(Unknown Source) at org.eclipse.ui.internal.Workbench.runUI(Unknown Source) at org.eclipse.ui.internal.Workbench.access$4(Unknown Source) at org.eclipse.ui.internal.Workbench$7.run(Unknown Source) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Unknown Source) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Unknown Source) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(Unknown Source) at org.eclipse.ui.internal.ide.application.IDEApplication.start(Unknown Source) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(Unknown Source) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(Unknown Source) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(Unknown Source) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(Unknown Source) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(Unknown Source) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.eclipse.equinox.launcher.Main.invokeFramework(Unknown Source) at org.eclipse.equinox.launcher.Main.basicRun(Unknown Source) at org.eclipse.equinox.launcher.Main.run(Unknown Source) at org.eclipse.equinox.launcher.Main.main(Unknown Source)
Which Unix system do you hit this on - USS or something else? Also which version of RSE are you using? In the Remote Systems->Files preference page which File Transfer Mode is set for .xml?
The system is USS. The version is 3.2.2. The file transfer mode is set to Binary.
(In reply to comment #2) > The system is USS. The version is 3.2.2. The file transfer mode is set to > Binary. I tried this on a USS system but didn't hit the problem. I can't think of any reason why an xml file would hit this exception but not some other type of file.
I got the following description from the original submitter. It looks xml file type has nothing to do with the problem, but the xml file in error was tend to be accessed simultaneously. It looks like the problem is a file locking problem. If I am editing the file and someone access the same file (Push To client) the NPE appears. If someone is editing the same file and I try to save it I get the NPE. If the file is being used or accessed by another user and I try to open it I get the NPE and I cannot edit or open the file until I disconnect and reconnect from the host.
(In reply to comment #4) > I got the following description from the original submitter. It looks xml file > type has nothing to do with the problem, but the xml file in error was tend to > be accessed simultaneously. > > It looks like the problem is a file locking problem. If I am editing the file > and someone access the same file (Push To client) the NPE appears. If someone > is editing the same file and I try to save it I get the NPE. If the file is > being used or accessed by another user and I try to open it I get the NPE and I > cannot edit or open the file until I disconnect and reconnect from the host. The file support in Open RSE does not account for locking. Is this locking mechanism specific to USS or can the problem be reproduced on any system where there is concurrent file editing and saving?
Locking may be wrong term. No locking mechanism is used for USS either. So what he meant is concurrent update.
(In reply to comment #6) > Locking may be wrong term. No locking mechanism is used for USS either. So > what he meant is concurrent update. Does the customer get a save conflict dialog? I've tried to reproduce this with a Linux connection while editing the same file in vi but I'm not hitting the issue; not sure whether it should make any difference that it's on Linux versus USS. Have you been able to reproduce it?
Masao, are you going to get back to me on this one?
No. Since I cannot reproduce the error, you were working with the originator, Eric Hambright.
(In reply to comment #9) > No. Since I cannot reproduce the error, you were working with the originator, > Eric Hambright. Can Eric be added to the CC list for this defect?
(In reply to comment #10) > (In reply to comment #9) > > No. Since I cannot reproduce the error, you were working with the originator, > > Eric Hambright. > Can Eric be added to the CC list for this defect? I did not see a save conflict error and I have not been able to reproduce the problem with the latest RDz 8.0.3 builds. The problem would occur when multiple users access the file while I was editing or saving it.
(In reply to comment #11) > (In reply to comment #10) > > (In reply to comment #9) > > > No. Since I cannot reproduce the error, you were working with the originator, > > > Eric Hambright. > > Can Eric be added to the CC list for this defect? > > I did not see a save conflict error and I have not been able to reproduce the > problem with the latest RDz 8.0.3 builds. The problem would occur when multiple > users access the file while I was editing or saving it. The exception shown in this bug has come up before but in unrelated scenarios. There were some changes in the universal file stuff that should reduce the chances of this happening via bug 323299 but, since this was reproduced with RSE 3.2.2, it is probably already in there.
Hi Devid, I have asked Eric if he still see this issue with the latest version, and he agreed to close this since he haven't seen this problem in a while. You can close this. I'm going to close our corresponding defect for RDz.
Resolving as worksforme.
