Re: [infinispan-dev] To Optional or not to Optional?

2017-05-25 Thread David M. Lloyd 
I'm not an Infinispan developer, but I'll chime in anyway. :)

I've never been a fan of Optional.  But the theory behind it that made 
it acceptable in the first place is that it generally gets optimized away.

Now this theory is only true if you never hold a reference to it in any 
persistent manner (it should be very short-lived even as a local 
variable (after optimizations like dead-code & etc. have run)).

What should happen is, the actual allocation should get deleted, and the 
(usually one or two) strictly monomorphic or bi-morphic call(s) should 
each be flattened into what amounts to (at most) simple if/else 
statement(s), all of which should be very fast (as fast as a null-check, 
in theory) and branch-predictable and all that good stuff.  (Now null 
checks have a very slight advantage in that they can be optimistically 
removed in some cases, and only re-added once the operating system gets 
a SIGSEGV or equivalent, but that difference is usually going to be 
pretty small even in fairly tightly optimized code).  This seems 
consistent with the benchmark results.  I doubt it has much to do with 
how hot the code path is (in fact, a hotter code path should mean 
Optional usages will get more accurately optimized by C2 over time). 
With an appropriate JDK build, you can browse the compiler output to 
test this theory out.

If you put an Optional into a field, all of this is very likely to be 
thrown in the garbage.  I think there is some escape analysis stuff that 
might apply but in the most likely case, the heap will simply be 
polluted with a bunch useless crap, along with all the consequences thereof.

So if (and only if) you're using Optional as a return value, creating it 
on the fly (particularly in monomorphic methods), and using the result 
directly via the chainable methods on the Optional class or keeping it 
around only for one or two usages in a local variable (not referring to 
it afterwards in any way), it *should* be fine from a performance 
perspective.  Note that HotSpot is pretty good at knowing the difference 
between when *you* think the value is being referred to and when the 
value is *really* being referred to (this is what caused the finalize() 
debacle that resulted in Runtime.reachabilityFence() being added to Java 
9 - HotSpot was a little *too* good at it).

Aesthetically it's a different story.  There's no magic silver bullet to 
make null problems go away; Optional is a tradeoff just like everything 
in engineering and in life.  I would never put Optional into one of my 
APIs as it exists today (or even as it exists in Java 9, where several 
deficiencies have admittedly been addressed).  I would only start using 
it once it is extremely well-understood and well-established (i.e. maybe 
in 5-10 years I'll have another look).

On 05/25/2017 02:56 AM, Sebastian Laskawiec wrote:
> Indeed Bela, you're an extreme naysayer! :)
> 
> I'm actually trying to get as many comments and arguments out of this 
> discussion. I hope we will be able to iron out a general recommendation 
> or approach how we want to treat Optionals.
> 
> On Tue, May 23, 2017 at 10:14 PM Bela Ban  > wrote:
> 
> Actually, I'm an extreme naysayer! I actually voiced concerns so I'm
> wondering where your assumption there are no naysayers is coming
> from... :-)
> 
> 
> On 23/05/17 1:54 PM, Sebastian Laskawiec wrote:
>  > Hey!
>  >
>  > So I think we have no extreme naysayers to Optional. So let me try to
>  > sum up what we have achieved so:
>  >
>  >   * In macroscale benchmark based on REST interface using Optionals
>  > didn't lower the performance.
>  >   * +1 for using it in public APIs, especially for those using
>  > functional style.
>  >   * Creating lots of Optional instances might add some pressure
> on GC,
>  > so we need to be careful when using them in hot code paths. In
>  > such cases it is required to run a micro scale benchamark to make
>  > sure the performance didn't drop. The microbenchmark should also
>  > be followed by macro scale benchamrk - PerfJobAck. Also, keep an
>  > eye on Eden space in such cases.
>  >
>  > If you agree with me, and there are no hard evidence that using
>  > Optional degrade performance significantly, I would like to issue a
>  > pull request and put those findings into contributing guide [1].
>  >
>  > Thanks,
>  > Sebastian
>  >
>  > [1]
>  >
> 
> https://github.com/infinispan/infinispan/tree/master/documentation/src/main/asciidoc/contributing
>  >
>  > On Mon, May 22, 2017 at 6:36 PM Galder Zamarreño
> 
>  > >> wrote:
>  >
>  > I think Sanne's right here, any differences in such large scale
>  > test are hard to decipher.
>

Re: [infinispan-dev] if (trace) logger.tracef - it makes sense

2016-09-30 Thread David M. Lloyd 
The performance problem that this trick is meant to resolve is really a 
problem in the logging backend.  It *should* be faster inside of 
WildFly, where JBoss LogManager is used, because that project just 
checks a single volatile field for the level check... and the path to 
that code *should* be inline-friendly.

On 09/30/2016 11:16 AM, Dennis Reed wrote:
> As Wolf noted, caching the trace flag is bad when trying to debug issues.
>
> Don't do it!  It's not worth breaking the logging semantics for a
> nano-second level performance difference.  (if your trace is being
> called enough for that tiny impact to make any real difference, that
> trace logging is going to be WAY too verbose to be of any use anyways).
>
> If I see it done, I'm going to open a BZ.
>
> -Dennis
>
>
> On 09/30/2016 08:23 AM, Sanne Grinovero wrote:
>> this discussion appears on this mailing list approximately every 2 years :)
>>
>> On 30 September 2016 at 13:41, Dan Berindei <dan.berin...@gmail.com> wrote:
>>> I should stress that we only cache `isTraceEnabled()` in a static
>>> field. Debug logging can still be enabled or disabled on the fly.
>>>
>>>
>>> Cheers
>>> Dan
>>>
>>>
>>> On Fri, Sep 30, 2016 at 3:14 PM, Wolf Fink <wf...@redhat.com> wrote:
>>>> Ok,
>>>>
>>>> thanks for clarifying it.
>>>>
>>>> So there is a factor of 3 for the test if no trace is enabled, just for
>>>> checking.
>>>> It makes sense to use it.
>>>> But my concern is still that it is sometimes good to have the possibility 
>>>> to
>>>> enable debug for some important information in production just on the fly
>>>> and switch it of to prevent from throtteling the server by that log
>>>> statements or restart the server.
>>>> We have the same issue in EAP but here a restart is not that bad as here 
>>>> you
>>>> don't have to load the cache or rebalance the cluster for stop/start.
>>>>
>>>> - Wolf
>>>>
>>>> On Fri, Sep 30, 2016 at 1:53 PM, David M. Lloyd <david.ll...@redhat.com>
>>>> wrote:
>>>>>
>>>>> On 09/30/2016 01:53 AM, Sebastian Laskawiec wrote:
>>>>>> Hey!
>>>>>>
>>>>>> A while ago I asked Radim and Dan about these kind of constructs [1]:
>>>>>>
>>>>>> private boolean trace = logger.isTraceEnabled(); //stored in a field
>>>>>>
>>>>>> ... called in some method ...
>>>>>> if(trace)
>>>>>> logger.tracef(...);
>>>>>> ...
>>>>>>
>>>>>> At first they seemed wrong to me, because if one changes logging level
>>>>>> (using JMX for example), the code won't notice it. I also though it's
>>>>>> quite ok to use tracef directly, because JIT will inline and optimize
>>>>>> it.
>>>>>>
>>>>>> Unfortunately my benchmarks [2] show that I was wrong. Logger#tracef
>>>>>> indeed checks if the logging level is enabled but since JBoss Logging
>>>>>> may use different backends, the check is not trivial and is not inlined
>>>>>> (at least with default settings).
>>>>>
>>>>> What backend where you using with your test?
>>>>>
>>>>>> The performance results look like this:
>>>>>> Benchmark  Mode  Cnt   Score  Error
>>>>>> Units
>>>>>> MyBenchmark.noVariablethrpt   20   *717252060.124* ± 13420522.229
>>>>>> ops/s
>>>>>> MyBenchmark.withVariable  thrpt   20  *2358360244.627* ± 50214969.572
>>>>>> ops/s
>>>>>>
>>>>>> So if you even see a construct like this: logger.debuf or logger.tracef
>>>>>> - make sure you check if the logging level is enabled (and the check
>>>>>> result is stored in a field).
>>>>>>
>>>>>> That was a bit surprising and interesting lesson :D
>>>>>>
>>>>>> Thanks
>>>>>> Sebastian
>>>>>>
>>>>>> [1]
>>>>>> https://github.com/infinispan/infinispan/pull/4538#discussion_r80666086
>>>>>> [2] https://github.com/slaskawi/jboss-logging-perf-test
>>>>>>
>>>>>>
>>>>>> __

Re: [infinispan-dev] if (trace) logger.tracef - it makes sense

