give clear error when gricli is out of date with backend

[yuriyh]

users should see clear indication when they have to download new version.

[vladimir-mencl-eresearch]

Yes. Not sure where the decision should come from - who should be holding the compatibility matrix - the client or the server?

The backend could be denying login if the client version is too old (or too new) and the client would interpret that as a message telling the user to update?

[yuriyh]

something may be done with web service versioning in cxf. @makkus ?

[makkus]

No idea how that would work, to be honest. Would require some investigatin'

If there is a new API signature, jax-ws client will throw exception. Probably easiest to try to catch that somehow and give generic error message "please download latest client from ..."?

[makkus]

All right, I did what I could on this one. Anything more would take a considerable bigger chunk of time.

What it does: if the SOAP wsdl changed, it'll print an error message like:

Could not connect to backend, probably because of frontend/backend incompatibility (Underlying cause: "Undefined operation name getInterfaceVersion"). Before reporting a bug, please try latest client from: http://code.ceres.auckland.ac.nz/stable-downloads.

This is obviously not the correct link for dev-clients, but I didn't want to clutter the message too much. Snapshot versions sit somewhere else, but users who use dev-clients just need to be aware of that.

If something else is changed (like if we change a name of a internal constant name like we are about to do and frontend/backend compatibility breaks because of that, I print a bit more finegrained message (not much though).

Hope that is good enough.

[yuriyh]

yeah i think this is enough for now.

[ndjones]

Should I have gotten this nice error yesterday, when I was running jython scripts and didn't have backend set to DEV?

I got the below exception when i tried to login:

Login failed: Could not do slcs login: java.lang.ClassNotFoundException:
grisu.control.serviceInterfaces.LocalServiceInterface

When I tried to relaunch I got this fuller exception stack:

office-extension:~ nick$ java -jar Downloads/grisu-jython-dev.jar hello-world.py 
Traceback (most recent call last):
  File "hello-world.py", line 5, in <module>
    si = LoginManager.loginCommandline()
    at grisu.frontend.control.login.LoginManager.login(LoginManager.java:369)
    at grisu.frontend.control.login.LoginManager.login(LoginManager.java:477)
    at grisu.frontend.control.login.LoginManager.login(LoginManager.java:495)
    at grisu.frontend.control.login.LoginManager.loginCommandline(LoginManager.java:593)
    at grisu.frontend.control.login.LoginManager.loginCommandline(LoginManager.java:514)
    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:597)

grisu.frontend.control.login.LoginException: grisu.frontend.control.login.LoginException: Could not login: 
java.lang.ClassNotFoundException: grisu.control.serviceInterfaces.LocalServiceInterface

When I changed to LoginManager.loginCommandline("DEV") backend inside the jython script it started working.

I've just tried to replicate this just now, and got the lovely new exception:

Login failed: Could not do slcs login: grisu.control.exceptions.ServiceInterfaceException: Could not connect to 
backend, probably because of frontend/backend incompatibility (Underlying cause: "Undefined operation name 
getInterfaceVersion"). Before reporting a bug, please try latest client from: http://code.ceres.auckland.ac.nz/stable-
downloads.

Definitely would be good to assign this issue to Sina, to tidy up the language being used, so that it's a proper user facing exception (slcs, grisu.control.. etc).

[makkus]

Not really sure why you got different behaviours, probably some version mixups. Since nobody (I thought) was using the jython thing I didn't really bother to make sure it gets built automatically whenever there are changes...

Gricli is probably a better client to test those things with, since there was more effort in building and deploying it...

[ndjones]

Yea, I wasn't trying to test this though, just coincidence... I was trying to test more than 20 jobs :) so wasn't really testing that.

Nice to know it works now though. I almost posted the above feedback without trying to replicate the issue - in the end I couldn't replicate, as it provides the right exception now.

I guess it could have been something else, as the first time it didn't login, it stalled actually. And it was the 2nd and 3rd attempts that gave me the progressively worse errors, until I switched to DEV. So perhaps the backend was rebooted or something in the meantime..

On 21/08/11 10:16 PM, "makkus" reply@reply.github.com wrote:

Not really sure why you got different behaviours, probably some version mixups. Since nobody (I thought) was using the jython thing I didn't really bother to make sure it gets built automatically whenever there are changes...

Gricli is probably a better client to test those things with, since there was more effort in building and deploying it...

Reply to this email directly or view it on GitHub: https://github.com/grisu/gricli/issues/91#issuecomment-1862706

[makkus]

@smas036, could you have a look and think about better language? Happy to help replace that then...

[sina-masoud-ansari]

Sure no problem

[yuriyh]

hello? we either move it to next release or fix it now.

[sina-masoud-ansari]

Yup will do today

[sina-masoud-ansari]

Ok, I followed a similar format to Gricli exceptions, assuming an entry is made in a debug file.

Login failed. Please make sure you have the latest version, available from: http://code.ceres.auckland.ac.nz/stable-downloads If you have the latest version and are still experiencing this problem please contact eresearch-admin@list.auckland.ac.nz with a description of the issue and the debug file located at: [$DEBUG_FILE]

[ndjones]

Should this be more explicit - e.g.:

Login failed as your software client is an older version than is supported by the server you connected to.

Can we get some formatting into these error messages? White space, your friend :)

[sina-masoud-ansari]

How about this, a little friendlier and more informative:

Sorry, could not login. Your client version is no longer supported by the server.

Please download the latest version from:

http://code.ceres.auckland.ac.nz/stable-downloads

If you have the latest version and are still experiencing this problem please contact

eresearch-admin@list.auckland.ac.nz 

with a description of the issue and the debug file located at:

[$DEBUG_FILE]

[ndjones]

I guess we only need to ask for the bug file if it's not on login appliance as we already log everything?

So perhaps we can override the "attach your debug file" part with a setting to suppress it on the login node?

[sina-masoud-ansari]

Yeah good point. There are other errors that pop up occasionally, I'll write something for them too.

[makkus]

Ok, will use Sinas last version without the debug file thing....

[makkus]

Changed error message.

https://github.com/grisu/grisu/commit/dce32587a0da30d5ce5abc79a54eb1978a8958c9