2 structures not indexed, native library not initialized

Hi,

We have an environment running JChem cartridge 5.9.1 and Oracle 10.2.0.5

When the process is trying to create indexes we get the following:

[main/10]: 2013-10-29 13:23:47.194 chemaxon.jchem.cartridge.rmi.impl.AdminImpl setStructureCacheId
INFO: Cache id set to JCC1
[main/10]: 2013-10-29 13:23:48.150 chemaxon.jchem.cartridge.rmi.impl.AdminImpl startServer
INFO: Listening at 1099
[RMI TCP Connection(1)-127.0.0.1/11]: 2013-10-29 13:24:28.749 chemaxon.jchem.cartridge.servlets.JCartConnectionManager createJCartDataSource
INFO: Using chemaxon.jchem.cartridge.util.cpool.Oracle10gDataSource
[RMI TCP Connection(1)-127.0.0.1/11]: 2013-10-29 13:24:30.081 chemaxon.jchem.cartridge.util.Environment identifyJdbcDriverVersion
INFO: JDBC driver version: 11.1.0.7.0-Production
[pool-1-thread-7/12]: 2013-10-29 14:23:33.244 chemaxon.jchem.cartridge.servlets.indexing.structhandlers.CalculateInsertHandler handleException
SEVERE: Error while processing ROWID=AAB1XhAAKAACogfAAC: chemaxon.formats.MolFormatException: Native library is not initialized., InChI=1S/C9H20O/c1-7(2)5-9(10)6-8(3)4/h7-10H,5-6H2,1-4H3
[pool-1-thread-9/13]: 2013-10-29 14:23:35.571 chemaxon.jchem.cartridge.servlets.indexing.structhandlers.CalculateInsertHandler handleException
SEVERE: Error while processing ROWID=AAB1XhAAKAACpA6AAB: chemaxon.formats.MolFormatException: Native library is not initialized., InChI=1S/C10H20O2/c1-2-3-4-5-6-7-10(12)8-9-11/h11H,2-9H2,1H3
[RMI TCP Connection(3)-127.0.0.1/14]: 2013-10-29 14:23:37.167 chemaxon.jchem.cartridge.rmi.impl.RmiExceptionHandler handleError
SEVERE: 2 structure(s) could not be indexed. Please, check the JChem Server logs.
java.lang.Exception: 2 structure(s) could not be indexed. Please, check the JChem Server logs.
    at chemaxon.jchem.cartridge.servlets.indexing.operations.ConcurrentIndexBuilder.handleDeferredErrors(ConcurrentIndexBuilder.java:141)
    at chemaxon.jchem.cartridge.servlets.indexing.operations.ConcurrentIndexBuilder.build(ConcurrentIndexBuilder.java:119)
    at chemaxon.jchem.cartridge.servlets.indexing.operations.JCartIndexCreate.buildIndexConcurrently(JCartIndexCreate.java:389)
    at chemaxon.jchem.cartridge.servlets.indexing.operations.JCartIndexCreate.buildIndex(JCartIndexCreate.java:344)
    at chemaxon.jchem.cartridge.servlets.indexing.operations.JCartIndexCreate.executePayLoad(JCartIndexCreate.java:78)
    at chemaxon.jchem.cartridge.servlets.indexing.operations.JCartIndexBase.executeSynch(JCartIndexBase.java:50)
    at chemaxon.jchem.cartridge.servlets.indexing.operations.JCartIndexBaseAsync.executeSynch(JCartIndexBaseAsync.java:14)
    at chemaxon.jchem.cartridge.servlets.indexing.operations.JCartIndexBaseAsync.executeAsynch(JCartIndexBaseAsync.java:93)
    at chemaxon.jchem.cartridge.rmi.impl.IndexImpl.createIndex(IndexImpl.java:57)
    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)
    at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:305)
    at sun.rmi.transport.Transport$1.run(Transport.java:159)
    at java.security.AccessController.doPrivileged(Native Method)
    at sun.rmi.transport.Transport.serviceCall(Transport.java:155)
    at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:535)
    at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:790)
    at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:649)
    at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
    at java.lang.Thread.run(Thread.java:619)

 

Could you please advise on this error?

 

Thanks in advance,

Jade

Hi Jade,

Please, could you post the output of the following SQL command:

select jchem_core_pkg.getenvironment from dual;

Thanks,

Peter

Hi Peter,

This is happening on both a production and test environment for this particular member, so the output for both is below.

We have successfully indexed these structures on other set ups in house and other members have been successful too.

PROD:

 

GETENVIRONMENT

"Oracle environment:

Oracle Database 10g Enterprise Edition
Release 10.2.0.5.0 - 64bi

PL/SQL Release 10.2.0.5.0 - Production

CORE    
10.2.0.5.0           
Production

TNS for Solaris: Version 10.2.0.5.0 -
Production

NLSRTL Version 10.2.0.5.0 - Production

 

JChem owner: JCHEM

 

JChem Server environment:

Java VM vendor: Sun Microsystems Inc.

Java version: 1.6.0_20

Java VM version: 16.3-b01

JChem version: 5.9.1

JChem Index version: 5080100

JDBC driver version:
11.1.0.7.0-Production

"

 

TEST:

 

GETENVIRONMENT

"Oracle environment:

Oracle Database 10g Enterprise Edition
Release 10.2.0.5.0 - 64bi

PL/SQL Release 10.2.0.5.0 - Production

CORE    
10.2.0.5.0           
Production

TNS for Solaris: Version 10.2.0.5.0 -
Production

NLSRTL Version 10.2.0.5.0 - Production

 

JChem owner: JCHEM

 

JChem Server environment:

Java VM vendor: Sun Microsystems Inc.

Java version: 1.6.0_20

Java VM version: 16.3-b01

JChem version: 5.9.1

JChem Index version: 5080100

JDBC driver version:
11.1.0.7.0-Production

"

 

Thanks,

Jade

Hi Jade,

Thank you for this information.

I assume the JChem Cartridge server is running on the same system as the Oracle database: Solaris. If so, the source of the problem is that the InChi representation is not supported on Solaris. (http://www.chemaxon.com/marvin/help/formats/inchi-doc.html) The work-around would be install and run the JChem Cartridge server on a platform where InChi is supported.

Peter

Thanks very much for this, I will pass the information on.

 

Jade

Hi Peter,

One final question - do you know if/when the InChi representation will be supported on Solaris?

Thanks,

Jade

"when the InChi representation will be supported on Solaris?"

Currently this task has low priority as we did not get much request for this from our users. So as it seems now the most appropriate answer is never. This may change if it will be requested by many users (I hardly believe in this) or some user requests this support as consultancy. 

Maybe this answer is not a pleasing one but it is honest.

Ok no problem, thanks for the reply!

Jade