2016-09-30 Thread David M. Lloyd 
On 09/30/2016 01:53 AM, Sebastian Laskawiec wrote:
> Hey!
>
> A while ago I asked Radim and Dan about these kind of constructs [1]:
>
> private boolean trace = logger.isTraceEnabled(); //stored in a field
>
> ... called in some method ...
> if(trace)
> logger.tracef(...);
> ...
>
> At first they seemed wrong to me, because if one changes logging level
> (using JMX for example), the code won't notice it. I also though it's
> quite ok to use tracef directly, because JIT will inline and optimize it.
>
> Unfortunately my benchmarks [2] show that I was wrong. Logger#tracef
> indeed checks if the logging level is enabled but since JBoss Logging
> may use different backends, the check is not trivial and is not inlined
> (at least with default settings).

What backend where you using with your test?

> The performance results look like this:
> Benchmark  Mode  Cnt   Score  Error  Units
> MyBenchmark.noVariablethrpt   20   *717252060.124* ± 13420522.229  ops/s
> MyBenchmark.withVariable  thrpt   20  *2358360244.627* ± 50214969.572  ops/s
>
> So if you even see a construct like this: logger.debuf or logger.tracef
> - make sure you check if the logging level is enabled (and the check
> result is stored in a field).
>
> That was a bit surprising and interesting lesson :D
>
> Thanks
> Sebastian
>
> [1] https://github.com/infinispan/infinispan/pull/4538#discussion_r80666086
> [2] https://github.com/slaskawi/jboss-logging-perf-test
>
>
> ___
> infinispan-dev mailing list
> infinispan-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>

-- 
- DML
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Re: [infinispan-dev] JBoss Marshalling 1.4.4.Final + ASL + Infinispan 6

2014-03-05 Thread David M. Lloyd 
On 03/05/2014 02:12 PM, Tristan Tarrant wrote:
 Dear all,

 David Lloyd has kindly release JBoss Marshalling 1.4.4.Final under the
 ASL: this means that all of our core deps are now ASL. Should we release
 a 6.0.2 with this dependency change only ?

FWIW there's also a nice bugfix in there: the long-standing 
https://issues.jboss.org/browse/JBMAR-120 was recently solved, allowing 
objects which are Serializable but with read/writeObject methods which 
failed to read/write their fields to serialize safely, where before they 
would cause an exception.

-- 
- DML
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Re: [infinispan-dev] Clean ThreadLocals

2013-12-11 Thread David M. Lloyd 
On 12/11/2013 04:47 PM, Pedro Ruivo wrote:
 Hi,

 I've created a method to clean a specific ThreadLocal variable from all
 live threads [1].

 My goal is to clean the ThreadLocal variables after a cache stops. It's
 kind expensive method (it uses reflection) but I think it is fine.

 Currently, I'm using it to clear the Marshaller ThreadLocal in here [2].

 Does anyone see any problem with this approach? Maybe it can be used in
 other possible leaking ThreadLocals?

It's an interesting idea (I've done something similar in the past to 
simply drop all thread locals).  I would recommend that you check that 
all the JDKs you want to support use the same technique for thread 
locals though.  Because these fields are not part of the JDK, they may 
not always exist in all environments.

Also, it is important to only ever clean the thread locals of your 
current thread, or you're inviting all kinds of bizarre concurrency 
problems (maybe even locking threads into infinite loops), especially if 
the thread is running and actively using thread locals at the time.
-- 
- DML
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Re: [infinispan-dev] JBM version in ISPN 6.0

2013-09-20 Thread David M. Lloyd 
On 09/20/2013 06:40 AM, Mircea Markus wrote:
 Hi guys,

 ISPN 6.0 final is scheduled for 11 Oct.
 Is there going to be an JBM 2.0 final release prior that date?
 Paul, what JBM version does 6.0 integration into AS?

JBoss Marshalling 2.0 will have incompatible API changes that are not 
going to be in WildFly 8.  I have however backported all of the fixes 
from 2.0 into 1.4.0.Final.  As a stepping stone to 2.0, you should use 
1.4.0.Final (be especially mindful of deprecations - the Creator API in 
particular is deprecated and does not need to be used in conjunction 
with MarshallingConfiguration anymore).

I expect that EAP 7 will be using Marshalling 2.0, and probably WildFly 
9 or 10.
-- 
- DML
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Re: [infinispan-dev] CHM or CHMv8?

2013-04-19 Thread David M. Lloyd 
On 04/19/2013 05:17 AM, Sanne Grinovero wrote:
 On 19 April 2013 11:10, Dan Berindei dan.berin...@gmail.com wrote:



 On Fri, Apr 19, 2013 at 12:58 PM, Sanne Grinovero sa...@infinispan.org
 wrote:

 On 19 April 2013 10:37, Dan Berindei dan.berin...@gmail.com wrote:
 Testing mixed read/write performance with capacity 10, keys 30,
 concurrency level 32, threads 12, read:write ratio 99:1
 Container CHM   Ops/s 5178894.77  Gets/s 5127105.82  Puts/s
 51788.95  HitRatio  86.23  Size 177848  stdDev   60896.42
 Container CHMV8 Ops/s 5768824.37  Gets/s 5711136.13  Puts/s
 57688.24  HitRatio  84.72  Size 171964  stdDev   60249.99

 Nice, thanks.

 The test is probably limited by the 1% writes, but I think it does show
 that
 reads in CHMV8 are not slower than reads in OpenJDK7's CHM.
 I haven't measured it, but the memory footprint should also be better,
 because it doesn't use segments any more.

 AFAIK the memoryCHMV8 also uses copy-on-write at the bucket level, but
 we
 could definitely do a pure read test with a HashMap to see how big the
 performance difference is.

 By copy-on-write I didn't mean on the single elements, but on the
 whole map instance:

 private volatile HashMap configuration;

 synchronized addConfigurationProperty(String, String) {
   HashMap newcopy = new HashMap( configuration ):
   newcopy.put(..);
   configuration = newcopy;
 }

 Of course that is never going to scale for writes, but if writes stop
 at runtime after all services are started I would expect that the
 simplicity of the non-threadsafe HashMap should have some benefit over
 CHM{whatever}, or it would have been removed already?


 Right, we should be able to tell whether that's worth doing with a pure read
 test with a CHMV8 and a HashMap :)

 IFF you find out CHMV8 is as good as HashMap for read only, you have
 two options:
   - ask the JDK team to drop the HashMap code as it's no longer needed
   - fix your benchmark :-P

 In other words, I'd consider it highly surprising and suspicious
 (still interesting though!)

It's not as surprising as you think.  On x86, volatile reads are the 
same as regular reads (not counting some possible reordering magic).  So 
if a CHM read is a hash, an array access, and a list traversal, and so 
is HM (and I believe this is true though I'd have to review the code 
again to be sure), I'd expect very similar execution performance on 
read.  I think some of the anti-collision features in V8 might come into 
play under some circumstances though which might affect performance in a 
negative way (wrt the constant big-O component) but overall in a 
positive way (by turning the linear big-O component into a logarithmic one).

-- 
- DML
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Re: [infinispan-dev] CHM or CHMv8?

2013-04-19 Thread David M. Lloyd 
On 04/19/2013 08:22 AM, Sanne Grinovero wrote:
 On 19 April 2013 13:52, David M. Lloyd david.ll...@redhat.com wrote:
 On 04/19/2013 05:17 AM, Sanne Grinovero wrote:
 On 19 April 2013 11:10, Dan Berindei dan.berin...@gmail.com wrote:



 On Fri, Apr 19, 2013 at 12:58 PM, Sanne Grinovero sa...@infinispan.org
 wrote:

 On 19 April 2013 10:37, Dan Berindei dan.berin...@gmail.com wrote:
 Testing mixed read/write performance with capacity 10, keys 30,
 concurrency level 32, threads 12, read:write ratio 99:1
 Container CHM   Ops/s 5178894.77  Gets/s 5127105.82  Puts/s
 51788.95  HitRatio  86.23  Size 177848  stdDev   60896.42
 Container CHMV8 Ops/s 5768824.37  Gets/s 5711136.13  Puts/s
 57688.24  HitRatio  84.72  Size 171964  stdDev   60249.99

 Nice, thanks.

 The test is probably limited by the 1% writes, but I think it does show
 that
 reads in CHMV8 are not slower than reads in OpenJDK7's CHM.
 I haven't measured it, but the memory footprint should also be better,
 because it doesn't use segments any more.

 AFAIK the memoryCHMV8 also uses copy-on-write at the bucket level, but
 we
 could definitely do a pure read test with a HashMap to see how big the
 performance difference is.

 By copy-on-write I didn't mean on the single elements, but on the
 whole map instance:

 private volatile HashMap configuration;

 synchronized addConfigurationProperty(String, String) {
HashMap newcopy = new HashMap( configuration ):
newcopy.put(..);
configuration = newcopy;
 }

 Of course that is never going to scale for writes, but if writes stop
 at runtime after all services are started I would expect that the
 simplicity of the non-threadsafe HashMap should have some benefit over
 CHM{whatever}, or it would have been removed already?


 Right, we should be able to tell whether that's worth doing with a pure 
 read
 test with a CHMV8 and a HashMap :)

 IFF you find out CHMV8 is as good as HashMap for read only, you have
 two options:
