hang in jcman

I just tried to upgrade to jchem 3.1.3. When I run jcman, I get two windows, but neither appears to respond to mouse clicks or key presses. This must be something simple; jcman has always worked for me in the past.

It could be related to this problem. When I run

Code:

jcman t

I get

Code:

Cannot connect: java.lang.ClassNotFoundException: oracle.jdbc.driver.OracleDriver

Oops. My fault. My notes told me to set the CLASSPATH to include the Oracle stuff, but I had ignored it. Setting CLASSPATH gets me past the initial problem.





I still get nonresponsive windows in GUI jcman.





If I run

Code:

jcman t

I see four structure tables. However, any attempt to regenerate them fails. For example,

Code:

jcman r ACEORG.USER_MISC_MOLECULES_V1

gives me

Code:

Regenerating ACEORG.USER_MISC_MOLECULES_V1 ... java.sql.SQLException: ORA-00942: table or view does not exist         at oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:134)         at oracle.jdbc.ttc7.TTIoer.processError(TTIoer.java:289)         at oracle.jdbc.ttc7.Oall7.receive(Oall7.java:573)         at oracle.jdbc.ttc7.TTC7Protocol.doOall7(TTC7Protocol.java:1891)         at oracle.jdbc.ttc7.TTC7Protocol.parseExecuteFetch(TTC7Protocol.java:1093)         at oracle.jdbc.driver.OracleStatement.executeNonQuery(OracleStatement.java:2047)         at oracle.jdbc.driver.OracleStatement.doExecuteOther(OracleStatement.java:1940)         at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:2709)         at oracle.jdbc.driver.OracleStatement.execute(OracleStatement.java:854)         at chemaxon.jchem.db.UpdateHandler.storeUpdate(UpdateHandler.java:1791)         at chemaxon.jchem.db.UpdateHandler.saveUpdateAndGetUpdateCounter(UpdateHandler.java:1780)         at chemaxon.jchem.db.UpdateHandler.close(UpdateHandler.java:1750)         at chemaxon.jchem.db.UpdateHandler.regenerateTable(UpdateHandler.java:2237)         at chemaxon.jchem.Command.regenerateTable(Command.java:768)         at chemaxon.jchem.Command.main(Command.java:423)

More information. When I went back to jchem3.0.15 and ran jcman -r, on some of my relations I got messages like:

Code:

Regenerating ACEORG.USER_MOLECULES1_V1 ... java.sql.SQLException: The structure table contains newer data version that this program version can handle. Please use a later version.

But jchem3.1.3's version of jcman fails on close at the end of regeneration.





I now worry that my attempts to regenerate for 3.1.3 have left the structure tables in an indeterminate state. Should I export the data and reimport it? If so, can you advise the best commands to do so? I seem to be forced to use the command-line interface; I can't get the gui to respond.

Dear Raphael,


This topic is moved into the Structure search and chemical database section.


Please do not post JChem specific questions and database issues into the Structure editing, viewing and file formats section. Post them here (Structure search and chemical database).





Tamas Vertse


Forum moderator

Sure. Thanks for the advice. I was being sloppy.





Raphael

Hi,

Quote:

I just tried to upgrade to jchem 3.1.3. When I run jcman, I get two windows, but neither appears to respond to mouse clicks or key presses. This must be something simple; jcman has always worked for me in the past.

I suppose you get the main window (with the graphical buttons), and the connection dialog where you have to enter connection data, right ?








Please provide us the following information:


- operating system


- java version ("java -version"),


- window manager type (if relevant, e.g. Linux)


- any extra things, like using multiple monitors


- any relevant changes in the environment since the last working state

Quote:

I see four structure tables. However, any attempt to regenerate them fails.

You get this error, because from version 3.1.1 we use log tables for each structure table. These log tables are normally created after you start the GUI - which sadly has problems in your case.

Quote:

When I went back to jchem3.0.15 and ran jcman -r, on some of my relations I got messages like:

Currently there is no mechanism in JChem to downgrade the version.





I hope we can solve this GUI issue soon, so you can use the latest version.





(We are planning to make available this upgrade feature also from the command-line in the near future.)





As a quick workaround it's worth trying to set up and run jcman on a different computer and start up the GUI there, connecting to the same database.


Please see the following thread, where the user had only console access to the server:





http://www.chemaxon.com/forum/ftopic753.html





Best regards,





Szilard

Szilard,





Yes, I get the main window and the connection dialog. Both are unresponsive to mouse clicks and keyboard input.





I tried running jcman from another computer. I get the same lack of response. I also tried running jcman with java 1.4 instead of java 1.5. Again, I get the same lack of response.








operating system: Linux, kernel 2.6.11


java version: 1.4.2_06


window manager type: I usually use fvwm2 with X-windows. I am viewing the windows on a different machine from the one on which I am running jcman; ssh is tunnelling the X connection.


changes in environment: none that I know of, except we have upgraded to Java 1.5 in general.





I am able to export from all the four tables. Perhaps I should just import the data into fresh tables? As an experiment, I created a new table TMP, imported one of my exported files into it, and ran the regeneration, all from the command line. Creating the table took about a minute, surprisingly. Import was pretty fast, regeneration took about a minute and completed without complaint. Is there any reason I should not just do this for all the tables?





köszönöm szíves fáradozását


Raphael

Hi,

Quote:

window manager type: I usually use fvwm2 with X-windows. I am viewing the windows on a different machine from the one on which I am running jcman; ssh is tunnelling the X connection.

I think either the X-windows ssh tunneling or fvwm2 may be a major contributor to the problem.


This can explain why you get the same unresponsiveness on a different machine, if you have also connected remotely in the same way.





