Jchem Server Aborts

We are trying compare structures before and after applying standardization but when we run in bulk by database script , the Jchem server terminates and raises the attached log.





The script does not fail straight away but after few minutes it fails. Our script logs the failure and when we try to run the same compound with the same standardization method manually it works.





Any idea??








Our environment is below





JCHEM_CORE_PKG.GETENVIRONMENT()


--------------------------------------------------------------------------------


Oracle environment:


Oracle Database 10g Release 10.2.0.3.0 - 64bit Production


PL/SQL Release 10.2.0.3.0 - Production


CORE 10.2.0.3.0 Production


TNS for Linux: Version 10.2.0.3.0 - Production


NLSRTL Version 10.2.0.3.0 - Production





JChem Server environment:


Java VM vendor: Sun Microsystems Inc.


Java VM version: 10.0-b22


JChem version: 5.0.2.1





JCHEM_CORE_PKG.GETENVIRONMENT()


--------------------------------------------------------------------------------


JDBC driver version: 10.2.0.3.0

We've seen similar stability problems with Java 6 (1.6) on a similar platform with long running (command-line) batch applications. Replacing Java 6 with a recent version of Java 5 solved these stability problems. I suggest trying to use a recent version Java 5 instead of Java 6 .

It worked fine when we let the script run overnight. It was run in 20 threads as dbms jobs in oracle but when we tried to run during the day the jchem server was terminating.





We have two jchem server running on the same machine one for live and other for performance database. Both the jchem server is occupying 700 MB memory and the server has 32 GB of RAM (so lots of memory)





Could you suggest or point me to the documentation where we can increase JDBC connections for the RMI call.

Quote:

when we tried to run during the day the jchem server was terminating.

Did the server terminate with the same error symptoms as before -- generating an hs_err_pidXXX.txt file?

Quote:

Could you suggest or point me to the documentation where we can increase JDBC connections for the RMI call.

JChem Server uses Oracle JDBC connection pools which are configured to create as many connections as needed (if this is what you mean). Certain aspects of the connection pools can be changed/configured but JChem Server currently provides no interface to configure them.





Thanks


Peter

Quote:

JChem Server currently provides no interface to configure them

It is still possible to customize connection creation behavior through the following back-door (and, of course, I can help in this if needed):





1. Implement the chemaxon.jchem.cartridge.util.cpool.JCartDataSource interface:

Code:

public interface JCartDataSource {     public Connection getConnection() throws SQLException;     public void close() throws Exception; }

The constructor of the implementation should have the following signature:

Code:

(String url, String login, String password)

2. Set the value of the connection.cached.pool.impl property in the jcart.properties file to the class name of your implementation.





By default, JChem Cartridge uses this implementation:

Code:

public class Ora9iDataSource implements JCartDataSource {     private OracleConnectionCacheImpl cache;     public Ora9iDataSource(String url, String login, String password)             throws SQLException {         OracleConnectionPoolDataSource ocpds =                 new OracleConnectionPoolDataSource();         ocpds.setDriverType("thin");         ocpds.setURL(url);         ocpds.setUser(login);         ocpds.setPassword(password);         cache = new OracleConnectionCacheImpl(ocpds);     }     public void close() throws SQLException {         cache.close();     }     public Connection getConnection() throws SQLException {         return cache.getConnection();     } }

Thanks


Peter

Yes the Jchem Server terminated with same error ie generating an hs_err_pidXXX.txt file when we run during the day.





Thanks for your earlier reply and much appreciated....





Yes I was taking about JDBC connection how we can increase the default number of connections in the JDBC connection pool. I think I can try your suggestion.





When I run 20 dbms jobs it looks like there is only one JDBC connection that serves the job request and when I look into the dbms jobs they seem to wait, only one is progressing. Is there any quick way to increase the JDBC connection ie changing #jcSearchThreadsPerCall=? in jacrt.properties





Could please also give me some documentation of the following parameters.





# indexingThreadsPerCall=?


# jcSearchThreadsPerCall=?


# jcReactThreadsPerCall=?


## connection.cached.pool.impl=chx.jchem.cartridge.util.cpools.CommonsDataSource


### url=jdbc\:oracle\:thin\:@localhost\:1521\:mydb


### driver=oracle.jdbc.driver.OracleDriver

Quote:

Yes the Jchem Server terminated with same error ie generating an hs_err_pidXXX.txt file when we run during the day.

Is it with Java 5 this time round?

Quote:

When I run 20 dbms jobs it looks like there is only one JDBC connection that serves the job request and when I look into the dbms jobs they seem to wait, only one is progressing. Is there any quick way to increase the JDBC connection ie changing #jcSearchThreadsPerCall=? in jacrt.properties

When I start simultaneous structure searches (a) in multiple, already existing (primary) database sessions (b) using the same user and (c) a freshly started JChem Server, I see in $ORACLE_HOME/network/log/listener.log a new connection appearing instantaneously after starting the search: starting a search triggers a new connection, starting a second search triggers a second connection to be opened, starting a third search triggers a third new connection...so each concurrent primary database session appears to get its own secondary JDBC session as soon as needed. Based on, this I would say (JDBC) connection creation shouldn't be the cause for throttling simultaneous searches.





One possible reason for the apparent serialization of searches might be that if those 20 jobs execute searches using multiple different structure indexes, the data for some of the structure indexes may not fit into the memory allocated to JChem Server based on the JAVA_HEAP_SIZE environment variable. As the searches that are executed against non-cached indexes are much slower than searches executed against cached indexes (and this relative difference in speed is only re-enforced by the fact that non-cached searches have to compete for CPU against cached searches), the former may appear to be idle. (Unfortunately, current JChem Cartridge versions don't report which index tables could not cached -- this will be fixed in the next JChem version.) Is this scenario possible in your environment? What is the value of your JAVA_HEAP_SIZE environment variable and what is the total number of structures (including all jc_idxtype-indexed structure columns) in which you search simultaneously (including concurrent DB jobs and user searches)?





A side note: searches are, by default, heavily parallelized by JChem Cartrdige, so that executing searches in parallel (especially if they are longer searches, ie. normally executing over about 10 seconds) will only marginally improve throughput -- depending on what kind of other operations they are interspersed with in your DB jobs.

Quote:

Could please also give me some documentation of the following parameters. # indexingThreadsPerCall=? # jcSearchThreadsPerCall=? # jcReactThreadsPerCall=? ## connection.cached.pool.impl=chx.jchem.cartridge.util.cpools.CommonsDataSource ### url=jdbc\:oracle\:thin\:@localhost\:1521\:mydb ### driver=oracle.jdbc.driver.OracleDriver

indexingThreadsPerCall: one index operation will be executed in this many concurrent threads. The default is the number of processing CPU cores.


jcSearchThreadsPerCall: one search operation will be executed in this many concurrent threads. The default is the number of processing CPU cores. (This parameter doesn't currently have an effect. This will be fixed in the next JChem version.)


jcReactThreadsPerCall: one jc_react operation will be executed in this many concurrent threads. The default is the number of processing CPU cores.


url and driver are basically a remnants from JChem 3.x (and, in certain way, also a look into the future when JChem Server will be used with databases other than Oracle on the other for non-cartridge applications). They are no more relevant for JChem Cartridge. With JChem Cartridge the driver is always the same (oracle.jdbc.driver.OracleDriver) while the variable portions of the url are "externalized" into the oracle.server.host, oracle.server.port and oracle.server.instance properties.





Thanks


Peter