- ask the JDK team to drop the HashMap code as it's no longer needed
- fix your benchmark :-P

 In other words, I'd consider it highly surprising and suspicious
 (still interesting though!)

 It's not as surprising as you think.  On x86, volatile reads are the
 same as regular reads (not counting some possible reordering magic).  So
 if a CHM read is a hash, an array access, and a list traversal, and so
 is HM (and I believe this is true though I'd have to review the code
 again to be sure), I'd expect very similar execution performance on
 read.  I think some of the anti-collision features in V8 might come into
 play under some circumstances though which might affect performance in a
 negative way (wrt the constant big-O component) but overall in a
 positive way (by turning the linear big-O component into a logarithmic one).

 Thanks David. I know about the cost of a volatile read, what I'm referring to
 is that I would expect the non-concurrent Maps to generally contain some
 simpler code than a conccurrent one. If this was not the case,
 why would any JDK team maintain two different implementations?
 That's why I would consider it surprising if it turned out that the CHMV8 was
 superior over a regular one on all fronts: there certainly is some
 scenario in which the regular one would be a more appropriate choice,
 which directly proofs that blindly replacing all usages in a large project
 is not optimal. Of course, it might be close to optimal..

You are right, it is not superior on all fronts.  It is definitely 
similar in terms of read, but writes will have a substantially higher 
cost, involving (at the very least) multiple volatile writes which are 
orders of magnitude more expensive than normal writes (on Intel they 
have the costly impact of memory fence instructions).  So I don't think 
anyone will want to drop HashMap any time soon. :-)

-- 
- DML
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Re: [infinispan-dev] CHM or CHMv8?

2013-04-18 Thread David M. Lloyd 
On 04/18/2013 09:35 PM, Manik Surtani wrote:
 Guys,

 Based on some recent micro benchmarks I've been doing, I've seen:

 MapStressTest configuration: capacity 10, test running time 60 seconds
 Testing mixed read/write performance with capacity 100,000, keys 300,000, 
 concurrency level 32, threads 12, read:write ratio 0:1
 Container CHM   Ops/s 21,165,771.67  Gets/s   0.00  Puts/s 
 21,165,771.67  HitRatio 100.00  Size262,682  stdDev 77,540.73
 Container CHMV8 Ops/s 33,513,807.09  Gets/s   0.00  Puts/s 
 33,513,807.09  HitRatio 100.00  Size262,682  stdDev 77,540.73

 So under high concurrency (12 threads, on my workstation with 12 hardware 
 threads - so all threads are always working), we see that Infinispan's CHMv8 
 implementation is 50% faster than JDK6's CHM implementation when doing puts.

 We use a fair number of CHMs all over Infinispan's codebase.  By default, 
 these are all JDK-provided CHMs.  But we have the option to switch to our 
 CHMv8 implementation by passing in -Dinfinispan.unsafe.allow_jdk8_chm=true.

 The question is, should this be the default?  Thoughts, opinions?

The JDK's concurrency code - especially CHM - changes all the time. 
You'd be very well-served, in my opinion, to go with something like 
CHMv8 just because you could be so much more sure that you'll have more 
consistent (and possibly better, but definitely more consistent) 
performance across all JVMs, instead of being at the mercy of whatever 
particular implementation happens to run on whatever JVM.


-- 
- DML
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Re: [infinispan-dev] More verbose logging

2013-02-19 Thread David M. Lloyd 
This is one reason why I recommend logging using categories versus class 
names.  If you confine types of trace logging to specific categories 
which correspond to logical processes, then this allows the user to 
surgically select what information they wish to receive.  It is very 
often the case that one class is involved in several such logical processes.

