Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #34441

Re: Java program "debugging" itself...

Show all headers | View raw

On 6/2/2016 10:21 AM, comp.lang.coffee wrote:
> On Thursday, June 2, 2016 at 8:36:51 AM UTC-5, Andreas Leitgeb wrote:
>> My application is a server that runs separate tasks as
>> requested by clients.
>>
>> Rarely it happens, that one of the tasks goes awry, due
>> to some bug in the task's code itself.  Latest incident
>> was a loop that accidentally didn't terminate but grew a
>> StringBuilder's buffer beyond any bounds.
>>
>> Given that there exist some natural "constraints" on these
>> tasks, like they would *never ever* allocate an array of
>> more than a million elements (yes, that's a rather low
>> upper bound), then I'd like to use some debugging-API to
>> request that any thread trying to "new" any array of
>> size >= 1,000,000 ought to get e.g. an OutOfMemoryError -
>> regardless of actually available heap-space. This of
>> course would include "new" statements happening from
>> the standard library (like StringBuilder's .append(...) ).
>>
>> Does anyone know, whether any VMs offer any (maybe non-
>> standard) API for applications to "watch" themselves?
>>
>> The whole point is that any task may fail, but the show
>> (i.e. the server) must go on...
>
> It looks to me like you could use custom exception handling to solve your problem. You can set the limit configurable so you can update it as required.

     If you suggest he should catch OutOfMemoryException and stop the
thread that caught it, I don't think that will work.  (If you meant
something else, just ignore this ...)

     The problem is a lot like that of Linux' OOM Killer: The task that
hits the limit is not necessarily the task at fault.  If a runaway task
gobbles up almost all the memory and then a well-behaved task gets an
OutOfMemoryException on something innocuous like `new int[10]', the
exception is thrown to the "wrong" thread: Not the runaway, but the
innocent bystander.

     The traditional approach to this sort of problem is to run each
task in its own JVM.  I'm sure Andreas is aware of this, and I'm sure
he'd do that if it made sense (it might not if, for example, most of
the tasks are short-lived).  Since he's asking for another means of
attack, I surmise that something in his situation makes the multi-JVM
approach undesirable.

     Unfortunately, I know of no way to "contain the damage" when one
of several tasks in the same JVM decides to go off the rails ...

-- 
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM

Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Java program "debugging" itself... Andreas Leitgeb <avl@logic.at> - 2016-06-02 13:36 +0000
  Re: Java program "debugging" itself... Martin Gregorie <martin@address-in-sig.invalid> - 2016-06-02 14:17 +0000
    Re: Java program "debugging" itself... Andreas Leitgeb <avl@logic.at> - 2016-06-02 15:06 +0000
      Re: Java program "debugging" itself... Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-06-02 11:14 -0400
        Re: Java program "debugging" itself... Andreas Leitgeb <avl@logic.at> - 2016-06-02 15:43 +0000
  Re: Java program "debugging" itself... "comp.lang.coffee" <kirandesai84@gmail.com> - 2016-06-02 07:21 -0700
    Re: Java program "debugging" itself... Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-06-02 10:38 -0400
      Re: Java program "debugging" itself... Robert Klemme <shortcutter@googlemail.com> - 2016-06-02 22:24 +0200
    Re: Java program "debugging" itself... Andreas Leitgeb <avl@logic.at> - 2016-06-02 15:28 +0000
      Re: Java program "debugging" itself... Martin Gregorie <martin@address-in-sig.invalid> - 2016-06-02 22:22 +0000
        Re: Java program "debugging" itself... Andreas Leitgeb <avl@logic.at> - 2016-06-03 15:58 +0000
          Re: Java program "debugging" itself... Wanja Gayk <brixomatic@yahoo.com> - 2016-06-04 21:32 +0200

csiph-web