Infinispan testsuite's tcp.xml rename
by Galder Zamarreño
Hi,
We seem to have several tcp.xml files:
- jgroups-3.2.0.CR1.jar!/tcp.xml
- infinispan-core-5.2.0.Beta2-tests.jar/tcp.xml
An external project that might want to use the standard tcp.xml for testing might have issues if it's also depending on the Infinispan tests jars, it might have issues, particularly cos that tcp.xml has RELAY2 configuration that's environment specific, i.e.
Caused by: java.lang.Exception: site configuration for "__site_name__" not found in configs/xsite/relay-config.xml
at org.jgroups.protocols.relay.RELAY2.parseSiteConfiguration(RELAY2.java:161)
at org.jgroups.protocols.relay.RELAY2.init(RELAY2.java:88)
at org.jgroups.stack.ProtocolStack.initProtocolStack(ProtocolStack.java:857)
at org.jgroups.stack.ProtocolStack.setup(ProtocolStack.java:469)
at org.jgroups.JChannel.init(JChannel.java:749)
at org.jgroups.JChannel.<init>(JChannel.java:167)
at org.jgroups.JChannel.<init>(JChannel.java:137)
at org.infinispan.remoting.transport.jgroups.JGroupsTransport.buildChannel(JGroupsTransport.java:365)
... 74 more
So, what about we rename the tcp.xml in the infinispan testsuite?
Cheers,
--
Galder Zamarreño
galder(a)redhat.com
twitter.com/galderz
Project Lead, Escalante
http://escalante.io
Engineer, Infinispan
http://infinispan.org
12 years, 1 month
Per-entry lock container
by Manik Surtani
Guys, after investigating https://issues.jboss.org/browse/ISPN-2381 and https://github.com/infinispan/infinispan/pull/1382, I've discovered a pretty nasty race condition in our per-entry lock containers (whether OwnableReentrantLocks or JDK locks for non-transactional caches).
The problem is that we maintain a lock map, and any given request can acquire a lock, if a lock doesn't exist for a given key, create the lock and acquire it, and when done, release the lock and remove it from the lock map. There's lots of room for races to occur. The current impl uses a ConcurrentMap, where concurrent operations on the map are used to make sure locks are not overwritten. But still, since the process of creating, acquiring and adding the lock to the lock map needs to be atomic, and not just atomic but also safe with regards to competing threads (say, an old owner) releasing the lock and removing it from the map (also atomic), I think a concurrent map isn't good enough anymore.
The sledgehammer approach is to synchronise on this map for these two operations, but that causes all sorts of suckage. Ideally, I'd just hold on to the segment lock for the duration of these operations, but these aren't exposed. Extending CHM to expose methods like acquireLockAndGet() and unlockAndRemove() would work perfectly, but again a lot of CHM internals are private or package protected.
So my options are: completely re-implement a CHM-like structure, like we've done for BCHM, or perhaps think of a new, specialised structure to contain locks. In terms of contract, I just need a fast way to look up a value under given a key, efficient put and remove as well. It should be thread-safe (naturally), and allow for an atomic operation (like "get, do work, put").
Any interesting new data structures on peoples' minds?
Cheers
Manik
--
Manik Surtani
manik(a)jboss.org
twitter.com/maniksurtani
Platform Architect, JBoss Data Grid
http://red.ht/data-grid
12 years, 1 month
Dist.exec failover
by Vladimir Blagojevic
Hey guys,
Erik noted that we should by default have no failover policy installed
rather the default random policy we currently have. Also he noted that
keys are never supplied to failover policy and they might be important
when it comes to a deciding where to dispatch the failed over task.
Our current interface is :
public interface DistributedTaskFailoverPolicy {
Address failover(Address failedExecution, List<Address>
executionCandidates, Exception cause);
}
Rather than adding yet another parameter here maybe we should make a
simple container class
public class FailoverContext {
Address failedExecution;
List<Address> executionCandidates;
Exception cause;
List<Object> inputKeys;
}
and have
public interface DistributedTaskFailoverPolicy {
Address failover(FailoverContext context);
}
WDYT?
Regards,
Vladimir
12 years, 1 month
Replace command not checking previous value
by Sanne Grinovero
Hello,
I'm in need to use the Cache method
.replace( key, expectedValue, newValue );
and while debugging I got into
org.infinispan.commands.write.ReplaceCommand.perform(InvocationContext)
which is doing "the right think" only if ctx.isOriginLocal() . What
puzzles me most is that there even is a comment pointing this out, as
it was a design choice made for some purpose.. some purpose which
strongly conflicts with my needs and the API contract :-/
Could anyone please explain?
thanks,
Sanne
12 years, 1 month
Correction in documents
by Rohith Thulasidas
Dear All,
I am a newbie to JBoss community, and I am very happy to be a part of the
community which is contributing a lot to this techie world.
I would like to know that what I should do, if I came across some mistakes
in documents(as simple as spelling mistakes).
My contribution may be small, but the quality of the product may go high.
Regards
Rohith Thulasidas
12 years, 1 month
Re: [infinispan-dev] Cache stopping
by Galder Zamarreño
Extending to dev list...
On Oct 18, 2012, at 4:32 PM, Vladimir Blagojevic <vblagoje(a)redhat.com> wrote:
> On 12-10-18 5:56 AM, Galder Zamarreño wrote:
>> On Oct 17, 2012, at 11:44 PM, Vladimir Blagojevic <vblagoje(a)redhat.com> wrote:
>>
>>> Hey Galder,
>>>
>>> I've noticed that some of the Map/Reduce tasks were failing due to CacheRemoveCommand timeouts.
>> Hmmm, who's calling remove cache?
> MapReduceTask is calling it when it cleans up and destroys temp cache.
Ok.
>>> I've noticed that sometimes cache stop command takes longer that default rpc timeout and was wondering why might be the cause?
>> Thread dumps? Logs?
> I'll take a look, no problem.
>
>>
>>> If there is nothing to be done for cache stopping timeout does it make sense to have an option of CacheRemoveCommand being asynchronous?
>> Well, before you consider that you need to figure out why remove cache is called, and if it's really needed.
>>
> It is needed to remove tmp cache that MapReduceTask used for intermediate values.
Ok. At which point does it get called? When the cache stops?
And what would the effects be if all nodes deleted the temporary cache except one of them? What would be the implications of this?
>
> Cheers,
> Vladimir
>
--
Galder Zamarreño
galder(a)redhat.com
twitter.com/galderz
Project Lead, Escalante
http://escalante.io
Engineer, Infinispan
http://infinispan.org
12 years, 1 month
Changing the configuration for Cross site state transfer
by Hammad Said
I am implementing the cross site state transfer. In order to have specify the timeout of the state transfer and the chunk size to be sent in each transfer we are proposing changes in XSD. Specifically suggesting to add the element stateTransfer with the attributes timeout and chunkSize. Please let me know what you think of it.
<namedCache name="noTakeOffline">
<sites>
<backups>
<backup site="NYC" strategy="SYNC" backupFailurePolicy="WARN" timeout="12003">
<stateTransfer timeout="30000" chunkSize="40"/>
</backup>
</backups>
<backupFor/>
</sites>
</namedCache>
Thanks!
Hammad
12 years, 1 month
XSite configuration in AS7/EAP/JDG
by Tristan Tarrant
Hi all,
right on the heels of my previous e-mail related to declarative
configuration of XSite in Infinispan, I also would like to tackle the
issue of how we are going to translate it to the configuration dialect
in AS7/EAP/JDG.
Here's my rough concept:
add the local site name to the <cache-container /> element
<cache-container name="maximal" aliases="alias1 alias2"
default-cache="local" eviction-executor="infinispan-eviction"
jndi-name="java:global/infinispan/maximal"
listener-executor="infinispan-listener"
replication-queue-executor="infinispan-repl-queue" module="org.infinispan"
local-site="LON">
add the backups element as a child of the cache:
<local-cache name="local">
<backups>
<backup site="NYC" failure-policy="WARN" strategy="SYNC"
timeout="12000" enabled="true"/>
<backup site="SFO" failure-policy="IGNORE" strategy="ASYNC"
enabled="true"/>
<backup site="LON" strategy="SYNC" enabled="false"/>
</backups>
<backup-for remote-cache="remoteCache" remote-site="NYC" />
</local-cache>
Since the JGroups config already allows multiple stacks, I suggest
adding the relay element as a child of the <stack /> element allowing it
to reference other stacks:
<stack name="bridge">
<transport type="TCP" socket-binding="jgroups-bridge-tcp" />
</stack>
<stack name="xsite">
<transport type="TCP" socket-binding="jgroups-tcp" />
<protocol ... />
<relay type="relay.RELAY2">
<site name="LON" id="0">
<bridges>
<bridge name="global" stack="bridge" />
</bridges>
</site>
<site name="NYC" id="1">
<bridges>
<bridge name="global" stack="bridge" />
</bridges>
</site>
<site name="SFO" id="2">
<bridges>
<bridge name="global" stack="bridge"/>
</bridges>
</site>
</relay>
</stack>
Comments ?
Tristan
12 years, 1 month
XSite Declarative configuration
by Tristan Tarrant
Hi all,
sorry for this being a bit late (but since it is before CR1 it is not
that late :), but the XSite config looks a bit redundant and we should
improve it a bit before release
|<||global||>|
|||...|
|||<||sites| |local||=||"LON"||/>|
|||...|
|</||global||>|
Since this just provides the local logical name for this site I would
instead use
|<||global||>|
|||...|
|||<||site| |name||||=||"LON"||/>|
|||...|
|</||global||>|
In the cache declaration we have the following:
| <||sites||>|
|||<||backups| |backupSites||=||"NYC,SFO"||>|
|||<||backup| |site||=||"NYC"| |backupFailurePolicy||=||"WARN"|
|strategy||=||"SYNC"| |timeout||=||"12000"||/>|
|||<||backup| |site||=||"SFO"| |backupFailurePolicy||=||"IGNORE"|
|strategy||=||"ASYNC"||/>|
|||<||backup| |site||=||"LON"| |strategy||=||"SYNC"||/>|
|||</||backups||>|
|||</||sites||>|
Instead of dumping a list inside an XML attribute (backupSites), can't
we just skip that attribute and add an enabled attribute to each backup
element ? Also the "backup" prefix to the failure policy is redundant
and can be dropped altogether.
Also, while I understand the rationale behind giving a "home element" to
all xsite-related configurations (<sites>), I do feel it is unnecessary,
so I suggest:
|||<||backups||||>|
|||<||backup| |site||=||"NYC"| |failurePolicy||=||"WARN"|
|strategy||=||"SYNC"| |timeout||=||"12000"||enabled="true"/>|
|||<||backup| |site||=||"SFO"| |failurePolicy||=||"IGNORE"|
|strategy||=||"ASYNC"||enabled="true"/>|
|||<||backup| |site||=||"LON"| |strategy||=||"SYNC"||enabled="false"/>|
|||</||backups||>|
This means that <backupFor/> also moves as a direct child element of a
cache declaration.
Just my 2¢
Tristan
12 years, 1 month