On 02/19/2013 10:35 AM, Manik Surtani wrote:
 I also see this - 3 lines per segment, per cache!

 2013-02-19 16:22:13,990 TRACE [StateConsumerImpl] (OOB-1,ISPN,NodeB-11464) 
 Received keys [] for segment 0 of cache ___defaultcache from node NodeA-62578
 2013-02-19 16:22:13,990 DEBUG [StateConsumerImpl] (OOB-1,ISPN,NodeB-11464) 
 Finished applying state for segment 0 of cache ___defaultcache
 2013-02-19 16:22:13,991 DEBUG [StateConsumerImpl] (OOB-1,ISPN,NodeB-11464) 
 Applying new state for segment 1 of cache ___defaultcache from node 
 NodeA-62578: received 0 cache entries
 2013-02-19 16:22:13,991 TRACE [StateConsumerImpl] (OOB-1,ISPN,NodeB-11464) 
 Received keys [] for segment 1 of cache ___defaultcache from node NodeA-62578
 2013-02-19 16:22:13,991 DEBUG [StateConsumerImpl] (OOB-1,ISPN,NodeB-11464) 
 Finished applying state for segment 1 of cache ___defaultcache
 2013-02-19 16:22:13,992 DEBUG [StateConsumerImpl] (OOB-1,ISPN,NodeB-11464) 
 Applying new state for segment 2 of cache ___defaultcache from node 
 NodeA-62578: received 0 cache entries
 2013-02-19 16:22:13,992 TRACE [StateConsumerImpl] (OOB-1,ISPN,NodeB-11464) 
 Received keys [] for segment 2 of cache ___defaultcache from node NodeA-62578
 2013-02-19 16:22:13,992 DEBUG [StateConsumerImpl] (OOB-1,ISPN,NodeB-11464) 
 Finished applying state for segment 2 of cache ___defaultcache
 2013-02-19 16:22:13,992 DEBUG [StateConsumerImpl] (OOB-1,ISPN,NodeB-11464) 
 Applying new state for segment 3 of cache ___defaultcache from node 
 NodeA-62578: received 0 cache entries
 2013-02-19 16:22:13,993 TRACE [StateConsumerImpl] (OOB-1,ISPN,NodeB-11464) 
 Received keys [] for segment 3 of cache ___defaultcache from node NodeA-62578
 2013-02-19 16:22:13,993 DEBUG [StateConsumerImpl] (OOB-1,ISPN,NodeB-11464) 
 Finished applying state for segment 3 of cache ___defaultcache
 2013-02-19 16:22:13,993 DEBUG [StateConsumerImpl] (OOB-1,ISPN,NodeB-11464) 
 Applying new state for segment 4 of cache ___defaultcache from node 
 NodeA-62578: received 0 cache entries
 2013-02-19 16:22:13,993 TRACE [StateConsumerImpl] (OOB-1,ISPN,NodeB-11464) 
 Received keys [] for segment 4 of cache ___defaultcache from node NodeA-62578
 2013-02-19 16:22:13,994 DEBUG [StateConsumerImpl] (OOB-1,ISPN,NodeB-11464) 
 Finished applying state for segment 4 of cache ___defaultcache

 Another candidate for a -Dinfinispan.logging.verbose guard?

 - M


 On 19 Feb 2013, at 16:29, Manik Surtani msurt...@redhat.com wrote:

 Guys,

 I see this emitted by the CommandAwareRpcDispatcher:

 2013-02-19 16:22:13,988 TRACE [CommandAwareRpcDispatcher] 
 (OOB-1,ISPN,NodeB-11464) Attempting to execute command: 
 StateResponseCommand{cache=___defaultcache, origin=NodeA-62578, 
 topologyId=1, stateChunks=[StateChunk{segmentId=0, cacheEntries=[], 
 isLastChunk=true}, StateChunk{segmentId=1, cacheEntries=[], 
 isLastChunk=true}, StateChunk{segmentId=2, cacheEntries=[], 
 isLastChunk=true}, StateChunk{segmentId=3, cacheEntries=[], 
 isLastChunk=true}, StateChunk{segmentId=4, cacheEntries=[], 
 isLastChunk=true}, StateChunk{segmentId=5, cacheEntries=[], 
 isLastChunk=true}, StateChunk{segmentId=6, cacheEntries=[], 
 isLastChunk=true}, StateChunk{segmentId=7, cacheEntries=[], 
 isLastChunk=true}, StateChunk{segmentId=8, cacheEntries=[], 
 isLastChunk=true}, StateChunk{segmentId=9, cacheEntries=[], 
 isLastChunk=true}, StateChunk{segmentId=10, cacheEntries=[], 
 isLastChunk=true}, StateChunk{segmentId=11, cacheEntries=[], 
 isLastChunk=true}, StateChunk{segmentId=12, cacheEntries=[], 
 isLastChunk=true}!
 ,!
StateChunk{segmentId=13, cacheEntries=[], isLastChunk=true}, 
 StateChunk{segmentId=14, cacheEntries=[], isLastChunk=true}, 
 StateChunk{segmentId=15, cacheEntries=[], isLastChunk=true}, 
 StateChunk{segmentId=17, cacheEntries=[], isLastChunk=true}, 
 StateChunk{segmentId=16, cacheEntries=[], isLastChunk=true}, 
 StateChunk{segmentId=19, cacheEntries=[], isLastChunk=true}, 
 StateChunk{segmentId=18, cacheEntries=[], isLastChunk=true}, 
 StateChunk{segmentId=21, cacheEntries=[], isLastChunk=true}, 
 StateChunk{segmentId=20, cacheEntries=[], isLastChunk=true}, 
 StateChunk{segmentId=23, cacheEntries=[], isLastChunk=true}, 
 StateChunk{segmentId=22, cacheEntries=[], isLastChunk=true}, 
 StateChunk{segmentId=25, cacheEntries=[], isLastChunk=true}, 
 StateChunk{segmentId=24, cacheEntries=[], isLastChunk=true}, 
 StateChunk{segmentId=27, cacheEntries=[], isLastChunk=true}, 
 StateChunk{segmentId=26, cacheEntries=[], isLastChunk=true}, 
 StateChunk{segmentId=29, cacheEntries=[], isLastChunk=true}, StateChu!
 nk{!
   segmentId=28, cacheEntries=[], isLastChunk=true},

Re: [infinispan-dev] Avoid Collections.emptySet() / emptyMap() / emptyList

2012-10-22 Thread David M. Lloyd 
On 10/22/2012 01:41 AM, Galder Zamarreño wrote:

 On Oct 19, 2012, at 7:20 PM, David M. Lloyd david.ll...@redhat.com wrote:

 Also be aware that JBMAR has specific optimizations for the JDK empty
 collections - they are represented by a single byte in the stream.

 Well, it's actually 3 bytes that you use to represent empty collections (at 
 least in 1.3.15ga):

 write(ID_NEW_OBJECT);
 write(ID_CLASS_CLASS);
 write(classByte);

 Whereas with our externalizers, these get resolved via object writer (which 
 gets called before your code to detect empty collections) and it only writes 
 1 byte:

 write(externalizerId);

No, that's inaccurate; they are singletons and do not use ID_NEW_OBJECT. 
  They're done as instances so it is one of:

 public static final int ID_EMPTY_LIST_OBJECT= 0x5d;
 public static final int ID_EMPTY_SET_OBJECT = 0x62;
 public static final int ID_EMPTY_MAP_OBJECT = 0x69;

Your externalizers on the other hand take multiple bytes even in the 
simplest case.  If it is that important, you could use an ObjectResolver 
to swap in the JDK instance instead of using yet another externalizer 
(which has several bytes of overhead of its own).

-- 
- DML
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Re: [infinispan-dev] Avoid Collections.emptySet() / emptyMap() / emptyList

2012-10-19 Thread David M. Lloyd 
Also be aware that JBMAR has specific optimizations for the JDK empty 
collections - they are represented by a single byte in the stream.

On 10/19/2012 11:28 AM, Dan Berindei wrote:
 Galder, what JDK are you using? OpenJDK 1.7 uses
 EmptyIterator.EMPTY_ITERATOR since 2007:

 http://hg.openjdk.java.net/jdk7/jdk7/jdk/annotate/37a05a11f281/src/share/classes/java/util/Collections.java

 I don't have JDK 1.6 sources on hand to check, but I don't think it's
 worth optimizing for such an old version anyway.

 Cheers
 Dan


 On Fri, Oct 19, 2012 at 5:50 PM, Vladimir Blagojevic
 vblag...@redhat.com mailto:vblag...@redhat.com wrote:

 Cool! Did not know about this! Is this original idea or others are
 already doing this?
 On 12-10-19 8:31 AM, Galder Zamarreño wrote:
   Hi all,
  
   Re:
 
 https://github.com/galderz/infinispan/commit/0609207d13216de81d77ff51dc20652ce270c635
  
   Please avoid using these JDK methods where possible. I've created
 alternative versions in InfinispanCollections util class that
 provide a better implementation.
  
   The problem with the JDK versions is that even if these
 collections are immutable, if you wanna iterate them (i.e. for(X :
 emptySet) ), they'll create a brand new Iterator every time they're
 looped, and that generates useless garbage.
  
   The InfinispanCollections versions of emptyX will return a
 constant singleton iterator which avoids this problem, and avoids
 the need for client code to check if the collection is empty before
 looping.
  
   Cheers,
   --
   Galder Zamarreño
   gal...@redhat.com mailto:gal...@redhat.com
   twitter.com/galderz http://twitter.com/galderz
  
   Project Lead, Escalante
   http://escalante.io
  
   Engineer, Infinispan
   http://infinispan.org
  
  
   ___
   infinispan-dev mailing list
   infinispan-dev@lists.jboss.org
 mailto:infinispan-dev@lists.jboss.org
   https://lists.jboss.org/mailman/listinfo/infinispan-dev

 ___
 infinispan-dev mailing list
 infinispan-dev@lists.jboss.org mailto: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



-- 
- DML
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Re: [infinispan-dev] Double+ buffering during value marshalling

2012-08-28 Thread David M. Lloyd 
All I can contribute is that you cannot really avoid buffering in the 
marshaller, because for user data it uses constructs of the form:

   length content

You generally cannot know length without some form of buffering. 
There may be some optimizations which are possible that I haven't done 
yet, but I think as it is right now is pretty much how it'll stay for 
the near future at least.

On 08/20/2012 09:51 AM, Galder Zamarreño wrote:
 I don't really know tbh. More of a question for David.

 To provide more background info, we have MarshalledValue in:
 https://github.com/infinispan/infinispan/blob/master/core/src/main/java/org/infinispan/marshall/MarshalledValue.java

   It used to keep a byte[], but now we do some buffering in 
 ExpandableMarshalledValueByteStream 
 (https://github.com/infinispan/infinispan/blob/master/core/src/main/java/org/infinispan/io/ExpandableMarshalledValueByteStream.java)
  to be more efficient and avoid throwing away byte arrays, see 
 https://issues.jboss.org/browse/ISPN-2032

 What Sanne suggests is that we avoid double buffering in 
 ExpandableMarshalledValueByteStream and SimpleDataOutput (RiverMarshaller).

 There's a 1 to 1 mapping between the RiverMarshaller and the stream/buffer 
 passed to Marshalling.createByteOutput(), so I think there could be an option 
 where the stream passed is the actual buffer.

 @Sanne, did you see any particular performace impact in the profiler? Or just 
 noting it?

 Cheers,

 On Aug 13, 2012, at 6:22 PM, Manik Surtani wrote:

 Probably a question for David or Galder… but good detective work as always, 
 Sanne.

 On 11 Aug 2012, at 21:00, Sanne Grinovero sa...@infinispan.org wrote:

 While debugging around the Infinispan/JBMar integration I noticed that
 Infinispan defines in-memory buffers wrapped as byte streams, and uses
 JBoss Marshaller to write to these.

 JBoss Marshaller also buffers writes, and flushes when needed or on
 demand; I did already know of both, but just realized that these two
 levels of buffering are both applied when serializing instances in a
 org.infinispan.marshall.MarshalledValue; I guess we could do better
 avoiding buffering and have JBMAR write straight away? It would also
 mean less array resizing, as we are often able to allocate the right
 size in one shot.

 I gave a look into RiverMarshaller, and this didn't look like a simple
 task as _byte[] buffer_ is the main element around which most of the
 code revolves (in it's superclass SimpleDataOutput).

 I'm wondering if SimpleDataOutput wouldn't be simpler by just writing
 to a org.jboss.marshalling.ByteOutput (and have an optional buffering
 implementation), or if Infinispan should use River in a different way.

 Regards,
 Sanne
 ___
 infinispan-dev mailing list
 infinispan-dev@lists.jboss.org
 https://lists.jboss.org/mailman/listinfo/infinispan-dev

 --
 Manik Surtani
 ma...@jboss.org
 twitter.com/maniksurtani

 Founder and Project Lead, Infinispan
 http://www.infinispan.org

 Platform Architect, JBoss Data Grid
 http://red.ht/data-grid


 --
 Galder Zamarreño
 Sr. Software Engineer
 Infinispan, JBoss Cache



-- 
- DML


___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Re: [infinispan-dev] [jboss-as7-dev] AS7-4007 missing Infinispan dependency for clustered JPA second level cache

2012-03-06 Thread David M. Lloyd 
On 03/06/2012 01:02 PM, Galder Zamarreño wrote:
 On Mar 6, 2012, at 6:31 PM, Paul Ferraro wrote:
 - Original Message -
 From: Jason T. Greenejason.gre...@redhat.com
 To: David M. Lloyddavid.ll...@redhat.com
 Cc: Galder Zamarreñogal...@redhat.com, Paul 
 Ferraropferr...@redhat.com, Bela Banb...@redhat.com,
 infinispan -Dev Listinfinispan-dev@lists.jboss.org, 
 hibernate-...@lists.jboss.org,
 jboss-as7-...@lists.jboss.org Developmentjboss-as7-...@lists.jboss.org
 Sent: Tuesday, March 6, 2012 10:30:11 AM
 Subject: Re: [jboss-as7-dev] AS7-4007 missing Infinispan dependency for 
 clustered JPA second level cache

 On 3/6/12 9:28 AM, David M. Lloyd wrote:
 On 03/06/2012 09:21 AM, Galder Zamarreño wrote:
 This reminds me that we had a discussion about this a few months
 back: http://goo.gl/DJLhB

 At the time, it wasn't clear whether you can use
 ModularClassResolver in a non-module env. Seems like it's not
 possible.

 So, one option is to have a class resolver lookup class, or
 similar so that AS7 can pass us the right ClassResolver.

 There might a quicker option here though:
 - Extend VersionAwareMarshaller (http://goo.gl/bu8CF) and provide
 a variant of JBossMarshaller (http://goo.gl/o9Ro3) in Infinispan
 (this requires JBossMarshaller to be made non-final)
 - Override JBossMarshaller.inject(), call super.inject() and then
 call baseCfg.setClassResolver(…)
 - This would require that the VersionAwareMarshaller extension be
 passed the ModuleLoader that ModularClassResolver requires.
 - Configure Infinispan with this new marshaller, via
 SerializationConfiguration. Thankfully you can now pass an
 instance of the marshaller to it, so no need to do any magic
 ModuleLoader lookup from the VersionAwareMarshaller extension.

 Scott, other than the change in JBossMarshaller to be made
 non-final, the rest can built on AS7. Wanna have a go? Ping me on
 IRC if you need help.

 Cheers,

 p.s. Silly question, how come this issue is not present in HTTP
 session replication use case or EJB3 SFSB?

 It actually is present anywhere we're using Infinispan (I think).
 It
 just hasn't blown up yet anywhere public (in this case it's a 90%
 effective solution versus a 100% effective solution).

 Session replication does setup a custom marshaller, so it does in
 fact
 work. I think the issue is just that the hibernate-infinispan, which
 is
 part of the hibernate project set, and not AS code does not do this,
 and
 it doesn't expose a way to do it.

 Sort of...

 To summarize:
 The fundamental issue is that Infinispan uses the same marshaller instance 
 for all caches within a cache manager - which doesn't map cleanly to our use 
 case, which uses a cache instance per application - thus requires 
 cache-grained marshalling configuration.

 Well, this is not exactly correct since 5.0. Internally, we differentiate 
 between a global marshaller and a per-cache marshaller. What's the 
 difference? The classloader with which they're configured.

 Since 5.0, you can configure the classloader to use per cache. You can even 
 configure the classloader per invocation with cache.with(cl)….

 If that's not helping you, we were wasting our time when we did this...

Well :)  (see below)


 To work around this, we typically store MarshalledValues in the cache - 
 which are marshalled/unmarshalled using a marshalling configuration specific 
 to the application (e.g. via a ModularClassResolver using the ModuleLoader 
 of the deployment unit).
 https://github.com/jbossas/jboss-as/blob/master/clustering/api/src/main/java/org/jboss/as/clustering/MarshalledValue.java
 https://github.com/jbossas/jboss-as/blob/master/clustering/api/src/main/java/org/jboss/as/clustering/SimpleMarshalledValue.java
 https://github.com/jbossas/jboss-as/blob/master/clustering/api/src/main/java/org/jboss/as/clustering/HashableMarshalledValue.java

 Isn't a class resolver and a class loader, functionality wise, doing the same 
 thing? I wonder if a custom classloader could not be built that delegates to 
 a ModularClassResolver...

No, not really.  A class loader loads a class, given a name.  But a 
class resolver loads a class given a name *and* stream information.  The 
modular class resolver reads the stream information to know which class 
loader houses the class in question.  This is critically important 
because it's possible (common even) for more than one class to exist in 
an AS instance with the same name.  And there is no single class loader 
which has visibility to all classes which could potentially be stored in 
a cache.

Yes, accepting a class loader to use is a powerful feature.  However it 
*should* just be a convenience abstraction over a more fundamental 
feature which allows a class resolver to be set.

 So, essentially Infinispan itself only ever has to marshal/unmarshal a 
 byte[] wrapper - so the AS has full control over the marshalling process.

 I would recommend that the 2LC do something similar, and include a mechanism 
 for providing

Re: [infinispan-dev] [jboss-as7-dev] AS7-4007 missing Infinispan dependency for clustered JPA second level cache

2012-03-06 Thread David M. Lloyd 
On 03/06/2012 01:27 PM, Galder Zamarreño wrote:
 (***) I still don't fully understand how web apps don't have the same issue 
 as 2LC of not seeing Infinispan classes (Reminder: we're not talking about 
 the contents of the cache, but about the Infinispan classes themselves).

It's possible that someone saw the exception and said to themselves, 
oh... well I'll just add Infinispan to all web apps, and then the 
patch slipped by the code review process.  Other problems will continue 
to lurk beneath the surface though.

-- 
- DML
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Re: [infinispan-dev] JBoss Logging upgrade breaking build

2011-10-23 Thread David M. Lloyd 
On 10/23/2011 03:20 AM, Galder Zamarreño wrote:
 Hi,

 This JBoss Logging upgrade is rather annoying for a couple of
 reasons:

 1. IDE integration is broken: Before we had a JBoss Logging Processor
 as some dependency that allowed the logging processor to be found in
 the classpath. Now this is no longer in the classpath, so IntelliJ
 forces you to point to a jar. However, the new processing jar is
 split between two jars:
 ./jboss-logging-processor/1.0.0.CR3/jboss-logging-processor-1.0.0.CR3.jar
 and
 ./jboss-logging-generator/1.0.0.CR3/jboss-logging-generator-1.0.0.CR3.jar
 - And the generation won't work without both jars being pointed by
 the annotation processor. David, why did you split these jars?

We split the JARs at the request of the Seam Solder project who wanted
to reuse the generator.  It should however still work just fine if you 
add both JARs as provided dependencies; I haven't had a problem here, 
even with IDEA.

James and I have been discussing the ultimate wisdom of this strategy 
though.  We might consider re-merging the JARs if it proves to cause 
insurmountable issues (they aren't getting *that* much value from our 
code, really).  But I'm really surprised this is turning out to be a 
serious issue.

 2. It breaks our build, see
 https://infinispan.ci.cloudbees.com/job/Infinispan-master-JDK6-tcp/268/org.infinispan$infinispan-query/console
 - What are these errors about? And why is it an info it breaks the
 compilation? :) [INFO] diagnostic error: All message bundles and
 message logger messageMethods must have or inherit a message.

I've never seen this before.  Maybe this error is a result of extending 
the other message bundle interface, that isn't in the same artifact? 
We'll see about putting in some more tests for this case.

 What is wrong with
 https://github.com/infinispan/infinispan/blob/master/query/src/main/java/org/infinispan/query/logging/Log.java
 ?

 Cheers,

 p.s. We can we please test these upgrades throughfully before
 committing them? Thx :)

Of course we test, but of course things can be missed.  In particular 
I've integrated the new version with several projects without any issues.

-- 
- DML
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Re: [infinispan-dev] JBoss Logging upgrade breaking build

2011-10-23 Thread David M. Lloyd 
Okay, I've gotten to the root of the build issue.  If you update your 
jboss-logging to 3.1.0.Beta3, and do a clean rebuild, the problem should 
go away.

The issue was caused by me changing the retention on the annotations - 
cross-artifact interface hierarchies would stop working in this case.

On 10/23/2011 01:59 PM, David M. Lloyd wrote:
 On 10/23/2011 03:20 AM, Galder Zamarreño wrote:
 Hi,

 This JBoss Logging upgrade is rather annoying for a couple of
 reasons:

 1. IDE integration is broken: Before we had a JBoss Logging Processor
 as some dependency that allowed the logging processor to be found in
 the classpath. Now this is no longer in the classpath, so IntelliJ
 forces you to point to a jar. However, the new processing jar is
 split between two jars:
 ./jboss-logging-processor/1.0.0.CR3/jboss-logging-processor-1.0.0.CR3.jar
 and
 ./jboss-logging-generator/1.0.0.CR3/jboss-logging-generator-1.0.0.CR3.jar
 - And the generation won't work without both jars being pointed by
 the annotation processor. David, why did you split these jars?

 We split the JARs at the request of the Seam Solder project who wanted
 to reuse the generator.  It should however still work just fine if you
 add both JARs as provided dependencies; I haven't had a problem here,
 even with IDEA.

 James and I have been discussing the ultimate wisdom of this strategy
 though.  We might consider re-merging the JARs if it proves to cause
 insurmountable issues (they aren't getting *that* much value from our
 code, really).  But I'm really surprised this is turning out to be a
 serious issue.

 2. It breaks our build, see
 https://infinispan.ci.cloudbees.com/job/Infinispan-master-JDK6-tcp/268/org.infinispan$infinispan-query/console
 - What are these errors about? And why is it an info it breaks the
 compilation? :) [INFO] diagnostic error: All message bundles and
 message logger messageMethods must have or inherit a message.

 I've never seen this before.  Maybe this error is a result of extending
 the other message bundle interface, that isn't in the same artifact?
 We'll see about putting in some more tests for this case.

 What is wrong with
 https://github.com/infinispan/infinispan/blob/master/query/src/main/java/org/infinispan/query/logging/Log.java
 ?

 Cheers,

 p.s. We can we please test these upgrades throughfully before
 committing them? Thx :)

 Of course we test, but of course things can be missed.  In particular
 I've integrated the new version with several projects without any issues.



