JChem licence code not recognised

Dear Support team

One of our customers is having difficulty with JChem. They are using JChem 5.2.0.6 on UNIX (Red
Hat Enterprise Linux Server release 5.6 (Tikanga) 64 bit).

They reported that they see the following error when trying to use the JChem cartridge:

ORA-29902: error in executing ODCIIndexStart() routine ORA-29532: Java call terminated by uncaught Java exception: java.rmi.ServerException: RemoteException occurred in server thread; nested exception is: java.rmi.RemoteException: No valid license for JChem Cartridge

 

I have checked and can confirm:

1) The license is included in the correct place (the licenses directory)

2) The license is valid (I have tested this on a windows machien in our own tst systems and it does not show the same problem)

3) The correct license.cxl file is the only file in the licnses directory

They were previously using an old (now expired) license file, and have recently updated to the new file, and so I wondered if the JChem restart had not been performed following file replacement (so the JChem cartridge would still attempt to use cached informaiton prehaps?).  I therefore asked the user to stop and restart their Jchem server, but when they try to stop they get the following output:

[jchem@hendrix
cartridge]$ ./server.sh stop

+
/usr/java/jdk1.6.0_20/bin/java
-Djava.util.logging.config.class=chemaxon.jchem.cartridge.util.LoggingConfigurator
-Dchemaxon.jchem.cartridge.config.file=conf/jcart.properties
-Djava.awt.headless=true -classpath ./../lib/jchem.jar
-XX:-OmitStackTraceInFastThrow chemaxon.jchem.cartridge.server.Bootstrapper
stop

INFO: Server control
process started

INFO: Using
classpath: /export/home01/jchem/ChemAxon/JChem/lib/jchem.jar:

INFO: Server process
stop-ed.

INFO: Connecting to
hendrix.am.lilly.com:1099

java.rmi.ServerException:
RemoteException occurred in server thread; nested exception is:

     
  java.rmi.RemoteException: Could not initialize class
java.net.NetworkInterface

     
  at sun.rmi.server.UnicastServerRef.dispatch(Unknown Source)

     
  at sun.rmi.transport.Transport$1.run(Unknown Source)

     
  at java.security.AccessController.doPrivileged(Native Method)

     
  at sun.rmi.transport.Transport.serviceCall(Unknown Source)

     
  at sun.rmi.transport.tcp.TCPTransport.handleMessages(Unknown Source)

     
  at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(Unknown
Source)

     
  at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(Unknown
Source)

     
  at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown
Source)

     
  at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)

     
  at java.lang.Thread.run(Unknown Source)

     
  at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:273)

     
  at
sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:251)

     
  at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:160)

     
  at chemaxon.jchem.cartridge.rmi.impl.AdminImpl_Stub.execute(Unknown Source)

     
  at chemaxon.jchem.cartridge.rmi.impl.AdminImpl.main(AdminImpl.java:356)

Caused by:
java.rmi.RemoteException: Could not initialize class java.net.NetworkInterface

     
  at
chemaxon.jchem.cartridge.rmi.impl.RmiImplUtil.handleError(RmiImplUtil.java:50)

     
  at
chemaxon.jchem.cartridge.rmi.impl.AdminImpl.execute(AdminImpl.java:127)

     
  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 sun.rmi.server.UnicastServerRef.dispatch(Unknown Source)

     
  at sun.rmi.transport.Transport$1.run(Unknown Source)

     
  at java.security.AccessController.doPrivileged(Native Method)

     
  at sun.rmi.transport.Transport.serviceCall(Unknown Source)

     
  at sun.rmi.transport.tcp.TCPTransport.handleMessages(Unknown Source)

     
  at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(Unknown
Source)

     
  at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(Unknown
Source)

     
  at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown
Source)

     
  at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)

     
  at java.lang.Thread.run(Unknown Source)

SEVERE: Server
process exited with code: 1

 

Does this indicate that the server process has not correctly stopped?

Do you have any thoughts as to why the correct license file is not recognised by the system?

 

Many thanks for any assistance you can offer.

 

Karen

Dear Karen,

I'd say that stopping the JCC server failed. I am not entirely sure why. Do they use an Oracle Java? What is the output of the following command:

$JAVA_HOME/bin/java -version

?

To see if there is still any process listening at 1099, I suggest to execute

netstat -untap | grep 1099

. If you find JCC server is still up, just kill it.

JCC is refreshing the licenses on server.sh reload based on the new license file, but this might not always work, so the safest is to stop and restart the server.

Peter

Dear Peter

 

Thank you for your email. The user who is having the problem is the same user that experienced the issues reported here:

https://www.chemaxon.com/forum/viewpost37379.html&highlight=hendrix#37379

I don't think it is the same issue but my understanding is limited so it would be great if you can review and see if there is any similarity.

 

The java home was previously reported as :

hendrix$ $JAVA_HOME/bin/java -version
java version "1.5.0"
Java(TM) 2 Runtime Environment, Standard Edition (build
pxi32devifx-20071025 (SR6b))
IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 Linux x86-32
j9vmxi3223-20071005 (JIT enabled)
J9VM - 20071004_14218_lHdSMR
JIT  - 20070820_1846ifx1_r8
GC   - 200708_10)
JCL  - 20071025

I don't think this will have changed as they are using the same machine in this latest testing.

 

I will ask them to try the following command:

netstat -untap | grep 1099

and to kill any active sessions before they try to stop and restart the server.

The user in in America so i won't have any further update until this afternoon but I will keeo you up to date.

Many thanks

Karen

Dear Karen

The java home was previously reported as

I think they replaced it with an Oracle Java as we suggested. That is presumably what that whole issue back then was about. (But I can't be sure.)

Peter

Dear Peter

 

I'm pleaed to report that after the user killed the JChem sessions that remained, and then restarted the server with the correct licence file, everything works correctly.

 

Would you like me to verify the java home (would this help to understand why the service was not stopped with server.sh stop)?

If this will not give us any further clues then I will just ask them to ensure that all services are stopped using kill session as well as server.sh stop in the future.

 

many thanks

 

Karen

Dear Karen,

This is certainly not the way stopping is expected to work (and I've never seen stopping fail with this error), but not having a clear idea about the potential source of the problem, I think there is little point to pursue this issue now.

Best regards,

Peter

Thank you Peter

 

I am happy to close this issue. I have asked the uers to make a note in their internal documentation to check that there are no sessions still running when stopping the service.

 

Many thanks for all your assistance

 

Karen