Given the pattern of it, I might be able to produce a PMD checks for this. This way, you could run it across the code base and check for all occurences of it.
On 10 September 2014 13:58, Alan Field <afi...@redhat.com> wrote: > Hey Bela, > > > Just a quick heads up. I'm currently working on > > https://issues.jboss.org/browse/JGRP-1877, which it critical as it may: > > - cause RPCs to return prematurely (possibly with a TimeoutException), or > > - cause RPCs to blocks for a long time (pick which one is worse :-)) > > How frequently can these errors occur? Is this something that is not very > likely to happen or something that requires an external action to trigger > it? (i.e. changing the time via NTP) Just trying to determine the priority > of this issue. > > Thanks, > Alan > > ----- Original Message ----- > > From: "Bela Ban" <b...@redhat.com> > > To: infinispan-dev@lists.jboss.org > > Sent: Wednesday, September 10, 2014 12:05:11 PM > > Subject: [infinispan-dev] JGRP-1877 > > > > Just a quick heads up. I'm currently working on > > https://issues.jboss.org/browse/JGRP-1877, which it critical as it may: > > - cause RPCs to return prematurely (possibly with a TimeoutException), or > > - cause RPCs to blocks for a long time (pick which one is worse :-)) > > > > This is due to my misunderstanding of the semantics of > > System.nanoTime(), I frequently have code like this, which computes a > > future deadline for a timeout: > > > > long wait_time=TimeUnit.NANOSECONDS.convert(timeout, > > TimeUnit.MILLISECONDS); > > final long target_time=System.nanoTime() + wait_time; > > while(wait_time > 0 && !hasResult) { /* Wait for responses: > */ > > wait_time=target_time - System.nanoTime(); > > if(wait_time > 0) { > > try {cond.await(wait_time, TimeUnit.NANOSECONDS);} > > catch(Exception e) {} > > } > > } > > if(!hasResult && wait_time <= 0) > > throw new TimeoutException(); > > > > Variable target_time can possibly become *negative* if nanoTime() > > returns a negative value. If so, hasResult is false and wait_time > > negative, and therefore a TimeoutException would be thrown ! > > > > While I'm at it, I'll also fix my uses of System.currentTimeMillis(), > > and replace it with nanoTime(). Our good friend Erik has run into issues > > with RPCs (using currentTimeMillis()) hanging forever when their > > NTP-based servers adjusted the time .... backwards ! > > > > Please be aware of nanoTime() in your own code, e.g. > > long t0=nanoTime(); > > ... > > long t1=nanoTime(); > > > > It is *not* guaranteed that t1 > t0 because of numeric overflow (t0 > > might be Long.MAX_VALUE-1 and t1 Long.MAX_VALUE +2 !). The only way to > > compare them is t1 - t0 > 0 (t1 is more recent) or < 0 t0 is more recent. > > > > Just thought I wanted to pass this on, in case somebody made the same > > stupid mistake... > > > > Thanks to David Lloyd for pointing this out ! > > > > -- > > Bela Ban, JGroups lead (http://www.jgroups.org) > > _______________________________________________ > > infinispan-dev mailing list > > infinispan-dev@lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/infinispan-dev > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev > -- Romain PELISSE, *"The trouble with having an open mind, of course, is that people will insist on coming along and trying to put things in it" -- Terry Pratchett* Belaran ins Prussia (blog) <http://blog.wordpress.belaran.eu/> (... finally up and running !)
_______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
