Map/Reduce test failures in master
by Manik Surtani
Guys (probably Vladimir)
Does anyone know what's up here? I see these fail sporadically:
Failed tests: testinvokeMapReduceOnAllKeys(org.infinispan.distexec.mapreduce.DistributedTwoNodesMapReduceTest): Error removing cache
testCombinerDoesNotChangeResult(org.infinispan.distexec.mapreduce.DistributedFourNodesMapReduceTest): Error removing cache
testinvokeMapReduceOnAllKeysWithCollator(org.infinispan.distexec.mapreduce.DistributedFourNodesMapReduceTest): Error removing cache
testinvokeMapReduceOnAllKeysWithCollatorAsync(org.infinispan.distexec.mapreduce.DistributedFourNodesMapReduceTest): org.infinispan.CacheException: Error removing cache
I presume I am not alone here?
Cheers
Manik
--
Manik Surtani
manik(a)jboss.org
twitter.com/maniksurtani
Platform Architect, JBoss Data Grid
http://red.ht/data-grid
13 years, 10 months
Release 5.2.CR1
by Mircea Markus
Hi,
Even though there has been a sustained push and many of the NBST issues raised are now either in master or with pending pull requests, the general feeling is that the 5.2 master is not yet CR ready.
In order to allow time to finish some pending JIRAs and to integrate what we already have in the queue, next Infinispan release(Beta3 or CR1) is postponed to 25 Oct.
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
13 years, 10 months
Including CENTRAL_LOCK in our stacks, COUNTER
by Sanne Grinovero
Hi all,
I'm still in a prototyping phase, but for the next big feature of
Hibernate Search & Infinispan Query it looks like the LockService from
JGroups would be exactly what I need.
My only concern about using it is that people will have to reconfigure
JGroups from Infinispan, or even worse to reconfigure the stack in
AS7.
Would it be possible to include this in our default stacks? Including
the one provided by AS7 ?
I have a very similar requirement for Hibernate OGM to rely on COUNTER
for the CounterService... same question, different use case.
Regards,
Sanne
13 years, 10 months
Re: [infinispan-dev] Infinispan 5.1.x Object marshalling with and without a class table in use and unmarshalling smacking its head against the wall...
by Scott Marlow
On 10/15/2012 06:07 PM, Dennis Reed wrote:
> On 10/15/2012 04:21 PM, Scott Marlow wrote:
>> On 10/15/2012 12:47 PM, Scott Marlow wrote:
>>> On 10/15/2012 06:12 AM, Galder Zamarreño wrote:
>>>> I've just realised this is the same issue Dennis reported in
>>>> https://issues.jboss.org/browse/ISPN-2330
>>>>
>>>> @Ben, this should also solve your TorqueBox problem.
>>>>
>>>> I'll fix it today.
>>>
>>> Didn't seem to help. I attached server.log's to ISPN-2330, not that I
>>> expect them to be that useful directly (I don't have Infinispan trace
>>> logging enabled, just added my own INFO level output and various
>>> printlns also in infinispan/jboss-marshalling).
>>>
>>> I'll send an update later when I have more information to share.
>>
>>
>> For my issue, stop/start methods don't appear to be involved.
>> http://pastebin.com/QiGV7F3b shows us creating a new
>> ExtendedRiverMarshaller/ContextClassResolver pair which is soon used
>> for marshalling.
>
> The stop method is involved.
>
> Your logs attached to the JIRA show the error start happening when you
> redeploy your war.
> During the undeploy it calls JBossMarshaller.stop, then during the
> deploy it gets the error because of the wrong class resolver.
>
>> I do see some calls to JBossMarshaller.stop() during my testing but
>> that is very early in the test run (well before any of this occurs and
>> well after the failures occur).
>>
>> I'll stop commenting on ISPN-2330, since my issue appears to be
>> different.
>
> It's not different. You are hitting ISPN-2330.
All the better if I'm wrong, as we will solve both problems with one
fix. :)
I don't see it yet though. I attached new logs to ISPN-2330 with a
little more information (clearer indication of when the problem is
caused in jbossas-clustering-SYNC-tcp-0/standalone/log/server.log).
Both the ContextClassResolver and the ExtendedRiverMarshaller are
created well after the last JBossMarshalling.stop() occurred. Also, if
we are creating a new ExtendedRiverMarshaller and using that when this
failure occurs, that should have nothing to do with any JBossMarshaller
instances.
Also note that the jbossmarshaller.stop() is only logged at the
beginning of the testsuite run and near the end (in
jbossas-clustering-SYNC-tcp-0/standalone/log/server.log).
>
> Also note that the class resolver is not the only issue that prevents a
> clustered .war or EJB to be redeployed in EAP6.
> There's also an issue with state transfer (which may be related to the
> same underlying cause -- both issues appear to be from re-using the
> wrong component that was already stopped).
>
> -Dennis
>
13 years, 10 months
admin operations for xsite replication
by Mircea Markus
Hi,
Re: https://issues.jboss.org/browse/ISPN-2320
Here is a list of admin operations I'd like to implement for ISPN-2320:
- status: shows a map with all defined sites and their status: available xor offline
- takeOffline: takes a site offline, i.e. backup to that site is ignored
- takeOnline: the reverse to takeOffline
- amendTakeOffline (int:afterFailures, long:minTimeToWait): changes the takeOffline functionality[1]
- statistics: numberOfBackupCalls, successfullBackupCalls, failedBackupCalls
Each of the operations that modify configs would be available on a per node or on a per cluster basis (a flag to the operation would differentiated between the two).
How does that sound? Any other operations you might think of?
[1] https://docs.jboss.org/author/display/ISPN/Cross+site+replication#Crosssi...
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
13 years, 10 months
Infinispan 5.1.x Object marshalling with and without a class table in use and unmarshalling smacking its head against the wall...
by Scott Marlow
ReplicableCommandExternalizer.writeCommandParameters() can marshall an
instance of class org.infinispan.util.ImmutableListCopy (as a
ID_EXTERNALIZABLE_CLASS) fine. If the classtable doesn't know about the
org.infinispan.util.ImmutableListCopy class, we also marshall the AS7
module name (org.infinispan) and module slot name (main). The
marshalled byte output looks something like the following (this is the
successful case). I apologize for the crappy hex/character dump :).
Each hex value is preceded by '0x' and followed by an extra space separator.
*class table does not have ImmutableListCopy class case*
0x03 0x01 0xFE 0x03 J0x00 0x00 0x11 0x00 0x00 0x00 0x1A
default-host/distributable0xAE 0x01 0x03 0x01 0xFE 0x06 I0x02 0x03 '0x02
])0xDE +?>0x85 0xBF 0xEC 0xCD P0xCB 0x8E 20x9E 0xD0 K0x00 0x00 0x00 0x07
0x04 0x0A 0x00 0x00 0x00 %org.infinispan.util.ImmutableListCopy0x00 0x00
0x09 0xF0 0xBD 0x13 q0x06 >0x0E org.infinispan>0x04 main20x04 0x00 0x00
0x00 0x02 0x03 '0x02 ])0xDE +?>0x85 0xBF 0xEC 0xCD P0xCB 0x8E 20x9E 0xD0
0x03 '0x02 0xB4 0x0D 00x8C 0x98 0xCF M0x89 0xF1 d|}0x0A 0x0B 0xA3 0xCD
5K0x00 0x00 0x00 0x06 0x03 0x04 0x03 '0x02 ])0xDE +?>0x85 0xBF 0xEC 0xCD
P0xCB 0x8E 20x9E 0xD0
Notice that the "org.infinispan.util.ImmutableListCopy" (on middle of
fourth line) is followed by about 10 separator bytes (of some importance
I'm sure :). After the 10 separator bytes, is the module name
(org.infinispan) and that is followed by more separator bytes and then
the module slot name (main). Again, this is the *working case*.
If the classtable does have an entry for the
org.infinispan.util.ImmutableListCopy class,
ReplicableCommandExternalizer.writeCommandParameters() appears to
instead write out some binary values that unmarshalling won't know how
to deal with later. The hexdump for the *failing case* looks like:
*class table does have ImmutableListCopy class case*
0x03 0x01 0xFE 0x03 J0x00 0x00 0x11 0x00 0x00 0x00
Dorg.jboss.as.test.clustering.cluster.ejb3.stateful.bean.StatefulBean0x98 0x01
0x03 0x01 0xFE 0x06 I0x02 0x03 '0x02 0xD5 0xFD 0xCC 0xC7 0xFD 0x10 0xCC
Q70xF7 0x9C %lZ5K0x00 0x00 0x00 0x14 0x04 0x0A 0x00 0x00 0x00
%org.infinispan.util.ImmutableListCopy0x00 0x00 0x09 0xF0 0xBD 0x13
q0x06 20x04 0x00 0x00 0x00 0x02 0x03 '0x02 H0xC6 0xD0 w0xEA 10xEA 0x97
U0xDC 0xE6 0x1C B0x99 s0xF1 0x03 '0x02 0xD5 0xFD 0xCC 0xC7 0xFD 0x10
0xCC Q70xF7 0x9C %lZ55K0x00 0x00 0x00 0x13 0x03 0x04 0x03 '0x02 H0xC6
0xD0 w0xEA 10xEA 0x97 U0xDC 0xE6 0x1C B0x99 s0xF1
In the above, the "org.infinispan.util.ImmutableListCopy" field is
followed by various bytes but no module name.
Later during when unmarshalling this payload, we reach code that doesn't
understand how to unmarshall. http://pastie.org/5043963 shows the
failing callstack (partially below for your convenience). It seems to
me, that somewhere in unmarshalling (Object) code, we need to check if a
class table was used and use the marshalled form instead.
org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:751)
org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:37)
org.jboss.marshalling.ModularClassResolver.resolveClass(ModularClassResolver.java:101)
org.jboss.marshalling.river.RiverUnmarshaller.doReadClassDescriptor(RiverUnmarshaller.java:938)
org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1210)
org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:272)
org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:37)
org.infinispan.marshall.exts.ReplicableCommandExternalizer.readParameters(ReplicableCommandExternalizer.java:158)
This is recreating on the AS 7.1 branch, with jboss-marshalling 1.3.17.x
and Infinispan 5.1.x.
I'll get closer to understanding the problem, but I need to hear from
the Infinispan champion of marshalling and class table handling. So, I
can coordinate effort with him/her. I also wanted to share what we are
seeing as well with the team. :)
Scott
13 years, 10 months
State transfer performance
by Mircea Markus
Hi ,
One of the targets of NBST is to minimise the downturn in throughput during topology changes. And now that NBST is getting there, I think that a test to measure how long does it take to a node to join, under different levels of cluster load, is very desirable in order to see where we are and also to help us profile and improve the state transfer performance.
Martin, are we doing this kind of performance testing? It would be nice to have it integrated in Radargun or something similar in order to be able to quickly run it.
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
13 years, 10 months
eviction + listeners in a local cache with unbounded container
by Adrian Nistor
Hi,
I've encountered a strange situation where eviction listeners are not
invoked although eviction otherwise works perfectly.
I use a local cache with no eviction policy. Looking at the code in
DataContainerFactory I can see this leads to an unbounded data container
which does not broadcast eviction notifications.
Now the problem is when I use a put and specify a lifespan (ie. V
BasicCache.put(K key, V value, long lifespan, TimeUnit lifespanUnit,
long maxIdleTime, TimeUnit maxIdleTimeUnit)) it behaves a bit strange -
the entry is evicted when lifetime expires but no listeners are notified
of the eviction. Is this behaviour intended or is it a bug? I think it
would make more sense to invoke those listeners. Now it seems to behave
as if eviction notification mechanism is disabled just because there is
no default life time set at cache level.
Cheers,
Adrian
13 years, 10 months
RAC: Reliable Asynchronous Clustering
by Bela Ban
Hi all,
I've come up with an alternative to sync TX updates across sites. It's
based on the requirement that we need high reliability between sites,
but yet it isn't feasible to run 2PCs across sites. RAC [1] is supposed
to be almost as fast as async replication and close to the reliability
sync replication provides.
I've published the design at [1], and we'll present it in more detail at
our clustering meeting in Palma early November.
Comments and feedback are welcome !
[1] https://community.jboss.org/wiki/RAC
--
Bela Ban, JGroups lead (http://www.jgroups.org)
13 years, 10 months
