Warning about JBMAR 1.2 upgrade
by Galder Zamarreno
Hi,
I've upgraded trunk to JBMAR 1.2.0.CR1. There's a couple of tests
failing due to https://jira.jboss.org/jira/browse/JBMAR-59 which is
already fixed and will be included in 1.2.0.CR2. I'll upgrade to that asap.
Failing tests due to these issue are:
JBossMarshallerTest.testExceptionResponse
ReplicationExceptionTest.testLockAcquisitionTimeout
Finally, with 1.2 upgrade, payload of all objects marshalled with JBMAR
are smaller than with the old marshaller. Bela will like this! :)
--
Galder Zamarreño
Sr. Software Maintenance Engineer
JBoss, a division of Red Hat
14 years, 11 months
Using marshaller internally in MarshalledValue and Marshalling reentrancy
by Galder Zamarreno
Hi,
I'm trying to move MarshalledValue to use an injected Marshaller rather
than relying on standard serialization and this is causing me a small
problem:
One of the trade offs when making JBoss Marshalling
marshaller/unmarshaller a thread local in JBoss Marshaller is reentrancy.
When marshalling a MarshalledValue, we call start() on the marshaller
and then we'd call marshallerValue.getRaw(). The most reasonable
implementation using an injected marshaller would call:
raw = marshaller.objectToBuffer(instance).getBuf();
By calling oTB again, you're calling start on the marshaller below and
since this is a thread local, this is exactly the same instance and you
get issues.
I don't think JBoss Marshalling marshaller/unmarshaller are meant to be
reentrant and this is not my intention.
A second option would be to simply create a new marshaller in
MarshalledValue.getRaw() but this means some initialisation that
involves reflection, so this is no good.
The third option, an my preferred one, would be to add a boolean
parameter to Marshaller.startObjectOutput() called cached. Based on this
parameter, you could either get the marshaller from the thread local or
if false, get a new one from the factory. This would get around the
issue and makes the API more flexible coping with reentrant marshalling
while for the rest of cases, taking advantage of the performance gains
from using thread locals. The code in marshallerValue.getRaw() would
then look like this:
ExposedByteArrayOutputStream baos = new ExposedByteArrayOutputStream(128);
ObjectOutput out = marshaller.startObjectOutput(baos, false);
try {
marshaller.objectToObjectStream(instance);
} finally {
marshaller.finishObjectOutput(out);
}
raw = baos.getRawBuffer();
Of course, I would document this accordingly in the API so that cached
is only set to false if reentrant marshalling could happen.
Thoughts?
--
Galder Zamarreño
Sr. Software Maintenance Engineer
JBoss, a division of Red Hat
14 years, 11 months
keySet(), values() and entrySet() not implemented
by Galder Zamarreno
Hi,
keySet(), values(), entrySet() do not seem to be implemented at the moment:
public Set<K> keySet() {
throw new UnsupportedOperationException("TODO implement me"); //
TODO implement me
}
public Collection<V> values() {
throw new UnsupportedOperationException("TODO implement me"); //
TODO implement me
}
public Set<Map.Entry<K, V>> entrySet() {
throw new UnsupportedOperationException("TODO implement me"); //
TODO implement me
}
We should be implementing these methods, shouldn't we? Users might want
to iterate the map for example to print the contents or to verify it
contains what they put on it...etc.
I can't see a JIRA for it, so I'll open one so that this gets
implemented for Beta1 unless someone has any objections.
On IRC, Mircea said it might very costly, specially for dist, but we
still need it regardless, otherwise we're not fully implementing the
ConcurrentMap interface and these are commonly used methods.
Regards,
--
Galder Zamarreño
Sr. Software Maintenance Engineer
JBoss, a division of Red Hat
14 years, 11 months
JGroups 2.7 and 2.8 work with Infinispan now
by Vladimir Blagojevic
Hi,
Give it a try as well! I suggest we move to 2.8 sooner than later.
Currently, with tcp and 2.7 I get 0 failures and with 2.8 I get 9 faliures.
Cheers,
Vladimir
14 years, 11 months
Improvements for SessionSimulatorTest in benchmark framework
by Galder Zamarreno
Hi all,
Over the weekend, I've been reading the JCIP and I've come up with a
list of improvements that I'm planning to implement for
SessionSimulatorTest:
- Use a CyclicBarrier to control read/write tasks start when all threads
are already up and running. Otherwise some taks could have head start
and begin before other tasks due to scheduling and this could affect the
results that we see.
- When measuring throughpuyt, we get more accurate measures by timing
the entire run and then dividing it by the number of operations to get a
per operation time. So, I'd suggest doing this rather than measuring
individual ops time. We can do this very easily using CyclicBarriers as
shown in JCIP.
- Currently, SessionSimulatorTest does not use the result of cache.get()
which is a bit unrealistic and could lead to the VM optimizing the
return path of the value. A recommended technique for getting around
this is recommended in the book.
- Finally, before warmup begins, we should add a check that the view of
the cluster is formed of the number of nodes that we're testing.
- Add an option to indicate the stress test timeout (currently
defaulting to 10 mins). This could be handy when profiling which leads
to longer execution times.
Thoughts?
--
Galder Zamarreño
Sr. Software Maintenance Engineer
JBoss, a division of Red Hat
14 years, 11 months
Distributed hashing - heterogenous nodes
by Manik Surtani
This is based on a question that came up when discussing Infinispan
with the Red Hat MRG group. My current design treats nodes as equal,
and as such would get an equal number of keys mapped to the node.
This is not always desirable, since nodes aren't always equal. Nodes
could be weighted. Inspired by Amazon's Dynamo paper [1], I'm
considering providing an alternate ConsistentHash implementation that
supports weights, with the use of "virtual nodes", or "tokens".
I suppose the purpose of this email is, do we need a "simplistic" CH
implementation like the one I have right now, anymore? Should we not
just ship a weighted CH, with the default weight being equal?
Cheers
Manik
[1] http://www.allthingsdistributed.com/2007/10/amazons_dynamo.html
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
14 years, 11 months
JGroups 2.8.Alpha3 + roadmap
by Manik Surtani
I am including this in Infinispan 4.0.0.ALPHA4. There _are_ issues
though, but they are intermittent and are around SuspectExceptions.
These will cause Hudson failures, and for some reason are more
prominent on some tests than others (Dist tests, SingletonStore tests,
etc).
Vladimir, would you be around over the next few days to help debug and
pinpoint what's wrong here?
Also, what is your roadmap for JGroups 2.8?
Cheers
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
14 years, 11 months