- Could you try if you have the same problem with other window managers too (if you have some others installed, e.g. Gnome or KDE) ?





When I have written about connecting from an other machine, I meant that the application (jcman) should run locally on the "new" machine as an other installation.


(so it would require an additional JChem installation).


This instance could connect to the same database server.


This could be a quick temporary solution, which would allow you to go on with the upgrade and still have the administration GUI.


(it might help if there is a different window manager on this machine)





Browsing trough the source code so far I could not find any modifications that should change the GUI behavior at startup in the program, so my questions are the following:


- Were there changes in the window manager / X configuration ?


- Does the JChem 3.0.15 GUI run fine in the same environment where 3.1.3 fails ?





We will also test the GUI next week in similar environments.

Quote:

I am able to export from all the four tables. Perhaps I should just import the data into fresh tables? As an experiment, I created a new table TMP, imported one of my exported files into it, and ran the regeneration, all from the command line. Creating the table took about a minute, surprisingly. Import was pretty fast, regeneration took about a minute and completed without complaint. Is there any reason I should not just do this for all the tables?

It depends on whether you want to use the new or the old version.





If you want to change back to version 3.0.15 it might be simpler to change back the table versions in the property table (e.g. "JChemProperties") to "21" from "27" (if editing table data is not a problem for you).


You should look for property names like

Code:

table.<table_name _with_schema>.version

After this change the regeneration with version 3.0.15 will run fine.

Quote:

Creating the table took about a minute, surprisingly.

In general it should not take more than a couple seconds.


Maybe your database was under heavy load at the moment.


If this slowness is permanent I suggest to contact your database administrator about the issue.

Quote:

köszönöm szíves fáradozását

Wow !


It seems Hungarian will be a world language some day ;)





Kind regards,





Szilard

Szilard,





Thanks for your suggestion to try from another machine. I was able to complete regenerating the tables by using the GUI from another machine, called "bud". (I had to install jchem3.1.3 on bud and find the oracle jdbc path.)





I don't think ssh tunnelling is at fault; although bud is closer to my workstation on the net than the database machine, bud also connected to my workstation via ssh tunnelling. I haven't changed window managers, either, and I would be surprised if fvwm2 were at fault. It's a pretty simple window manager.





One difference I can think of is that on the database machine, my ~/.chemaxon/.jchem file determines the settings on the (unresponsive) connection screen, whereas on bud, I had to fill in all those fields manually. Luckily, the connection screen was responsive.





A second difference is that bud is connected to my workstation via a few switches. The database machine is across campus, and therefore across at least one router. It could be that some firewall is disallowing traffic needed for the connection screen to activate properly. Does the connection screen use strange ports?





Raphael

Hi,

Quote:

One difference I can think of is that on the database machine, my ~/.chemaxon/.jchem file determines the settings on the (unresponsive) connection screen, whereas on bud, I had to fill in all those fields manually.

It should not make any difference whether the fields are filled or not.


The only thing in the .jchem file that can affect GUI behavior is the look & feel setting. Example:

Code:

gui.lookAndFeel.className=javax.swing.plaf.metal.MetalLookAndFeel

It might be interesting to see what happens if you remove the line from the file on the problematic machine (or remove the whole file).

Quote:

Does the connection screen use strange ports?

No.


Ports are used and utilized by the X-Window system, we do not directly deal with them.





It would be also interesting to try if other Java GUI applications have similar problems in your environment (e.g. "msketch" or "mview" ).





Best regards,





Szilard

Szilard,





Removing the single look-and-feel line makes no difference.


Removing the entire .jchem file makes no difference.


msketch works fine and is responsive.





It is most likely not relevant, but my CLASSPATH environment variable is

Code:

.:/usr/local/java/lib:/opt/oracle/product/9.2.0/jdbc/lib/ojdbc14.jar

Raphael

Hi,

Code:

.:/usr/local/java/lib

You did not extract jchem classes from jchem.jar that are accessible from the locations above, did you ?


(it would cause version conflict, which can produce all kind of strange errors)





Szilard

Szilard,





No, the only items in /usr/local/java are

Code:

-rw-r--r--    1 root     root      6772808 Nov 24  2004 tools.jar -rw-r--r--    1 root     root       278052 Sep 15  2004 htmlconverter.jar -rw-r--r--    1 root     root       142507 Sep 15  2004 dt.jar -r--r--r--    1 root     root        18381 Sep 15  2004 ir.idl -r--r--r--    1 root     root          429 Sep 15  2004 orb.idl -rw-r--r--    1 root     root       225884 Sep 15  2004 jconsole.jar -rw-r--r--    1 root     root      1493890 Sep 15  2004 sa-jdi.jar

None of these is apparently a ChemAxon jar file.





Raphael

Hi,

Quote:

None of these is apparently a ChemAxon jar file.

They are not ChemAxon files indeed.





Do you have direct physical access to the problematic machine ?


It would be interesting to see if jcman also fails if started locally there.


(without remote X)





Installing JChem on your workstation and starting it locally (also without remote X) should also provide valuable information.





Best regards,





Szilard

Szilard,





Sorry, I don't have physical access to the problematic machine. I'm not even sure if it has a monitor.





I was able to run the gui of jcman from machine "bud". What sort of information would you like me to derive from that run?





Raphael

Raphael,





The aim of running jcman locally on this machines was to filter out any possible network / remote X problems.





So far we could not reproduce the problem either locally or via remote X connection.


Other users did not report this problem either, so I assume this problem is peculiar to your environment.


(network or X settings, etc.)





If we decide to change the structure of JChem tables again, we will make sure this will be also available from the command-line version.





I will also let you know if we manage to find out more about this issue.





Best regards,





Szilard