Discussions

General J2EE: Is Java/J2EE reliable?

  1. Is Java/J2EE reliable? (8 messages)

    Well, I'm pretty sure most of you will say 'yes, look at transactions, clustering solutions, robust threading etc'. However my experience shows that J2EE has two BIG problems, that make me doubt in the reliability of J2EE as a server side platform despite many beautiful technologies in and on top of J2EE for two simple reasons:

    1. Unexpected OutOfMemoryErrors. When a system is pretty much loaded it eats memory as much as it can, reaching its limits. However, when the load gets lower, the JVM's memory size in use doesn't seem to shrink, which after some time results in OutOfMemoryError. This is why we have people whose duty is to look after servers and restart them as soon as OutOfMemoryError has been reached. Our servers have 4G of RAM and guess what we do twice a week.

    2. (Unpredictable) garbage collection pauses. Sometimes I need my jobs to run at EXACTLY requested time, not one second later. Running a critical task a second later than expected may result in critical problems, especially if this repeats from time to time.

    Is it just me, or somebody else has similar problems?

    How do you handle similar situations?

    With that said, can you still name J2EE a RELIABLE platform?

    Threaded Messages (8)

  2. Is Java/J2EE reliable?[ Go to top ]

    the answer for OutOfMemoryError: if your server has 4GB of RAM, it does not mean that your VM will use that much. By default VMs use very low memory. You have to pass -xmx(4GB) parameter to your VM to allow it for using 4GB of RAM. If it does not worked, its sure that you have not required refrences to objects that does not allow VM to free thier memory, in that case I suggest to read memory section in "Effective Java Programming", it helps you to find your memory leak section of your code.
    2. At some point your memory need to be released to allow other works done properly, in that case GC will pause the program for a little time, if doesn't your program will crash. If you think that C application will work better in that points, try it and you will found which work better.
  3. Sergei,

    Tuning your Garbage Collection parameters and paying close attention to the lifecycle of your objects are critical to alleviating this problem. Have you run profilers against the application in order to determine which objects are filling-up the memory? Most likely, you either have:

    - Hanging object references that prevent the garbage collector from cleaning up the objects while they are young, which is far more efficeint and doesn't cause detrimental pauses (i.e. Nursury GC's). Even worse, you may have references that aren't being cleaned up at all which will always lead to an OutOfMemory error eventually.

    - Too much data for the maximum VM size. A profiler might show you that the objects you are storing are larger than you thought.

    With some profiling and tuning, you will likely identify some culprits and easy gains pretty quickly. There is also a very low-tech and inelegant way to assure performance at a given time . . . . You can do an explicit GC (i.e. System.gc()) and take the performance hit at a time of your choosing--perhaps at night when you know activity is low.

    GemFire's distributed caching products also provide a relatively easy way to eliminate memory limitation problems. You can use our product to either overflow Least Recently Used (LRU) objects to disk based on memory utilization or Collection size, or you can distribute objects over multiple VM's in a partitioned caching scheme--all of this with very little change to your existing code.

    Cheers,

    Gideon
    GemFire-The Enterprise Data Fabric
    http://www.gemstone.com
  4. Is Java/J2EE reliable?[ Go to top ]

    Well, I'm pretty sure most of you will say 'yes, look at transactions, clustering solutions, robust threading etc'. However my experience shows that J2EE has two BIG problems, that make me doubt in the reliability of J2EE as a server side platform despite many beautiful technologies in and on top of J2EE for two simple reasons:1. Unexpected OutOfMemoryErrors. When a system is pretty much loaded it eats memory as much as it can, reaching its limits. However, when the load gets lower, the JVM's memory size in use doesn't seem to shrink, which after some time results in OutOfMemoryError. This is why we have people whose duty is to look after servers and restart them as soon as OutOfMemoryError has been reached. Our servers have 4G of RAM and guess what we do twice a week.2. (Unpredictable) garbage collection pauses. Sometimes I need my jobs to run at EXACTLY requested time, not one second later. Running a critical task a second later than expected may result in critical problems, especially if this repeats from time to time.Is it just me, or somebody else has similar problems?How do you handle similar situations?With that said, can you still name J2EE a RELIABLE platform?

    JAVA IS NOT MEANT FOR DEVELOPING APPILCATIONS TO CONTROL A SPACE SHIP OR ANYTHING OF THAT SORT..! IT IS MEANT MORE FOR TOLERANT BUSINESS APPLICATIONS AND OF THE LIKE, WITH MORE EMPHASIS ON REUSABILITY ,PLATFORM INDEPENDENCE , RAPID DEVELOPMENT, EASE OF MAINTENENCE ETC..!
  5. Is Java/J2EE reliable?[ Go to top ]

    JAVA IS NOT MEANT FOR DEVELOPING APPILCATIONS TO CONTROL A SPACE SHIP OR ANYTHING OF THAT SORT..! IT IS MEANT MORE FOR TOLERANT BUSINESS APPLICATIONS AND OF THE LIKE, WITH MORE EMPHASIS ON REUSABILITY ,PLATFORM INDEPENDENCE , RAPID DEVELOPMENT, EASE OF MAINTENENCE ETC..!

    Although I wouldn't stake somebody's life on the behavior of Java Garbage Collection, Java is certainly used in some of the most demanding environments. Many of the Global Investment Banks successfully run their most important and latency-sensitive trading systems on Java platforms--systems that manage transactions worth huge sums of money and where a failure can easily result in the loss of hundreds of thousands of dollars (or more!).

    To be sure, many firms in the Financial Services world choose to build these applications in C/C++, but I have never seen a case where that decision has actually specifically improved profitability over the long term.

    Cheers,

    Gideon
    GemFire-The Enterprise Data Fabric
    http://www.gemstone.com
  6. Is Java/J2EE reliable?[ Go to top ]

    JAVA IS NOT MEANT FOR DEVELOPING APPILCATIONS TO CONTROL A SPACE SHIP OR ANYTHING OF THAT SORT..! IT IS MEANT MORE FOR TOLERANT BUSINESS APPLICATIONS AND OF THE LIKE, WITH MORE EMPHASIS ON REUSABILITY ,PLATFORM INDEPENDENCE , RAPID DEVELOPMENT, EASE OF MAINTENENCE ETC..!

    The people at Boeing will disagree. At JavaOne we saw a few demonstrations of what various projects have acheived with the Real Time Specification for Java (RTSJ).

    The real time thread and memory management is reliable and predictable. I imagine we will probably see some J2EE application servers in the future provide some kind of support for RTSJ integration.

    It is not a matter of just taking existing code and executing in a realtime thread though.
  7. Is Java/J2EE reliable?[ Go to top ]

    I had an interesting problem just the other day.

    Our production server that processes messages using MDB from JMS queue would freeze. No logging or activity or CPU consumption.... kill -9 ...

    I am pretty sure no Java code is supposed to be able to freeze a VM. You could create some kind of endless loop in the high priority thread but that will cause the process to consume a lot of CPU. We had none of that. No deadlock either because the transaction manager will eventually timeout the transactions that would result in a rollback.

    The last log entries did not help either, there was no indication as to the problem. It had to be load related but it was no more load than what we have handled successfully before.

    Then we got lucky, our pre-production server reported an error indicating the transaction log was full. The same day we had another freeze on production after an OutOfMemory error was reported in the log. However at that time the process was not even consuming half the amount of memory we had allowed using -Xmx.

    This leads me to believe that the OutOfMemory exception was thrown by the transaction manager when the log is full.
    We will be increasing the transaction log size to see if that solves the freeze.

    More to follow...
  8. Is Java/J2EE reliable?[ Go to top ]

    In these types of situations, you should always do a thread dump before killing off the process (by doing a "kill -3"). This can give you lots of useful information about what the threads were doing at the time things froze.

    OutOfMemory errors can certainly be very frustrating. In early versions of the JVM, reaching the system resource limit of something like File Descriptors would throw the error and send you completely off-course in your debugging efforts. I think these issues have been resolved, but beware also of any JNI componenents running alongside the JVM in your process--they are often the culprits as well and Java can't capture/log their errors in any meaningful way.

    Cheers,

    Gideon
    GemFire-The Enterprise Data Fabric
    http://www.gemstone.com
  9. We are in crunch time and things are looking good so far.

    The next week will tell. The system will be processing largest volumes yet. Thanks for the tip on kill -3, have not had a chance to use it yet but the support guys have been informed.