Regeneration problem after updating from 3.1.5 to 3.2.2

Hi,





I have upgraded to 3.2.2 and tried to regenerate a structure table created with 3.1.5. The process gets stuck at a molecule. No error message just the molecule count (305) does not change. If I start it again it stops probably at the same molecule although the molecule count is different (1).


Is there a way to locate the molecule? I would delete it and start the process hoping I get lucky and do not bump into a similar problem.





Péter

Dear Peter,





Some structures may require proportionately much more calculation time than others.





How long did you wait for it to continue ?


A minute, or several minutes ?





I there is no progress after several minutes, it may indicate a "deadlock" or "livelock".


Can you check the CPU utilization in this state (closer to 0% or to 100%) ?


BTW is it a multi-processor (or multi-core) machine ?





I guess you are running the JChemManager (jcman) GUI.





Could you run this GUI from a console (command prompt), and when it reaches this state again click on the console and press CTRL + Break ?


This produces a stack trace for the JVM showing thread states, similar to this:

Code:

C:\Documents and Settings\dorant>jcman Full thread dump Java HotSpot(TM) Client VM (1.4.2_12-b03 mixed mode): "Thread-2" prio=4 tid=0x00a1f430 nid=0x2b4 waiting on condition [0x03aaf000..0x0 3aafd68]         at chemaxon.struc.MolAtom.clone(MolAtom.java:3603)         at chemaxon.struc.CGraph.clonecopy(CGraph.java:913)         at chemaxon.struc.MoleculeGraph.clonecopy(MoleculeGraph.java:1238)         at [...]

Could you send us the full trace please ? It can provide us with important information in case of either a deadlock or livelock.

Quote:

Is there a way to locate the molecule?

Since it seems to stop at different locations, I cannot think of an easy way of locating it at the moment.





However I'm hopeful that the requested information will help us tracking down the problem.





Best regards,





Szilard

Hi Szilárd,





I was running on a 2 cpu pc with linux. I tried twice. First it was doing nothing about 5 hours, second time the whole night (~14 hours).





Since I could not make the dump on linux I have repetead the experiment on a single cpu windows pc. The resulting dump is in the attachment.





Take care, Péter

Hi Peter,





From the dump it seems this is not structure dependent.


In fact it seems it's something about the JDBC driver.





We are still investigating this, but my quick tip would be to try an other JDBC driver.


I recommend the latest ojdbc14.jar from Oracle.


(Oracle JDBC drivers are usually backward compatible)





Cheers,





Szilard

PS:





Please also be sure there is only one JDBC driver in your CLASSPATH.





Szilard

Hi Szilárd,





I repeated the experiment with ojdbc14.jar. It is the same. I have enclosed the dump.





Péter

Hi,





The second thread dump looks exactly the same.


(as long as I could open it, now I cannot, this may be a forum bug)

Code:

"Thread-0" prio=6 tid=0x48fc67f0 nid=0x648 runnable [0x4987f000..0x4987f9e4]         at java.net.SocketInputStream.socketRead0(Native Method)         at java.net.SocketInputStream.read(SocketInputStream.java:129)         at oracle.net.ns.Packet.receive(Unknown Source)         at oracle.net.ns.DataPacket.receive(Unknown Source)         at oracle.net.ns.NetInputStream.getNextPacket(Unknown Source)         at oracle.net.ns.NetInputStream.read(Unknown Source)         at oracle.net.ns.NetInputStream.read(Unknown Source)         at oracle.net.ns.NetInputStream.read(Unknown Source)         at oracle.jdbc.ttc7.MAREngine.unmarshalUB1(MAREngine.java:930)         at oracle.jdbc.ttc7.MAREngine.unmarshalSB1(MAREngine.java:894)         at oracle.jdbc.ttc7.Oall7.receive(Oall7.java:383)         at oracle.jdbc.ttc7.TTC7Protocol.doOall7(TTC7Protocol.java:1973)         at oracle.jdbc.ttc7.TTC7Protocol.parseExecuteFetch(TTC7Protocol.java:111 9)

These lines are of particular interest:

Code:

at java.net.SocketInputStream.socketRead0(Native Method)         at java.net.SocketInputStream.read(SocketInputStream.java:129)

This seems to indicate TCP/IP communication problems between Oracle and the program.


I'm not sure if it's due to network / firewall settings or the problem lies inside Oracle, but I think it's worth to start the regeneration locally on the Oracle server, if your current attempts were from a remote machine.





Unfortunately this means installing Java and JChem on that machine too, but this is my current best tip.





If you only have console access to this server (telnet, ssh), you can also perform the necessary updates via command-line with any of the following commands:





Regeneration of a table:

Code:

jcman r <table_name>

Regeneration of all tables:

Code:

jcman r

Performing all necessary updates:

Code:

jcman u

Szilard

Unfortunately, running it on the oracle server is not option. It was working fine with two other databases, although those have fewer structures. For the first 305 structures it worked fine first time. Second time, if I guess right, it did not process these structures again so it got stuck at the first molecule.





Péter

Quote:

Second time, if I guess right, it did not process these structures again so it got stuck at the first molecule.

The regeneration process goes trough all structures every time, so there should be no difference.


Could the table be locked by an other process during this period ?


(Any live applications using this table at the time of the regeneration ?)





Szilard

You are right. TOAD was open. After closing it the regeneration seems to go fine.





Thanks, Péter