Re: [infinispan-dev] JBoss Common Core as core dependency?
by Pete Muir
My rule for library/framework development has always been that you should use at least 20% of a dependencies functionality if you want to add it as a dependency (rather than just copy the source to your code base). If you are using >50% you should add it, no question, and in between you have to make a decision case-by-case. So I definitely think this is a good idea.
Though of course I think we should put it in a distinct package :-)
On 24 Jan 2011, at 13:52, Galder Zamarreño wrote:
> Hi all,
>
> Looking at Infinispan's dependencies, core seems to depend on JBoss Common Core simply to take advantage of org.jboss.util.StringPropertyReplacer.
>
> Test code also depends for org.jboss.util.naming.NonSerializableFactory.
>
> What about we make our own org.jboss.util.StringPropertyReplacer and remove JBoss Common Core from being a main dependency? We could still keep it as a test dependency for org.jboss.util.naming.NonSerializableFactory.
>
> Cheers,
> --
> Galder Zamarreño
> Sr. Software Engineer
> Infinispan, JBoss Cache
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
13 years, 3 months
JBoss Common Core as core dependency?
by Galder Zamarreño
Hi all,
Looking at Infinispan's dependencies, core seems to depend on JBoss Common Core simply to take advantage of org.jboss.util.StringPropertyReplacer.
Test code also depends for org.jboss.util.naming.NonSerializableFactory.
What about we make our own org.jboss.util.StringPropertyReplacer and remove JBoss Common Core from being a main dependency? We could still keep it as a test dependency for org.jboss.util.naming.NonSerializableFactory.
Cheers,
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
13 years, 3 months
Concurrency problem on org.infinispan.transaction.xa.TransactionTable
by Sebastiano Peluso
Hi all!
We are Diego and Sebastiano and we are working in the Cloud-TM project;
in particular we are focusing on designing new replication schemes in
Infinispan. During our code inspection we have noted that Infinispan can
suffer from a concurrency issue: multiple threads in execution on the
same local cache instance can access without any synchronization scheme
on a org.infinispan.transaction.xa.TransactionTable's field named
localTransactions; the problem is that the aforementioned
localTransactions field is an instance of HashMap, which isn't
thread-safe. We have noticed the problem during some intensive tests
(executed with a version of RadarGun modified by us in order to enable
transactions executions) which stressed heavily the cache with
concurrent threads: in some cases all threads on some nodes blocked in
an infinite loop on a get() operation on the aforementioned HashMap
instance.
We attach the dump relevant to a single blocked node and you can note
that each thread, namely a Stresser, is blocked on the get() operation.
We have noted the same concurrency problem on the field
remoteTransactions in the same object.
To partially validate our hypothesis we have replaced the type HashMap
with ConcurrentHashMap and everithing works fine.
What is your opinion about this?
Best regards
Diego, Sebastiano
"Stresser-7" prio=10 tid=0x00007fb2c0295000 nid=0x5bd3 runnable
[0x00007fb2c6bea000]
java.lang.Thread.State: RUNNABLE
at java.util.HashMap.get(HashMap.java:303)
at
org.infinispan.transaction.xa.TransactionTable.getXaCacheAdapter(TransactionTable.java:222)
at
org.infinispan.context.InvocationContextContainerImpl.createInvocationContext(InvocationContextContainerImpl.java:67)
at
org.infinispan.CacheDelegate.getInvocationContext(CacheDelegate.java:285)
at org.infinispan.CacheDelegate.get(CacheDelegate.java:199)
at
org.radargun.cachewrappers.InfinispanWrapper.get(InfinispanWrapper.java:99)
at
org.radargun.stressors.PutGetStressor$Stresser.run(PutGetStressor.java:367)
"Stresser-6" prio=10 tid=0x00007fb2c0293000 nid=0x5bd2 runnable
[0x00007fb2c6ceb000]
java.lang.Thread.State: RUNNABLE
at java.util.HashMap.get(HashMap.java:303)
at
org.infinispan.transaction.xa.TransactionTable.getXaCacheAdapter(TransactionTable.java:222)
at
org.infinispan.context.InvocationContextContainerImpl.createInvocationContext(InvocationContextContainerImpl.java:67)
at
org.infinispan.CacheDelegate.getInvocationContext(CacheDelegate.java:285)
at org.infinispan.CacheDelegate.get(CacheDelegate.java:199)
at
org.radargun.cachewrappers.InfinispanWrapper.get(InfinispanWrapper.java:99)
at
org.radargun.stressors.PutGetStressor$Stresser.run(PutGetStressor.java:367)
"Stresser-5" prio=10 tid=0x00007fb2c0292000 nid=0x5bd1 runnable
[0x00007fb2c6dec000]
java.lang.Thread.State: RUNNABLE
at java.util.HashMap.get(HashMap.java:303)
at
org.infinispan.transaction.xa.TransactionTable.getXaCacheAdapter(TransactionTable.java:222)
at
org.infinispan.context.InvocationContextContainerImpl.createInvocationContext(InvocationContextContainerImpl.java:67)
at
org.infinispan.CacheDelegate.getInvocationContext(CacheDelegate.java:285)
at org.infinispan.CacheDelegate.get(CacheDelegate.java:199)
at
org.radargun.cachewrappers.InfinispanWrapper.get(InfinispanWrapper.java:99)
at
org.radargun.stressors.PutGetStressor$Stresser.run(PutGetStressor.java:367)
"Stresser-4" prio=10 tid=0x00007fb2c0291800 nid=0x5bd0 runnable
[0x00007fb2c77f6000]
java.lang.Thread.State: RUNNABLE
at java.util.HashMap.get(HashMap.java:303)
at
org.infinispan.transaction.xa.TransactionTable.getXaCacheAdapter(TransactionTable.java:222)
at
org.infinispan.context.InvocationContextContainerImpl.createInvocationContext(InvocationContextContainerImpl.java:67)
at
org.infinispan.CacheDelegate.getInvocationContext(CacheDelegate.java:285)
at org.infinispan.CacheDelegate.get(CacheDelegate.java:199)
at
org.radargun.cachewrappers.InfinispanWrapper.get(InfinispanWrapper.java:99)
at
org.radargun.stressors.PutGetStressor$Stresser.run(PutGetStressor.java:367)
"Stresser-3" prio=10 tid=0x00007fb2c0290800 nid=0x5bcf runnable
[0x00007fb2c78f7000]
java.lang.Thread.State: RUNNABLE
at java.util.HashMap.get(HashMap.java:303)
at
org.infinispan.transaction.xa.TransactionTable.getXaCacheAdapter(TransactionTable.java:222)
at
org.infinispan.context.InvocationContextContainerImpl.createInvocationContext(InvocationContextContainerImpl.java:67)
at
org.infinispan.CacheDelegate.getInvocationContext(CacheDelegate.java:285)
at org.infinispan.CacheDelegate.get(CacheDelegate.java:199)
at
org.radargun.cachewrappers.InfinispanWrapper.get(InfinispanWrapper.java:99)
at
org.radargun.stressors.PutGetStressor$Stresser.run(PutGetStressor.java:367)
"Stresser-2" prio=10 tid=0x00007fb2c0044000 nid=0x5bce runnable
[0x00007fb2c76f5000]
java.lang.Thread.State: RUNNABLE
at java.util.HashMap.get(HashMap.java:303)
at
org.infinispan.transaction.xa.TransactionTable.getXaCacheAdapter(TransactionTable.java:222)
at
org.infinispan.context.InvocationContextContainerImpl.createInvocationContext(InvocationContextContainerImpl.java:67)
at
org.infinispan.CacheDelegate.getInvocationContext(CacheDelegate.java:285)
at org.infinispan.CacheDelegate.get(CacheDelegate.java:199)
at
org.radargun.cachewrappers.InfinispanWrapper.get(InfinispanWrapper.java:99)
at
org.radargun.stressors.PutGetStressor$Stresser.run(PutGetStressor.java:367)
"Stresser-1" prio=10 tid=0x00007fb2c0043000 nid=0x5bcd runnable
[0x00007fb2c74f3000]
java.lang.Thread.State: RUNNABLE
at java.util.HashMap.get(HashMap.java:303)
at
org.infinispan.transaction.xa.TransactionTable.getXaCacheAdapter(TransactionTable.java:222)
at
org.infinispan.context.InvocationContextContainerImpl.createInvocationContext(InvocationContextContainerImpl.java:67)
at
org.infinispan.CacheDelegate.getInvocationContext(CacheDelegate.java:285)
at org.infinispan.CacheDelegate.get(CacheDelegate.java:199)
at
org.radargun.cachewrappers.InfinispanWrapper.get(InfinispanWrapper.java:99)
at
org.radargun.stressors.PutGetStressor$Stresser.run(PutGetStressor.java:367)
"Stresser-0" prio=10 tid=0x00007fb2c0048000 nid=0x5bcc runnable
[0x00007fb2c75f4000]
java.lang.Thread.State: RUNNABLE
at java.util.HashMap.get(HashMap.java:303)
at
org.infinispan.transaction.xa.TransactionTable.getXaCacheAdapter(TransactionTable.java:222)
at
org.infinispan.context.InvocationContextContainerImpl.createInvocationContext(InvocationContextContainerImpl.java:67)
at
org.infinispan.CacheDelegate.getInvocationContext(CacheDelegate.java:285)
at org.infinispan.CacheDelegate.get(CacheDelegate.java:199)
at
org.radargun.cachewrappers.InfinispanWrapper.get(InfinispanWrapper.java:99)
at
org.radargun.stressors.PutGetStressor$Stresser.run(PutGetStressor.java:367)
13 years, 3 months
Re: [infinispan-dev] Concurrency problem on org.infinispan.transaction.xa.TransactionTable
by Erik Salter
Hi guys,
What ISPN version are you using? The 4.2.1.CR1 branch and the main branch both use a ConcurrentHashMap for local and remote transactions.
(Apologies if this has already been answered)
Regards,
Erik
-----Original Message-----
From: infinispan-dev-bounces(a)lists.jboss.org [mailto:infinispan-dev-bounces@lists.jboss.org] On Behalf Of Sebastiano Peluso
Sent: Thursday, January 20, 2011 2:07 PM
To: infinispan -Dev List
Subject: Re: [infinispan-dev] Concurrency problem on org.infinispan.transaction.xa.TransactionTable
Il 20/01/11 18:45, Sebastiano Peluso ha scritto:
> Hi all!
> We are Diego and Sebastiano and we are working in the Cloud-TM
> project; in particular we are focusing on designing new replication
> schemes in Infinispan. During our code inspection we have noted that
> Infinispan can suffer from a concurrency issue: multiple threads in
> execution on the same local cache instance can access without any
> synchronization scheme on a
> org.infinispan.transaction.xa.TransactionTable's field named
> localTransactions; the problem is that the aforementioned
> localTransactions field is an instance of HashMap, which isn't
> thread-safe. We have noticed the problem during some intensive tests
> (executed with a version of RadarGun modified by us in order to enable
> transactions executions) which stressed heavily the cache with
> concurrent threads: in some cases all threads on some nodes blocked in
> an infinite loop on a get() operation on the aforementioned HashMap instance.
> We attach the dump relevant to a single blocked node and you can note
> that each thread, namely a Stresser, is blocked on the get() operation.
> We have noted the same concurrency problem on the field
> remoteTransactions in the same object.
> To partially validate our hypothesis we have replaced the type HashMap
> with ConcurrentHashMap and everithing works fine.
> What is your opinion about this?
>
> Best regards
> Diego, Sebastiano
>
>
>
>
>
> "Stresser-7" prio=10 tid=0x00007fb2c0295000 nid=0x5bd3 runnable
> [0x00007fb2c6bea000]
> java.lang.Thread.State: RUNNABLE
> at java.util.HashMap.get(HashMap.java:303)
> at
> org.infinispan.transaction.xa.TransactionTable.getXaCacheAdapter(TransactionTable.java:222)
> at
> org.infinispan.context.InvocationContextContainerImpl.createInvocationContext(InvocationContextContainerImpl.java:67)
> at
> org.infinispan.CacheDelegate.getInvocationContext(CacheDelegate.java:285)
> at org.infinispan.CacheDelegate.get(CacheDelegate.java:199)
> at
> org.radargun.cachewrappers.InfinispanWrapper.get(InfinispanWrapper.java:99)
> at
> org.radargun.stressors.PutGetStressor$Stresser.run(PutGetStressor.java
> :367)
>
> "Stresser-6" prio=10 tid=0x00007fb2c0293000 nid=0x5bd2 runnable
> [0x00007fb2c6ceb000]
> java.lang.Thread.State: RUNNABLE
> at java.util.HashMap.get(HashMap.java:303)
> at
> org.infinispan.transaction.xa.TransactionTable.getXaCacheAdapter(TransactionTable.java:222)
> at
> org.infinispan.context.InvocationContextContainerImpl.createInvocationContext(InvocationContextContainerImpl.java:67)
> at
> org.infinispan.CacheDelegate.getInvocationContext(CacheDelegate.java:285)
> at org.infinispan.CacheDelegate.get(CacheDelegate.java:199)
> at
> org.radargun.cachewrappers.InfinispanWrapper.get(InfinispanWrapper.java:99)
> at
> org.radargun.stressors.PutGetStressor$Stresser.run(PutGetStressor.java
> :367)
>
> "Stresser-5" prio=10 tid=0x00007fb2c0292000 nid=0x5bd1 runnable
> [0x00007fb2c6dec000]
> java.lang.Thread.State: RUNNABLE
> at java.util.HashMap.get(HashMap.java:303)
> at
> org.infinispan.transaction.xa.TransactionTable.getXaCacheAdapter(TransactionTable.java:222)
> at
> org.infinispan.context.InvocationContextContainerImpl.createInvocationContext(InvocationContextContainerImpl.java:67)
> at
> org.infinispan.CacheDelegate.getInvocationContext(CacheDelegate.java:285)
> at org.infinispan.CacheDelegate.get(CacheDelegate.java:199)
> at
> org.radargun.cachewrappers.InfinispanWrapper.get(InfinispanWrapper.java:99)
> at
> org.radargun.stressors.PutGetStressor$Stresser.run(PutGetStressor.java
> :367)
>
> "Stresser-4" prio=10 tid=0x00007fb2c0291800 nid=0x5bd0 runnable
> [0x00007fb2c77f6000]
> java.lang.Thread.State: RUNNABLE
> at java.util.HashMap.get(HashMap.java:303)
> at
> org.infinispan.transaction.xa.TransactionTable.getXaCacheAdapter(TransactionTable.java:222)
> at
> org.infinispan.context.InvocationContextContainerImpl.createInvocationContext(InvocationContextContainerImpl.java:67)
> at
> org.infinispan.CacheDelegate.getInvocationContext(CacheDelegate.java:285)
> at org.infinispan.CacheDelegate.get(CacheDelegate.java:199)
> at
> org.radargun.cachewrappers.InfinispanWrapper.get(InfinispanWrapper.java:99)
> at
> org.radargun.stressors.PutGetStressor$Stresser.run(PutGetStressor.java
> :367)
>
> "Stresser-3" prio=10 tid=0x00007fb2c0290800 nid=0x5bcf runnable
> [0x00007fb2c78f7000]
> java.lang.Thread.State: RUNNABLE
> at java.util.HashMap.get(HashMap.java:303)
> at
> org.infinispan.transaction.xa.TransactionTable.getXaCacheAdapter(TransactionTable.java:222)
> at
> org.infinispan.context.InvocationContextContainerImpl.createInvocationContext(InvocationContextContainerImpl.java:67)
> at
> org.infinispan.CacheDelegate.getInvocationContext(CacheDelegate.java:285)
> at org.infinispan.CacheDelegate.get(CacheDelegate.java:199)
> at
> org.radargun.cachewrappers.InfinispanWrapper.get(InfinispanWrapper.java:99)
> at
> org.radargun.stressors.PutGetStressor$Stresser.run(PutGetStressor.java
> :367)
>
> "Stresser-2" prio=10 tid=0x00007fb2c0044000 nid=0x5bce runnable
> [0x00007fb2c76f5000]
> java.lang.Thread.State: RUNNABLE
> at java.util.HashMap.get(HashMap.java:303)
> at
> org.infinispan.transaction.xa.TransactionTable.getXaCacheAdapter(TransactionTable.java:222)
> at
> org.infinispan.context.InvocationContextContainerImpl.createInvocationContext(InvocationContextContainerImpl.java:67)
> at
> org.infinispan.CacheDelegate.getInvocationContext(CacheDelegate.java:285)
> at org.infinispan.CacheDelegate.get(CacheDelegate.java:199)
> at
> org.radargun.cachewrappers.InfinispanWrapper.get(InfinispanWrapper.java:99)
> at
> org.radargun.stressors.PutGetStressor$Stresser.run(PutGetStressor.java
> :367)
>
> "Stresser-1" prio=10 tid=0x00007fb2c0043000 nid=0x5bcd runnable
> [0x00007fb2c74f3000]
> java.lang.Thread.State: RUNNABLE
> at java.util.HashMap.get(HashMap.java:303)
> at
> org.infinispan.transaction.xa.TransactionTable.getXaCacheAdapter(TransactionTable.java:222)
> at
> org.infinispan.context.InvocationContextContainerImpl.createInvocationContext(InvocationContextContainerImpl.java:67)
> at
> org.infinispan.CacheDelegate.getInvocationContext(CacheDelegate.java:285)
> at org.infinispan.CacheDelegate.get(CacheDelegate.java:199)
> at
> org.radargun.cachewrappers.InfinispanWrapper.get(InfinispanWrapper.java:99)
> at
> org.radargun.stressors.PutGetStressor$Stresser.run(PutGetStressor.java
> :367)
>
> "Stresser-0" prio=10 tid=0x00007fb2c0048000 nid=0x5bcc runnable
> [0x00007fb2c75f4000]
> java.lang.Thread.State: RUNNABLE
> at java.util.HashMap.get(HashMap.java:303)
> at
> org.infinispan.transaction.xa.TransactionTable.getXaCacheAdapter(TransactionTable.java:222)
> at
> org.infinispan.context.InvocationContextContainerImpl.createInvocationContext(InvocationContextContainerImpl.java:67)
> at
> org.infinispan.CacheDelegate.getInvocationContext(CacheDelegate.java:285)
> at org.infinispan.CacheDelegate.get(CacheDelegate.java:199)
> at
> org.radargun.cachewrappers.InfinispanWrapper.get(InfinispanWrapper.java:99)
> at
> org.radargun.stressors.PutGetStressor$Stresser.run(PutGetStressor.java
> :367) _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
Hi all again,
but we have seen that the problem is already fixed in the last stable release (4.2.0). We were using the 4.1.0 version beceause when we have started to work in Infinispan the last stable was 4.1.0.
We are sorry!
Best regards
Sebastiano, Diego
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
The information contained in this message is legally privileged and confidential, and is intended for the individual or entity to whom it is addressed (or their designee). If this message is read by anyone other than the intended recipient, please be advised that distribution of this message, in any form, is strictly prohibited. If you have received this message in error, please notify the sender immediately and delete or destroy all copies of this message.
13 years, 3 months
Some docs on OGM
by Emmanuel Bernard
After being gently reminded by Manik several times, I've finally sat down and wrote a page on Hibernate OGM.
http://community.jboss.org/wiki/HibernateOGMGeneralInformations
It contains several sections:
- how to use
- how to contribute
- what is supported
- architecture
The wiki went wild, so if you edit it, copy it first (I know the text is blank on blank, go figure) in your favorite text-only editor and then paste back in a Wiki Markup element.
13 years, 3 months
Distributed execution framework API - final review
by Vladimir Blagojevic
Hi,
Manik and I agreed on final look of distributed execution framework
API[1]. We removed DistributedTask used for migrating
DistributedCallable to execution nodes and replaced it with
DistributedExecutorService which follows ideas of a familiar
ExecutorService from util.concurrent.
MapReduce is still a beast of its own that can not fit into
ExecutorService paradigm but I think we nailed it with a simple and easy
to use API. See in particular examples provided.
The last item Manik and I disagree on is use of DistributedTaskContext.
DistributedTaskContext is given to each DistributedCallable once it has
migrated to remote node for execution. DistributedTaskContext might
evolve and I'd rather keep it in the framework while Manik wants to have
a simple setter on DistributedCallable:
setEnvironment(Cache, K...)
I think of it as an insurance policy in case we need to bootstrap
DistributedCallable with more parameters rather than only Cache and
input keys K.
Lets hear your thoughts and comments.
Regards,
Vladimir
[1]
https://github.com/vblagoje/infinispan/tree/76bcf603946955bfac58ab4f22995...
13 years, 3 months
MurmurHash fixes
by Manik Surtani
Guys,
The MurmurHash2 impl we have in 4.2.0 is buggy in that my translation from the original C source was faulty and it effectively hashes over just 31 bits instead of 32. It means the distribution result isn't as good as it could be.
Now it isn't that easy for me to just *fix* this in 4.2.1, since it means keys mapped to nodes using 4.2.0 may not map to the same node in 4.2.1.
So here is what I propose:
1) Fix it in 4.2.x as MurmurHash2A
2) Use MurmurHash2A by default, *unless* a config flag is provided that forces the use of MurmurHash2. (e.g., <hash function="MurmurHash2">)
This will even give us the ability to use MurmurHash3 in 5.0 when we have it.
WDYT?
Cheers
Manik
--
Manik Surtani
manik(a)jboss.org
twitter.com/maniksurtani
Lead, Infinispan
http://www.infinispan.org
13 years, 3 months