-- 
- DML
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Re: [infinispan-dev] Logger lookup performance

2011-08-08 Thread David M. Lloyd 
On 08/08/2011 05:06 AM, Sanne Grinovero wrote:
 Hi all,
 raising some attention here on Pete's suggestions;
 over the weekend we fixed this bootstrap performance issue ISPN-1315,
 which I had given the name Reduce number of Logger instances being
 created,
 after looking at this profiler screenshot:
 http://community.jboss.org/servlet/JiveServlet/showImage/2-619820-16841/hotspot.jpg

 Now Pete suggested that the JBoss Logging should return the same
 instance; TBH from the screenshot all we know is that
 LogFactory.getLog(Class) invocations are taking 280 seconds, so I
 guess they are actually returning always the same instance, but and
 likely the time is spent in finding it. I'll rename the issue.

JBoss Logging definitely *tries* to return the same logger but there's 
no guarantee that it can (depending on the log backend).  In any case 
though, it's definitely better to use static final loggers as you say; 
this advice applies to every log framework I know of, not just JBoss 
Logging.

If you _really_ want covariant loggers (which generally I disapprove of, 
btw) then use a protected method which returns a static final logger. 
Note that most of the time the reason people use covariant loggers is so 
that the category name can reflect the instance class name.  However, I 
recommend against this for various reasons.  If the user wants the 
logging class name they can add it to the format.  If the user wants the 
instance class name, it should be part of the log message.  The logger 
category should be named to reflect the task being performed, not a 
class name.

 IMO we should stick with static final loggers, unless there are
 special reasons (and then please add a comment to clarify it was an
 intentional choice).

