New Install - socket write error

JChem 5.2.06 Cartridge (port 1199) on Oracle 10g (Windows)

We are attempting to do a substructure and are getting the following error. 

- Thanks for your help

Feb 4, 2010 4:09:01 PM chemaxon.jchem.cartridge.rmi.impl.RmiImplUtil handleError
SEVERE: Io exception: Software caused connection abort: socket write error
java.sql.SQLException: Io exception: Software caused connection abort: socket write error
        at oracle.jdbc.driver.SQLStateMapping.newSQLException(SQLStateMapping.java:74)
        at oracle.jdbc.driver.DatabaseError.newSQLException(DatabaseError.java:131)
        at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:197)
        at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:261)
        at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:566)
        at oracle.jdbc.driver.T4CConnection.doRollback(T4CConnection.java:634)
        at oracle.jdbc.driver.PhysicalConnection.rollback(PhysicalConnection.java:3470)
        at oracle.jdbc.OracleConnectionWrapper.rollback(OracleConnectionWrapper.java:128)    
    at chemaxon.jchem.cartridge.rmi.impl.MiscellaniousImpl.idxCompatibility(MiscellaniousImpl.java:149)

Please, could you specify which Oracle patch level you use?

Is JChem Server installed on the same machine as the Oracle Server?

Please, could you post the output of the

select jchem_core_pkg.getenvironment from dual

command?

Thank you,

Peter

Hi Peter,

1) Patch Level

Oracle Database 10g Release 10.2.0.1.0 - Production PL/SQL Release 10.2.0.1.0 - Production
CORE    10.2.0.1.0      Production
TNS for 32-bit Windows: Version 10.2.0.1.0 - Production NLSRTL Version 10.2.0.1.0 - Production

2) Yes, the they are on the same machine.

3) Output from SQL:

"Oracle environment:
Oracle Database 10g Release 10.2.0.1.0 - Production
PL/SQL Release 10.2.0.1.0 - Production
CORE    10.2.0.1.0    Production
TNS for 32-bit Windows: Version 10.2.0.1.0 - Production
NLSRTL Version 10.2.0.1.0 - Production

JChem Server environment:
Java VM vendor: Sun Microsystems Inc.
Java version: 1.6.0_17
Java VM version: 14.3-b01
JChem version: 5.2.6
JChem Index version: 5020400
JDBC driver version: 11.1.0.7.0-Production
"

Thanks

Paul

Your Oracle patch level doesn't conform to the software requirements. At least 10.2.0.3 is required. Was the same error you found in the JChem Server's log file thrown back to the database client? Was it not a different one? Based on the error message you reported (Software caused connection abort), I'd speculate that the database session has crashed.

At this point, the best advice I can give is to upgrade Oracle to 10.2.0.4 which is the most stable 10gR2 version.

Thanks

Peter

Our DBA upgrade us to10.2.0.4 Oracle 10g. 

We had changed the port number in jcart.properties to 1199 because 1099 was used by another program.  We are getting the following error which is showing 1099.  Do I need to change the port number somewhere else too?



SQL Error: ORA-29902: error in executing ODCIIndexStart() routine
ORA-29532: Java call terminated by uncaught Java exception: java.lang.Exception: Problem connecting to JChemServer: rmi://localhost:1099: Connection refused
ORA-06512: at "JCHEMCART.JCHEM_CORE_PKG", line 49
ORA-06512: at "JCHEMCART.JC_IDXTYPE_IM", line 153
29902. 00000 -  "error in executing ODCIIndexStart() routine"

Thanks, Paul

In the table jc_idx_property  in the schema where you installed JChem Cartridge, you have to change the value of the rmi.server.1 property from localhost:1099 to localhost:1199.

Peter

The update to Oracle 10.2.0.4 and updating the port in jc_idx_property fixed our problems.  Thanks for your help,

Paul

Thank you, Paul, for the feedback.

Peter

Peter,

We ran into one new problem when using the BLOB search functions (e.g. jc_containsb). We need to use the BLOB version because we'll be searching with molfiles.  SQL:

  select * from jchemcart.structure where jc_containsb( cd_structure
                  ,<BLOB molfile>) = 1

Below is the error.  I saw some discussion on this bug elsewhere on this forum suggesting that this might be fixed in 5.3.  Is that related to the error we're seeing or is that a different issue?   

Error report:
SQL Error: 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: Premature end of cfile in CTAB
ORA-06512: at "JCHEMCART.JCHEM_BLOB_PKG", line 74
ORA-06512: at "JCHEMCART.JC_IDXTYPE_IM", line 282
29902. 00000 -  "error in executing ODCIIndexStart() routine"
*Cause:    The execution of ODCIIndexStart routine caused an error.
*Action:   Examine the error messages produced by the indextype code and
           take appropriate action.

Paul,



Please, could you post the exact SQL statement which resulted in this error?



Also, would it be possible to post the relevant Java stack trace from the jcart1.log file in the jchem/cartridge/logs directory?



Thanks



Peter

Peter,

Sorry for the confusion.  This was a problem on our end.  The function we were using to convert from CLOB to BLOB was not doing the conversion correctly some of the time.  Our DBA updated that and we're fine. 

Thanks again,

Paul

No problem, Paul. Thank you for the feedback.

Peter

The following function has been useful when searching with large molfiles as has been described on this forum.

  select * from jchemcart.structure where jc_containsb( cd_structure
                  ,<BLOB molfile>) = 1

We are working with a client who has a structure table with all of the other internal fields "CD_" that we would expect but does not have the cd_structure.Is there a reason why that field would not exist?  

 

 

 

We are working with a client who has a structure table with all of the other internal fields "CD_" that we would expect but does not have the cd_structure.Is there a reason why that field would not exist?

The cd_structure column in JChem structure tables is used to store the structure in its original form.

Most JChem Cartridge users use regular structure tables instead of JChem structure tables and create a jc_idxtype index on the column of the regular table containing the structures. (This column can have any names at the user's discretion in a table which can have any additional columns dictated by the user's requirements.) Indexing the structure column of a regular table will result in the creation of an index table having almost the same columns as a JChem structure table -- except the cd_structure column which will be replaced by a column called rid holding the ROWIDs of the corresponding rows of the table with the the original structures.

My first guess would be that you have mistaken the index table associated with a regular structure table for a JChem structure table.

Peter

What you've described sounds like what we're seeing.  If they are using 'regular structure tables', I'm assuming that means that they may not have a BLOB field that is the equivalent to the 'JChem structure table' CD_STRUCTURE field?  If that's the case how would you deal with search large molfiles if there is no BLOB field?  Or is the only option to convert the large molfile to a different format that is smaller?

You can pass the second parameter (in its original form) to jc_compare as a (temporary) CLOB, for example. (You may need then to cast the first parameter to_clob(), if the structure column is of type VARCHAR2...)

Peter

Peter,

My concern with using to_clob to cast the first param is performance.  Wouldn't something like the following do a table scan because every record would need to be converted first?  Or does the index handle this?

... where jc_compare(to_clob(smilesField), largeMolfile, 't:p')

Paul,

As long as the jc_compare operator is executed in domain index scan mode, the to_clob cast is only an indication for the parser which operator binding to use. No actual conversion from VARCHAR to CLOB is performed -- and yes, the JChem-index operator's implementation will handle it.

Peter