On 8 Jun 2009, at 14:24, Johan Svensson wrote: > On Mon, Jun 8, 2009 at 1:42 PM, Neil Ellis > <neil.el...@mangala.co.uk> wrote: >> On 8 Jun 2009, at 12:21, Johan Svensson wrote: >>> On Mon, Jun 8, 2009 at 12:04 PM, Neil Ellis >>> <neil.el...@mangala.co.uk> wrote: >>>> So after a weekend away from the problem it occured to me that I >>>> had >>>> neglected to nohup the java process. Therefore I am suspect that >>>> was >>>> the problem, running now with nohup ;-) >>>> >>> >>> Lets hope this works. I am not 100% sure about this but normally a >>> kill signal sent to a Java process shouldn't affect any of the Java >>> thread's interrupt status. If thats the case (when for example using >>> java.nio stuff) behavior is new to me. A way to achieve this would >>> be >>> to register a signal handler (via sun.misc.Signal) and manually go >>> through each thread and interrupt them (so check if there is any >>> code >>> like that running). What JVM are you running? >> >> Okay so I was clutching a little ;-) I bit of reading and I now >> understand that was a naive guess. Although the fact that Java >> actually can receive a HUP even if nohup'ed depresses me a little :). >> > > I tested this on Sun's 1.6 JVM and could not get any threads to > interrupt sending various signals to the Java process. What JVM are > you running?
1.6 Sun, I was agreeing with you Johan btw. I just made the naive assumption that a HUP might trigger Thread interrupts. I then (later) found out that nohup is actually ignored by the JVM anyway, so the signal would reach the JVM even though someone had said nohup. Let me apply your patch and see where I get, thanks. > > >>> >>> >>> Another thing, I just now went through all the catching of >>> InterruptedException we do in Neo4j and actually found one place >>> that >>> calls java.nio code that didn't reset the interrupt properly after a >>> wait. I fixed this in trunk (b9-SNAPSHOT) and if you want you could >>> try to apply the same patch to b8 (see >>> https://trac.neo4j.org/changeset/2890) or I could provide a jar for >>> you. If you want to try out b9-SNAPSHOT just remember you can't >>> switch >>> back to b8 since the store layout as changed. >> >> That's fine, we recreate the database from scratch each time, I'll >> checkout and build today and let you know - how stable is b9-SNAPSHOT >> btw. am I likely to shoot myself in the foot using it? >> > > That depends :) I would say that trunk is not stable now because we > haven't done any extensive testing on it yet. The plan is to release > b9-SNAPSHOT at the end of this month. > > Right now we are working on some (minor) known issues and next week we > will get some API changes in place. After that there are a few > improvements I hope to get in (or they will be pushed to next > release). This is followed by two weeks of testing then hopefully a > release. > So I'll try the patch on the b8 code base then, makes sense. > Regards, > Johan > _______________________________________________ > Neo mailing list > User@lists.neo4j.org > https://lists.neo4j.org/mailman/listinfo/user _______________________________________________ Neo mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user