Right on.

-- 
- DML
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Re: [infinispan-dev] New Logging rules!!! MUST READ

2011-06-28 Thread David M. Lloyd 
On 06/28/2011 06:31 AM, Galder Zamarreño wrote:

 On Jun 21, 2011, at 11:54 AM, Manik Surtani wrote:


 On 27 Apr 2011, at 14:18, Galder Zamarreño wrote:

 Please note as well that this might require some IDE settings changes. I 
 had to enable annotation processing in IntelliJ to be able to compile stuff 
 from IDE.

 Galder, do you have any instructions on these IDE settings?  Things work 
 fine from the command line, but the generated logger does not exist if I 
 build from an IDE.  I don't believe the annotation processor is being 
 invoked, or perhaps it is generating sources where the rest of the build 
 doesn't expect.

 True, I don't think it's generating the log implementations which makes tests 
 fail unless you've previously built from cmd line. I'll look into it.

 If David's listening, he might already have some tricks from the JBoss 
 Logging development work?

Sorry, I always build on the command line.  I know that IDEA can be 
configured because I have done it... once... in the distant past... but 
that's all I remember.
-- 
- DML
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Re: [infinispan-dev] Issue posted for JBoss Logging and slf4j

2011-06-20 Thread David M. Lloyd 
On 06/20/2011 04:16 PM, Thomas P. Fuller wrote:
 I've had an issue upgrading to CR5 and I was just about to ask about this.

 Basically when running infinispan CR5 in Grails I am seeing log messages
 repeated two times whereas before upgrading I'd only see one.

 This is not a showstopper, but it's a bit annoying. I'm also not sure if
 this is an Infinispan problem or a Grails problem, however this wasn't
 an issue until recently, which is why I suspect that JBoss Logging is at
 fault here.

Leaving aside the fact that this is basically a me too post which 
actually describes a completely different problem - can you give some 
specifics?  Like, what JARs are on your classpath where you see the 
problem?  Are all messages duplicated, or just Infinispan's?  What 
logging backend are you trying to use, and how is it configured?  What 
does the output actually look like, and what were you expecting?

-- 
- DML
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Re: [infinispan-dev] Issue posted for JBoss Logging and slf4j

2011-06-20 Thread David M. Lloyd 
Due to the lack of a logging backend JAR, I am assuming that you are 
using java.util.logging for your logging backend.  There is nothing in 
JBoss Logging which handles appenders or handlers or logs messages in a 
loop of any kind; thus I think the most likely situation is that there 
are multiple log backends being configured at a JUL level.  Apart from 
the obvious check the logging config file [1] [2], it's quite possible 
that one or more JARs on the classpath are helping you by configuring 
additional log handlers on JUL's root logger programmatically.  I can 
tell you that neither JBoss Logging nor JBoss Marshalling does this, but 
beyond that I cannot say.

[1] 
http://download.oracle.com/javase/1.4.2/docs/guide/util/logging/overview.html
[2] http://www.crazysquirrel.com/computing/java/logging.jspx

On 06/20/2011 05:33 PM, Thomas P. Fuller wrote:
 David,

 Leaving aside the fact that this is basically a me too post which
 actually describes a completely different problem - can you give some
 specifics?

 Note that the author of the email asked specifically the following question:

 Anybody else seeing a degradation in logging behavior?

 If you're an expert with the internals of JBoss Logging, then fine for
 you to categorize this as a different problem, but I am not and from my
 angle one user has a problem with JBoss Logging and so do I. It is
 perfectly conceivable that they could be related which is why I took the
 time to respond to this specific question.

 Now, moving on to your queries:

 Here are the list of Jars that are in the classpath:

 hibernate-commons-annotations-3.2.0.Final.jar
 hibernate-infinispan-3.6.4-20110430.213848-9.jar
 hibernate-search-3.4.0.Final.jar
 infinispan-core.jar
 infinispan-query.jar
 jboss-logging-3.0.0.Beta5.jar
 jboss-marshalling-1.3.0.CR9.jar
 jboss-marshalling-river-1.3.0.CR9.jar
 jboss-transaction-api-1.0.1.GA.jar
 jcip-annotations-1.0.jar
 jgroups-2.12.0.Final.jar
 lucene-core-3.2.0.jar
 readme.txt
 rhq-pluginAnnotations-3.0.1.jar

 Re: Are all messages duplicated, or just Infinispan's?

 All messages are duplicated, and I just wrote a quite test application
 in Grails in complete isolation and the log messages only appear once.

 Regards,

 Tom

 
 *From:* David M. Lloyd david.ll...@redhat.com
 *To:* infinispan-dev@lists.jboss.org
 *Sent:* Mon, 20 June, 2011 22:55:56
 *Subject:* Re: [infinispan-dev] Issue posted for JBoss Logging and slf4j

 On 06/20/2011 04:16 PM, Thomas P. Fuller wrote:
   I've had an issue upgrading to CR5 and I was just about to ask about
 this.
  
   Basically when running infinispan CR5 in Grails I am seeing log messages
   repeated two times whereas before upgrading I'd only see one.
  
   This is not a showstopper, but it's a bit annoying. I'm also not sure if
   this is an Infinispan problem or a Grails problem, however this wasn't
   an issue until recently, which is why I suspect that JBoss Logging is at
   fault here.

 Leaving aside the fact that this is basically a me too post which
 actually describes a completely different problem - can you give some
 specifics? Like, what JARs are on your classpath where you see the
 problem? Are all messages duplicated, or just Infinispan's? What
 logging backend are you trying to use, and how is it configured? What
 does the output actually look like, and what were you expecting?

 --
 - DML
 ___
 infinispan-dev mailing list
 infinispan-dev@lists.jboss.org mailto: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


-- 
- DML
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Re: [infinispan-dev] Failure looking up the river marshaller under AS 7 environment

2011-05-31 Thread David M. Lloyd 
Easiest solution is:

Marshalling.getProvidedMarshallerFactory(river);

This will always use the JBMAR class loader.  Otherwise you would have 
to make sure that the module from which you load the river protocol 
imports the river module like this:
dependencies
   ...
   module name=org.jboss.marshalling.river services=import/
   ...
/dependencies

... and then use your own class loader.

