No more data to read from socket error JChem Cartridge

Hi





This is Jchem Cartridge 3.1.1, Java 1.5.0_04, tomcat 4.1.31 on a Linux machine running Red Hat Enterprise Linux ES release 3 (Taroon Update 5), Kernel 2.4.21-32.0.1.ELsmp on an i686. The Oracle version is 9.2.0.6





I am having a problem where after jchem has been running for a while, suddenly it can no longer be queried. I am seeing the errors





Exception: No more data to read from socket ORA-06512: at "JCHEM.JCHEM_CORE_PKG", line 0 ORA-06512: at "JCHEM.JC_IDXTYPE_IM", line 323 ORA-06512: at line 1 at





and then





Exception: null ORA-06512: at "JCHEM.JCHEM_CORE_PKG", line 0 ORA-06512: at "JCHEM.JC_IDXTYPE_IM", line 323 ORA-06512: at line 1 at





I can see these too in catalina.out (which I have attached).





Jchem is then not available for querying until I restart tomcat, although the indexes themselves are still available (for example, inserts into the tables continue to work, which is not the case when tomcat is stopped altogether).





I noticed that in catalina.out, there seems to be a lot of tables being dropped from the structure cache. But I am thinking that even if there is not enough memory to hold all indexed tables in the cache, jchem should not just crash like this.





I am looking at increasing the memory size available to the cache, and I have a couple of questions about this, which I will post in another thread.





Do you have any suggestions about this problem?





Thanks


Mark

I thought I had attached the file, but the extension out is not allowed, apparently. Here it is

Mark,





Do you use the newest Oracle JDBC driver with Tomcat? With Oracle 9i, I often have the same error message if I use the driver bundled with 9i, but not with the 10g driver.








Peter

Peter


When I run the test.sh script, it says





Major JDBC version in Tomcat: 10


Minor JDBC version in Tomcat: 2





I think this means I am running the latest version of the JDBC driver, and not the older one.





Mark

Mark,





Was JChem Cartridge at the time the error occurred under heavy concurrent use?





As far as I can tell this problem might come from two things:





A) An Oracle client-server protocol error -- this what the error directly indicates (and that is beyond JChem Cartridge's control);





B) A low memory or out of memory situation, where the error messages seen do not necessarily indicate the true problem.





I suggest to wait and see what happens after you tuned JChem Streams so that it has a comfortably large amount of memory. (See my mail dated Thu Sep 22, 2005 4:34 pm under http://www.chemaxon.com/forum/ftopic905.html.)





Peter

Peter


The database was not under heavy concurrent use of JChem at the time. (I can tell by the search logs I keep). However, I don't know what was happening for the database as a whole.





The two times I have noticed this, it seems to have been the first search of the day which causes it. The database sometimes goes down overnight for backups and such.





I have increased the tomcat memory so the cache swapping is no longer happening. I will tell you if this problem recurs.





Mark

Mark,

Code:

the first search of the day which causes it

This situation is very similar to what I had using the 9i JDBC drivers with my test client (this is a client-side application which connects to Oracle and executes JChem Cartridge functions): the first or second queries sporadically failed with the same error message. I tried to work around the problem by creating a new connection, but it did not help: once the JDBC driver started to throw "No more data read from socket" errors it continued to do so until I restarted the program. Replacing the JDBC with a 10g version completely solved the problem, but I see that you are already using the latest version.





Interestingly, this problem never occurred with my JChem Cartridge installation (only with my test client) even though I used 9i JDBC driver until recently.





Peter

Mark and Peter,





I'm not sure if this makes you feel better or worse, but I've been having this exact problem sporadically for a few months now. I also have noticed the Tomcat cache size to be to low (producing the WARNINGS in the Catalina logs), but I didn't think this was the culprit. I have tried to change the ojdbc14.jar file to a few different 9i versions (a few months back), but to no avail. I will try to upgrade to the 10g version and let you know the outcome.





Thanks Mark for starting this thread.

We think we have solved it.


Basically, when I looked at the logs, turned out that it only happened on Monday and Thursday mornings, and it did not seem a co-incidence that Oracle is shutdown for backup on Sun and Wed nights. I think the problem was that Oracle was shut down, but tomcat was not.


So, I changed the backup routine as follows.





Shutdown Oracle


Shutdown tomcat


/home/oracle/tomcat/jakarta-tomcat-4.1.31/bin/shutdown.sh


back up and stuff as normal


Startup tomcat


/home/oracle/tomcat/jakarta-tomcat-4.1.31/bin/startup.sh


Startup Oracle





When tested manually, this works, but I am pretty sure that the issue will be solved by changing the script.





I also took the opportunity, since tomcat will be restarted, to repopulate the tomcat cache by running queries on all jchem indexed tables so that when the users arrive in the morning, their first searches on each table are not unduly slow.





By the way, we think this is the same problem and solution that my colleague pcochrane was having which he posted about in the thread





"JChem Cartridge issue"





I will let you know if I have any further problems.





Thanks


Mark

Quote:

We think we have solved it. Basically, when I looked at the logs, turned out that it only happened on Monday and Thursday mornings, and it did not seem a co-incidence that Oracle is shutdown for backup on Sun and Wed nights. I think the problem was that Oracle was shut down, but tomcat was not.

Great!!! And how simple! This is how the connection gets corrupted. (The reason why I did not think of it is probably because I practically never shutdown the database but I quite often restart Tomcat (or reload the JChem Streams application context).)

Quote:

I also took the opportunity, since tomcat will be restarted, to repopulate the tomcat cache by running queries on all jchem indexed tables so that when the users arrive in the morning, their first searches on each table are not unduly slow.

Very clever indeed!





Peter