No.

Post #153,928 by mmoffitt 5/5/04 6:18:33 PM Reply	No. Here's a piece. # # HotSpot Virtual Machine Error : 11 # Error ID : 4F530E43505002EF # Please report this error at # [link\|http://java.sun.com/cgi-bin/bugreport.cgi\|http://java.sun.com/...bin/bugreport.cgi] # # Java VM: Java HotSpot(TM) Client VM (1.4.2_03-b02 mixed mode) # # An error report file has been saved as hs_err_pid12941.log. # Please refer to the file for further information. There was a very long thread - it looks like Sun may have removed it - I quit counting when the number of "Yeah, Me too" posts hit 46 - but here's a part of one I really liked: In one comical, yet sad, case, a bug was opened in the Jakarta Tomcat project which includes the entire text of an email from a Sun engineer responding to one of these bugs, saying, "Ask the Jakarta people." That Tomcat bug was closed, "Invalid", with the note, "JVM crashes are JVM bugs, not Tomcat bugs. Take this up with Sun". A lot of finger pointing, but not a lot of help from an application developer's perspective. Never did get this outsourced app to work for longer than 30 minutes on anything but a very specific JDK/set of C Libraries/apache version/tomcat version/connector version/kernel/etc. Red Hat 7.2 Linux box (I called in an Ubergeek to help me and we worked literally weeks trying to get the app to run on our hardware. The goobers who wrote it couldn't deploy to anything. It simply would not run on anything but their development box. And it is a tiny app. Could've been done in PHP in about 1/3rd the time.) I'll admit being relatively ignorant about Java and tomcat, but my first experience with it makes me want to run and hide from it. bcnu, Mikem
Post #153,934 by admin 5/5/04 7:10:58 PM Reply	Have to agree with the Tomcat people. VM or JIT errors are the responsibility of the maker of the JDK. If you can get that with a particular set of application code, it's not the code's fault. Could be RedHat too. FWIW I've only had a JVM core dump once with some dodgy encryption code in 1.3.0, which was fixed with an upgrade: JVM problem. And I've been using Tomcat steadily for a few months now with only one issue (memory leak with reloading servlets; known issue and only a "problem" during heavy development). I'd be interested in seeing the application. Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #153,996 by mmoffitt 5/6/04 8:30:46 AM Reply	Re: seeing the application. No, you wouldn't like to see it. Perhaps I'm being overly critical, I don't know. As you know, I'm not a java hack, but judging from the things I saw that I do know about (the db stuff) the app is probably a horror show. In that thread I referred to, some folks posted that a bug in their code was causing JVM crashes. That would have been my guess as to what our problems were initially. But then, it did run on their machine. We've had it running on our box almost without incident for about 3 months now under very light load. No way of guessing what a heavy load would do to it - and I shudder at the thought. The "bug up my butt" about Java was actually a result of my experiences with this app. Going in, I was actually looking forward to learning about it. Then, after too many all-nighters to count (and I'm far too old for that) I was bitter. I mean, I didn't write it, the consultants who wrote it couldn't deploy it and my PHB was hammering me to "make it work". The experience left me with the sense that this tomcat/apache/JSP stuff is very, very sensitive (fragile?). The whole thing just seems like a mish-mash of fragile stuff that just barely works together - breathe on it too hard and BOOM! See you here at 2am. bcnu, Mikem
Post #154,004 by admin 5/6/04 9:20:19 AM Reply	Bad code in any language is like that. And I'd like to see it just from a forensics standpoint of figuring out what they did to make it so unstable. I've had JServ apps (precursor to Tomcat) running for over a year at a time under reasonably heavy load. Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #154,034 by mmoffitt 5/6/04 11:06:25 AM Reply	I'll try for permission to show you. I'm not trying to start a flame war on this, but isn't it one of Java's touted strengths that because of its architecture (especially its lack of pointers, automagic memory management, etc.) you aren't supposed to be able to crash a JVM with bad code? Or have I just read too much of the hype? In production, what is the difference between bad code causing an os/machine hang and bad java code causing a jvm crash? From the 10,000 foot view, if a product isn't capable of doing the thing that is supposed to be among its greatest strengths, what does that say about the product overall? bcnu, Mikem
Post #154,040 by admin 5/6/04 11:27:55 AM Reply	Bad code... As I said, I agree with the Tomcat people's assertion that this is a Sun problem. Given that there are no bugs in the VM, you can't crash the JVM. A crashing JVM is a bad JVM, period. Sun has an issue there and needs to fix it. That said, JVM crashes in my experience, and in the absence of JNI, are very very rare. I've seen one in my career, caused by some rather tense byte manipulation code. IMO that says nothing about the product overall, and everything about that particular JVM release. I've seen more bugs in C compilers and the like than I have in JVMs. Condemning an entire product because of one bad experience is rather Rossish, don't you think? :-) Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #154,043 by mmoffitt 5/6/04 11:33:45 AM Reply	Rossish? :0) Maybe so. There's more baggage associated with this fiasco that I won't bore you with. Suffice it to say that the damned app should have been done w/PHP and the only reason tomcat/JSP was selected was that a PHB confused Java w/JSP while reading marketing foo from IBM. ;0) bcnu, Mikem
Post #154,046 by admin 5/6/04 11:35:32 AM Reply	I've used PHP. I prefer JSP, believe it or not. PHP is a giant hack IMO (references... shudder). Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #154,051 by mmoffitt 5/6/04 11:50:36 AM 5/6/04 11:52:05 AM Reply	To each his own. But, here we have two people who know PHP. None that know Java/JSP. I'm always in favor of whatever works and sufficiently floats your boat. I'm not married to PHP, but my view is that everything you use has its warts. It's just that I know (some/most?) of PHP's warts, which makes it easier for me to fix. And I am constantly in search of "easy". :-) [Edit]: BTW, you still classify me as one of those whining weenies who slam Java out of ignorance? bcnu, Mikem Edited by mmoffitt May 6, 2004, 11:52:05 AM EDT Expand All History
Post #154,056 by admin 5/6/04 12:00:28 PM Reply	If you have the inhouse experience Then the PHB was truly an idiot for bringing in something else. But that has nothing to do with Java. ;-) As far as being a whining weenie, as long as you confine yourself to whining about Sun's 1.4.2 JDK, I don't have an issue. ;-) Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #154,120 by mmoffitt 5/6/04 5:16:20 PM Reply	Heh. ...as long as you confine yourself to whining about Sun's 1.4.2 JDK, Except that it did it with Blackdown's and IBM's as well. So, Java's open game then, yes? :-D bcnu, Mikem
Post #154,123 by admin 5/6/04 5:26:04 PM Reply	WTF? You got the same signal 11 in 3 different JDKs?? Does this thing use JNI by any chance? Or some libraries (like Oracle's OCI drivers) that use JNI? Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #154,452 by mmoffitt 5/10/04 9:24:58 AM Reply	Yes, sig 11 w/different JDK's. And different versions. I honestly cannot tell you which ones we tried, but we tried everything we could get our hands on. The last thing we did (rollback of libC) seems to have worked. I'm told that JNI is not used. In the absence of source code, is there a quick way to tell? bcnu, Mikem If you can read this, you are not the President.
Post #154,472 by admin 5/10/04 10:16:56 AM Reply	Re: Yes, sig 11 w/different JDK's. There would be .so or .dll files that came with it. Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #154,473 by mmoffitt 5/10/04 10:22:57 AM Reply	Nope. No JNI. bcnu, Mikem If you can read this, you are not the President.
Post #154,552 by mmoffitt 5/10/04 7:47:34 PM Reply	Dude, Got the code. If you're interested, send a message to me: mikem@moffitt-tech.com bcnu, Mikem If you can read this, you are not the President.
Post #154,006 by admin 5/6/04 9:25:59 AM 5/6/04 9:28:10 AM Reply	This thread? [link\|http://forum.java.sun.com/thread.jsp?forum=37&thread=307252&start=0&range=15&hilite=false&q=\|http://forum.java.su...5&hilite=false&q=] After a re-read, looks like it might be a glibc + 1.4.2 issue. The glibc mentioned most often is after 2.2.4, and I run 2.2.3. :-) Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..." Edited by admin May 6, 2004, 09:28:10 AM EDT Expand All History
Post #154,033 by mmoffitt 5/6/04 10:56:46 AM 5/6/04 11:14:25 AM Reply	Yeah, that's it ;0) [Edit: Found my post} We struggled with the same problem for almost two months. Having tried everything suggested here (and various and sundry other things) with no success, we finally downgraded glibc to version 2.2.4. It works and keeps running for weeks. We were able to identify that the bug is in the garbage collection of the jvm - at least that's where our jvm was crashing all the time. It looks like libjvm.so is dependent upon a bug in glibc that is not there anymore. With any later version of glibc, we saw crashes in anywhere from minutes to a couple of hours, regardless of which jdk we used. After downgrading glibc, we could use virtually any jdk just fine. If anyone seeing this problem is running tomcat 4.1.29 on a linux distro - and you can, try moving back your glibc. bcnu, Mikem Edited by mmoffitt May 6, 2004, 11:14:25 AM EDT Expand All History
Post #154,042 by admin 5/6/04 11:33:15 AM Reply	Have you since checked the release notes... ... for notations that it works with glibc > 2.2.4 now? Here's what I'm running at home: \nanderson@spork:~$ java -version\njava version "1.4.1"\nJava(TM) 2 Runtime Environment, Standard Edition (build Blackdown-1.4.1-01)\nJava HotSpot(TM) Client VM (build Blackdown-1.4.1-01, mixed mode)\nanderson@spork:~$ dpkg -l \| grep libc\nii libc6 2.3.2.ds1-10 GNU C Library: Shared libraries and Timezone\n And at work: \nsanderson@bd00402:~$ /usr/local/java/bin/java -version\njava version "1.4.1_06"\nJava(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_06-b01)\nJava HotSpot(TM) Client VM (build 1.4.1_06-b01, mixed mode)\nsanderson@bd00402:~$ dpkg -l \| grep libc\nii libc6 2.3.2.ds1-10 GNU C Library: Shared libraries and Timezone\n I haven't tried 1.4.2 yet. Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #154,050 by mmoffitt 5/6/04 11:46:17 AM Reply	No, I haven't. Been too busy w/loads of other stuff. I was just happy to get it running. I will, no doubt, have to re-visit this. It was a panic situation before. The product was delivered two months late, everybody's head was on fire, PHB screaming 'Get it to work! Get it to work!', etc. I'll try to approach it with a more open mind next time. But, the PHB in question is being replaced. This app is our only JSP app and could be redone from scratch w/PHP in a month tops. Dunno if the new PHB will want to continue w/JSP or not (this might be a do-over). Even if we stick with java, I'd bet the ranch that 80% of the code will be reworked completely. I know for sure that the database will be redesigned and that sp's will be used to insert/delete/update data (not to mention all the 'select a.*, b.column1 from table1 a, table2 b where a.name = b.name and a.date = b.date and a.address = b.address and a.plant = b.plant and a.location = b.location and a.type = b.type and a.invoice = b.invoice' crap. Who knows, might even add some Views, Triggers, explicit transaction processing and DRI to the database!) Thanks. bcnu, Mikem

Welcome to IWETHEY!