On 05/31/2011 10:13 AM, Galder Zamarreño wrote:
 The marshaller is a global component, so it'd have to be at the 
 GlobalConfiguration.

 Let's bounce some ideas tomorrow on IRC.

 On May 31, 2011, at 5:07 PM, 이희승 (Trustin Lee) wrote:

 The problem is that the marshaller lookup code exists in Infinispan
 unlike other subsystems.  We need to make it configurable.  Where would
 be the best place to expose the property in Infinispan?  For
 EmbeddedCachaManager, it is so simple because we have Configuration and
 GlobalConfiguration, but I'm not sure about the others.

 On 05/31/2011 11:38 PM, Galder Zamarreño wrote:
 In fact, a quick grep on AS7 shows:

 ./host-controller/src/main/java/org/jboss/as/host/controller/ManagedServer.java:
 MARSHALLER_FACTORY = Marshalling.getMarshallerFactory(river, 
 Module.getModuleFromCallerModuleLoader(ModuleIdentifier.fromString(org.jboss.marshalling.river)).getClassLoader());
 ./protocol/src/main/java/org/jboss/as/protocol/ProtocolUtils.java:
 MARSHALLER_FACTORY = Marshalling.getMarshallerFactory(river, 
 ProtocolUtils.class.getClassLoader());
 ./server/src/main/java/org/jboss/as/server/DomainServerMain.java:
 final MarshallerFactory factory = Marshalling.getMarshallerFactory(river, 
 DomainServerMain.class.getClassLoader());

 We might need different mechanisms depending on the env.

 On May 31, 2011, at 11:28 AM, Galder Zamarreño wrote:

 They're in diff jars and most likely in different JBoss Modules.

 Trustin, AS7 uses JBoss Marshalling, so maybe have a look in their code to 
 see how they instantiate the marshaller factory - that might give you the 
 clues here :)

 Cheers,

 On May 31, 2011, at 10:20 AM, Dan Berindei wrote:

 We don't use the TCCL to load the MarshallerFactory:

  factory = Marshalling.getMarshallerFactory(river,
 Marshalling.class.getClassLoader());

 Maybe the Marshalling class and the RiverMarshallerFactory classes are
 in different modules?

 Dan


 On Tue, May 31, 2011 at 10:14 AM, 이희승 (Trustin Lee)trus...@gmail.com  
  wrote:
 Hi folks,

 I'm trying to run Infinispan under AS 7 (i.e. JBoss Modules).  I
 succeeded to run an EmbeddedCacheManager, HotRodServer, and
 MemcachedServer.  However, it fails when a new node joins the cluser:

 http://pastebin.com/pGfxSWJP

 The root cause of the failure is that GenericJBossMarshaller fails to
 find the RiverMarshallerFactory.  So, I set the TCCL, but it didn't help
 at all.  Even setting the TCCL to
 RiverMarshallerFactory.class.getClassLoader() doesn't seem to help.  Any
 clues?

 Cheers

 --
 Trustin Lee, http://gleamynode.net/
 ___
 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

 --
 Galder Zamarreño
 Sr. Software Engineer
 Infinispan, JBoss Cache


 ___
 infinispan-dev mailing list
 infinispan-dev@lists.jboss.org
 https://lists.jboss.org/mailman/listinfo/infinispan-dev

 --
 Galder Zamarreño
 Sr. Software Engineer
 Infinispan, JBoss Cache


 ___
 infinispan-dev mailing list
 infinispan-dev@lists.jboss.org
 https://lists.jboss.org/mailman/listinfo/infinispan-dev


 --
 Trustin Lee, http://gleamynode.net/
 ___
 infinispan-dev mailing list
 infinispan-dev@lists.jboss.org
 https://lists.jboss.org/mailman/listinfo/infinispan-dev

 --
 Galder Zamarreño
 Sr. Software Engineer
 Infinispan, JBoss Cache


 ___
 infinispan-dev mailing list
 infinispan-dev@lists.jboss.org
 https://lists.jboss.org/mailman/listinfo/infinispan-dev


-- 
- DML
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Re: [infinispan-dev] Failure looking up the river marshaller under AS 7 environment

2011-05-31 Thread David M. Lloyd 
This issue is caused by users who put a writeObject() or readObject() 
method on their class, and never write/read the class' serializable 
fields.  This is a violation of spec [2][3] which causes undefined 
behavior in some cases and thus it has always been forbidden with JBMAR.

However, it has been pointed out that a lot of classes actually rely on 
the specific behavior of the Sun JDK (which is to read/write fields in 
the default way and hope for the best), hence I have a JIRA issue [1] 
which is not yet resolved.

Unfortunately I don't currently have time to devote to this and won't 
for a while.  If anyone is sufficiently annoyed by this that they want 
to volunteer to fix it, I can walk someone through the code and test suite.

[1] https://issues.jboss.org/browse/JBMAR-120
[2] 
http://download.oracle.com/javase/6/docs/platform/serialization/spec/output.html#861
[3] 
http://download.oracle.com/javase/6/docs/platform/serialization/spec/input.html#2971

On 05/31/2011 10:39 PM, 이희승 (Trustin Lee) wrote:
 With Marshalling.getProvidedMarshallerFactory(), I was able to look up
 the RiverMarshallerFactory.  However, another exception is raised while
 exchanging the topology view (java.io.NotActiveException: Fields were
 never written):

   http://pastebin.com/5zVj2FwG

 It seems like it has a problem with marshalling an ImmortalCacheEntry?

 On 06/01/2011 11:38 AM, 이희승 (Trustin Lee) wrote:
 Using Marshalling.getProvidedMarshallerFactory() sounds like a better
 solution. Let me create a JIRA issue and send a pull request soon.

 On 06/01/2011 01:47 AM, David M. Lloyd wrote:
 Easiest solution is:

 Marshalling.getProvidedMarshallerFactory(river);

 This will always use the JBMAR class loader. Otherwise you would have
 to make sure that the module from which you load the river protocol
 imports the river module like this:
 dependencies
 ...
 module name=org.jboss.marshalling.river services=import/
 ...
 /dependencies

 ... and then use your own class loader.

 On 05/31/2011 10:13 AM, Galder Zamarreño wrote:
 The marshaller is a global component, so it'd have to be at the
 GlobalConfiguration.

 Let's bounce some ideas tomorrow on IRC.

 On May 31, 2011, at 5:07 PM, 이희승 (Trustin Lee) wrote:

 The problem is that the marshaller lookup code exists in Infinispan
 unlike other subsystems. We need to make it configurable. Where would
 be the best place to expose the property in Infinispan? For
 EmbeddedCachaManager, it is so simple because we have Configuration and
 GlobalConfiguration, but I'm not sure about the others.

 On 05/31/2011 11:38 PM, Galder Zamarreño wrote:
 In fact, a quick grep on AS7 shows:

 ./host-controller/src/main/java/org/jboss/as/host/controller/ManagedServer.java:
 MARSHALLER_FACTORY = Marshalling.getMarshallerFactory(river,
 Module.getModuleFromCallerModuleLoader(ModuleIdentifier.fromString(org.jboss.marshalling.river)).getClassLoader());

 ./protocol/src/main/java/org/jboss/as/protocol/ProtocolUtils.java:
 MARSHALLER_FACTORY = Marshalling.getMarshallerFactory(river,
 ProtocolUtils.class.getClassLoader());
 ./server/src/main/java/org/jboss/as/server/DomainServerMain.java:
 final MarshallerFactory factory =
 Marshalling.getMarshallerFactory(river,
 DomainServerMain.class.getClassLoader());

 We might need different mechanisms depending on the env.

 On May 31, 2011, at 11:28 AM, Galder Zamarreño wrote:

 They're in diff jars and most likely in different JBoss Modules.

 Trustin, AS7 uses JBoss Marshalling, so maybe have a look in their
 code to see how they instantiate the marshaller factory - that
 might give you the clues here :)

 Cheers,

 On May 31, 2011, at 10:20 AM, Dan Berindei wrote:

 We don't use the TCCL to load the MarshallerFactory:

 factory = Marshalling.getMarshallerFactory(river,
 Marshalling.class.getClassLoader());

 Maybe the Marshalling class and the RiverMarshallerFactory
 classes are
 in different modules?

 Dan


 On Tue, May 31, 2011 at 10:14 AM, 이희승 (Trustin
 Lee)trus...@gmail.com  wrote:
 Hi folks,

 I'm trying to run Infinispan under AS 7 (i.e. JBoss Modules). I
 succeeded to run an EmbeddedCacheManager, HotRodServer, and
 MemcachedServer. However, it fails when a new node joins the
 cluser:

 http://pastebin.com/pGfxSWJP

 The root cause of the failure is that GenericJBossMarshaller
 fails to
 find the RiverMarshallerFactory. So, I set the TCCL, but it
 didn't help
 at all. Even setting the TCCL to
 RiverMarshallerFactory.class.getClassLoader() doesn't seem to
 help. Any
 clues?

 Cheers

 --
 Trustin Lee, http://gleamynode.net/
 ___
 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

 --
 Galder Zamarreño
 Sr. Software Engineer
 Infinispan, JBoss Cache

Re: [infinispan-dev] [Pull Request] Modular Classloading Compatibility

