Bugzilla – Bug 3945
Stack trace messages in RFT
Last modified: 2008-03-17 15:52:51
You need to log in before you can comment on or make changes to this bug.
Bug 2070 reported a specific instance where RFT dumps a long stack trace instead of simply catching and reporting an error with a simple one-line message. 2070 is reported as being fixed, but there are plenty of similar issues, so I would guess that only the specific error reported was fixed. I include below some notes I took a couple of weeks back; again, these are specific situations, but there's a real need to handle *all* common errors properly, and reserve dumping the stack for errors that are unexpected and unrecognized. A "-debug" or "-verose" flag would be useful to switch the stack trace on. Again, the notes below are just examples - there really needs to be a review of *all* expected errors, with a well-constructed, useful message for each case. EXAMPLES ======== Expired proxy: ------------- Exception in thread "main" Error during startup processing. Caused by org.globus.gsi.GlobusCredentialException: Expired credentials (O=Grid,O=HP,OU=MLL,CN=Jem Treadwell,CN=1989082797). at org.globus.gsi.GlobusCredential.verify(GlobusCredential.java:303) at org.globus.gsi.GlobusCredential.getDefaultCredential(GlobusCredential.java:528) at org.globus.transfer.reliable.client.BaseRFTClient.delegateCredential(BaseRFTClient.java:280) at org.globus.transfer.reliable.client.ReliableFileTransferClient.main(ReliableFileTransferClient.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.globus.bootstrap.BootstrapBase.launch(BootstrapBase.java:95) at org.globus.bootstrap.Bootstrap.main(Bootstrap.java:37) No Proxy: -------- [jem@risk rft]$ grid-proxy-destroy [jem@risk rft]$ rft -h risk.usa.hp.com -f jt.xfr Exception in thread "main" Error during startup processing. Caused by org.globus.gsi.GlobusCredentialException: Proxy file (/tmp/x509up_u7734) not found. at org.globus.gsi.GlobusCredential.<init>(GlobusCredential.java:98) at org.globus.gsi.GlobusCredential.getDefaultCredential(GlobusCredential.java:526) at org.globus.transfer.reliable.client.BaseRFTClient.delegateCredential(BaseRFTClient.java:280) at org.globus.transfer.reliable.client.ReliableFileTransferClient.main(ReliableFileTransferClient.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.globus.bootstrap.BootstrapBase.launch(BootstrapBase.java:95) at org.globus.bootstrap.Bootstrap.main(Bootstrap.java:37) Invalid config (commented out the "maximum number of retries" value): -------------------------------------------------------------------- Exception in thread "main" Error during startup processing. Caused by java.lang.NumberFormatException: For input string: "gsiftp://risk.usa.hp.com:2820/tmp/jt1.in" at java.lang.NumberFormatException.forInputString(NumberFormatException.java:48) at java.lang.Integer.parseInt(Integer.java:447) at java.lang.Integer.valueOf(Integer.java:553) at org.globus.transfer.reliable.client.ReliableFileTransferClient.getTransfer(ReliableFileTransferClient.java:117) at org.globus.transfer.reliable.client.ReliableFileTransferClient.main(ReliableFileTransferClient.java:171) 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.globus.bootstrap.BootstrapBase.launch(BootstrapBase.java:95) at org.globus.bootstrap.Bootstrap.main(Bootstrap.java:37)
I am changing the target version to 4.2 for this fix as it may involve adding a new commandline parameter ) -verbose).
Created an attachment (id=783) [details] patch against Bootstrap, ReliableFileTransferClient and ReliableFileDeleteClient This patch surrounds whole body of "main" method with try/catch block. Inside of the catch block there is an invocation of the exception handling class' method (ExceptionHandler, you may find it in the next attachment).
Created an attachment (id=784) [details] An exception handling class. This class has a few methodes. One that is currently used, ie. error(Exception e, Class clazz) obtains logger for "clazz" and checks logging level. If it's equal to ALL or DEBUG, stack trace is printed. Otherwise it prints only a short message.
Ravi, you are perfectly right about not adding any new commandline parameters. But in GridwiseTech, Chris Wilk and I have developed a bit different solution. You may find it in the attachment. It doesn't require adding any new commandline parameters. It just checks logging level for the class throwing an exception and makes decision (either to write only a short message or to print whole stack trace) on the base of that information.
Hi I like the ExceptionHandler portion of the patch. I think a better solution would be to implement RFT clients using the full functionality provided by BaseClient API in Core. I will use the patch provided when i implement that.
This should be fixed in 4.0.7
