Post #153,996
5/6/04 8:30:46 AM
|
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
5/6/04 9:20:19 AM
|
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
5/6/04 11:06:25 AM
|
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
5/6/04 11:27:55 AM
|
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
5/6/04 11:33:45 AM
|
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
5/6/04 11:35:32 AM
|
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
5/6/04 11:50:36 AM
5/6/04 11:52:05 AM
|
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
|
Post #154,056
5/6/04 12:00:28 PM
|
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
5/6/04 5:16:20 PM
|
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
5/6/04 5:26:04 PM
|
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
5/10/04 9:24:58 AM
|
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
5/10/04 10:16:56 AM
|
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
5/10/04 10:22:57 AM
|
Nope. No JNI.
bcnu, Mikem
If you can read this, you are not the President.
|
Post #154,552
5/10/04 7:47:34 PM
|
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.
|