2011-05-05 Thread David M. Lloyd 
On 05/05/2011 10:49 AM, David Bosschaert wrote:
 On 05/05/2011 10:55, Pete Muir wrote:
 I talked about this with Emmanuel last night, and we were

 a) concerned about the pollution of the API that this implies
 b) not sure why we need to do this

 So I also spoke to Jason to understand his initial motivation, and from this 
 chat I think it's clear that things have gone off course here.

 Jason raised two issues with modularity/classloading in Infinispan:

 1) Using the TCCL as the classloader to load Infinispan classes is a bad 
 idea. Instead we should use 
 org.infinispan.foo.Bar.getClass().getClassLoader().

 2) When we need to load application classes we need a different approach to 
 that used today. Most of the time the TCCL is perfect for this. However 
 *sometimes* Infinispan may be invoked outside of the application, when the 
 TCCL may not be set in AS7. Jason and I discussed three options:

 a) require (through a platform integration documentation contract) that the 
 TCCL must always be set when Infinispan is invoked.
 b) Have some sort of InvocationContext which knows what the correct 
 classloader to use is (aka Hibernate/Seam/Weld design where there is a 
 per-application construct based on a ThreadLocal). Given this hasn't been 
 designed into the core, it seems like a large retrofit
 c) Make users specify the CL (directly or indirectly) via the API (as we 
 discussed).

 Personally I think that (a) is the best approach right now, and is not that 
 onerous a requirement.

 We might want to make the TCCL usage pluggable for OSGI envs. Cc'd David to 
 get his feedback.

 In a sense a) and c) are similar. The only difference is the way you
 provide the classloader.

 OSGi doesn't specify the value of the Thread Context Classloader,
 primarily because it allows the creation of threads in your own code so
 OSGi can't control the value of the TCCL in those threads.

 a) Would be okay for OSGi as long as it's clearly documented. People
 would have to write code to set the TCCL before they call infinispan and
 then unset if afterwards. It requires a try/finally block which isn't
 fun to write and its a little verbose, but you can do it.

I don't know if OSGi is compatible with security managers, but this also 
has the added annoyance of potentially requiring privileged blocks in 
this case.

 c) Would be more user-friendly to OSGi users. It's easy to obtain the
 classloader of a bundle in OSGi so passing that in would be nice and easy.

 I guess you could consider providing both a) and c) at the same time, c)
 being simply an additional overload on the APIs so that people can
 choose whichever option they like best...

I like (c) better as well - I agree, doing both would be nicest.
-- 
- DML
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Re: [infinispan-dev] [Pull Request] Modular Classloading Compatibility

2011-05-03 Thread David M. Lloyd 
On 05/03/2011 12:41 PM, Pete Muir wrote:

 On 2 May 2011, at 10:10, Manik Surtani wrote:


 On 1 May 2011, at 13:38, Pete Muir wrote:

 As in, user API?  That's a little intrusive... e.g., put(K, V, cl) ?

 Not for put, since you have the class, just get, and I was thinking
 something more like:

 Foo foo = getUsing(key, Foo.class)

 This would be a pretty useful addition to the API anyway to avoid user 
 casts.

 Maybe as an advanced API, so as not to pollute the basic API?  A bit like:

 Foo f = cache.getAdvancedCache().asClass(Foo.class).get(key);


 I don't get why you need the asClass() (or any other method call in here), 
 just declare a method

 T  T get(key, Value.class);

 surely?

Yeah I agree, an asClass() method means an intermediate object and extra 
step which is a little clunky.  Adding one method doesn't hurt.

I'd like to see what the unmarshalling logic for this will look like - 
it is a novel and interesting, yet simple, solution; my favorite kind. :)
-- 
- DML
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Re: [infinispan-dev] cache name in logs

2011-04-29 Thread David M. Lloyd 
I would just use NDC or MDC honestly.

NDC.push(cacheName);
try {
do user stuff;
} finally {
NDC.pop();
}

Similar if you want to use an MDC key.

On 04/29/2011 09:55 AM, Galder Zamarreño wrote:

 On Apr 28, 2011, at 11:47 PM, Manik Surtani wrote:

 We do now support JBoss Logging.

 https://issues.jboss.org/browse/ISPN-380

 @Galder, does JBoss Logging have support for what Mircea mentioned below?

 I've skimmed through the javadoc but didn't see anything in particular for 
 this at least around the message loggers which are the ones that help with 
 internationalization.

 I think it could be fitted but would require a fair amount of changes, such 
 as making some static loggers, particularly those for named cache components 
 non static in order to take the cache name. Maybe you could have a named 
 cache component for a log factory?

 The other potential can of worms here is when multiple cache managers are in 
 action (i.e. managed environments) and you have multiple cache managers with 
 same cache names. You could end up having to put cache manager as well and 
 this could get too verbose. It could maybe be configurable somehow.

 David, any other ideas?


 On 27 Apr 2011, at 13:21, Olaf Bergner wrote:

 Silly me, forgot the link: http://logback.qos.ch/manual/mdc.html.

 Am 27.04.11 16:55, schrieb Mircea Markus:
 Hi,

 I'm looking into some logs for the a JBW demo : it has 4 caches deployed 
 on each node and lots of topology changes happen. It's close to impossible 
 to tell  which log pertains to which cache, especially around the 
 DistributionInterceptorImpl.
 Wouldn't it make sense that, for certain components, to include the name 
 of the cache in the logs? IThis might be achieved with minimal changes by 
 adding an additional param to the LogFactory.getLog(Class) method and let 
 the logger itself do the heavy lifting.
 e.g.
 Log l = LogFactory.getLog(DistributionManagerImpl.class, cacheName);
 and on each call l.trace(A message) the logger might output, besides 
 underlying log's format, the string [cacheName] A message.

 Wdyt?
 Cheers,
 Mircea
 ___
 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

 --
 Manik Surtani
 ma...@jboss.org
 twitter.com/maniksurtani

 Lead, Infinispan
 http://www.infinispan.org



 ___
 infinispan-dev mailing list
 infinispan-dev@lists.jboss.org
 https://lists.jboss.org/mailman/listinfo/infinispan-dev

 --
 Galder Zamarreño
 Sr. Software Engineer
 Infinispan, JBoss Cache



-- 
- DML
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Re: [infinispan-dev] @Marshallable as an option for end user externalizers?

2011-03-17 Thread David M. Lloyd 
On 03/17/2011 05:43 AM, Manik Surtani wrote:

 On 17 Mar 2011, at 08:30, Galder Zamarreño wrote:


 Is it to do with classloader leaks?  If so, a weak map could be
 used for this table...

 You misunderstood what I meant. By annotation scanning I meant that
 we won't be scanning the entire classpath for user classes that
 have @Marshaller, right? I mean, we don't do like an EJB container
 that goes through deployments checking for all @EJB classes, cos
 that would be very expensive and it's not our business. So, back to
 my question, the users will still need to give us the list of user
 defined externalizers. Sure, we can do annotation scanning on that
 specific list of classes.

 Ah I see what you mean.  Initially I thought you'd only need to
 register the externaliser when you first encounter a new type (i.e.,
 when a user defined type is first encountered with a put()), but this
 may not be the case since on the remote node it may see the a new
 magic number which may not be registered, and then you have a
 problem.

Marshalling will send Externalizers across the wire too, so the
receiving side need not know about it in advance.  The sending side can
then do this kind of discovery safely.  In addition, JBMAR already has
the @org.jboss.marshalling.Externalize annotation which does just this.

Unless you're talking about your own mechanism, anyway.  Just thought 
I'd throw this bit out there.


 My point is that it might look nice that users can use annotations
 to define some externalizer properties (id and typeClasses) but
 they're not getting as much out of it as they'd with @EJBs in an
 EJB container cos they have to list the externalizers somehow.
 Again, unless you wanna get into classpath annotation search...

 Yeah CP scanning does suck, but it is something to think about.
 Maybe follow a SEAM-like approach and only scan jars that have a
 certain file present in its META-INF?  WDYT?

 Cheers Manik

 -- Manik Surtani ma...@jboss.org twitter.com/maniksurtani

 Lead, Infinispan http://www.infinispan.org




 ___ infinispan-dev
 mailing list infinispan-dev@lists.jboss.org
 https://lists.jboss.org/mailman/listinfo/infinispan-dev


-- 
- DML
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

[infinispan-dev] Marshaller implementation discovery

2010-12-27 Thread David M. Lloyd 
Sanne Grinovero asked me to drop a quick note about the API used to 
discover JBoss Marshalling implementations.  Since 1.2.0.GA, you can use 
the org.jboss.marshalling.Marshalling class methods to locate protocol 
implementations without involving a hard dependency in your sources.

I've heard that Infinispan uses this pattern to load the implementation 
class:

(MarshallerFactory) 
Thread.currentThread().getContextClassLoader().loadClass(org.jboss.marshalling.river.RiverMarshallerFactory).newInstance();

This is a bit kludgey though and is considerably more complex than just 
doing:

Marshaller.getMarshallerFactory(river);

which uses the java.util.ServiceLoader API to locate and instantiate the 
appropriate implementation class, also using the TCCL, and should be 
functionally equivalent (yet quite a bit cleaner) to the former.
-- 
- DML
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev