Disabled PooledConnectionFactoryTest
by Manik Surtani
Hmm, PooledConnectionFactoryTest still seems disabled:
Obelix:trunk manik$ bin/findDisabledTests.py
Files containing disabled tests:
1. core/src/test/java/org/infinispan/profiling/MemConsumptionTest.java
2. tree/src/test/java/org/infinispan/profiling/TreeProfileTest.java
3. core/src/test/java/org/infinispan/profiling/ProfileTest.java
4. core/src/test/java/org/infinispan/profiling/AbstractProfileTest.java
5. cachestore/jdbc/src/test/java/org/infinispan/loader/jdbc/
PooledConnectionFactoryTest.java
(finished in 0.249939 seconds)
Obelix:trunk manik$
I understand this is a C3P0 issue, but the bug seems pretty old (> 1
year?) and still not fixed. I don't quite understand the specific
problem here - could you pls explain in further detail? Is it
something we can work around? Also, is it something that only affects
the test, or could it potentially affect a running JDBCCacheStore as
well?
Cheers
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
15 years
API behaviour when using DIST
by Manik Surtani
Some of the API methods' return values may not be as expected when
using DIST. Just wanted to run this by you guys to see what you
thought.
Specifically, what I am referring to is methods like put(),
putIfAbsent(), and the 2 versions of remove() and replace().
Now when these are executed in any other cache mode (LOCAL, REPL,
INVAL) return values are as expected from their java.util.Map contracts.
However with DIST, there are 2 separate ways this could go.
1. The key in question is mapped to the local cache on which the
method is invoked.
This case behaves normally as well as per the Map contract.
2. The key in question is *not* mapped to the local cache. E.g., K
is mapped to nodes A and B, and on C we do C.remove().
I can stick with the map contract if each of these methods first does
a remote lookup of the key and stores this in L1 (or even in the
invocation context and then throw it away if there is no L1) but this
is unnecessarily wasteful IMO.
The other approach is to realise the command pertains to a key for
which the local cache is not the owner, and replicate the call to the
remote nodes.
What happens next is also a matter of tuning: we could
a) replicate + ignore responses. Then the retval to these methods are
indeterminate, and probably unusable.
b) replicate + wait for response. This will adhere to the Map
contract, albeit at a cost. Probably not possible if we use DIST_ASYNC.
c) L1: we could either "correct" the L1 cache with the change, or
remove the key forcing another lookup for the next time around.
What do people think? Maybe offer all strategies? Or will this then
become configuration hell? :)
Cheers
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
15 years
ClusteredGet and direct operations on a cacheloader
by Manik Surtani
Mircea
Regarding direct loading from a cache loader in the
ClusteredGetCommand, this is an issue since a) it does not acquire any
locks to put this value back in the data container, and b) probably as
a consequence of a), doesn't bother to put any looked up value in the
data container at all.
This is inefficient since multiple CGCs on the same key (coming from
different cache instances in a cluster) would cause the owning cache
to load this several times repeatedly from a loader.
I see this problem with DIST since I use CGC to load an entry from a
remote cache and if L1 caching is disabled on the requesting cache,
multiple uses of an entry will result in this entry being read off a
loader repeatedly. Which is no good. :-)
So I think the CGC's perform() method should actually be doing a
cache.get() - or something very similar - where the entire interceptor
chain is invoked and locks are acquired, entries moved to the data
container if loaded, etc., and metrics on cache hits/misses properly
updated. The challenges here are, of course:
1. The ping-pong effect. So we need to make sure any clustered cache
loader or the DistributionInterceptor do not try and load this from
elsewhere in the cluster. Easily solved with the isOriginLocal flag
on the context.
2. Making sure we get an InternalCacheEntry and not just a value to
return. This is trickier since ICEs are not exposed via public APIs
at all. Perhaps we need a separate, non-replicable Command for this
purpose - maybe a subclass of GetKeyValueCommand
(GetCacheEntryCommand?) which (a) cannot be replicated and (b) will
return the ICE.
So, CGC would create a GCEC and pass it up the interceptor chain, and
retrieve the ICE from the GCEC after the call returns?
WDYT?
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
15 years
Infinispan added to bench fwk but exception when running test
by Galder Zamarreno
Hi,
I've added Infinispan cache product to the cache benchmark framework
based on Alpha1 (checked out and built from tag):
https://svn.jboss.org/repos/jbosscache/benchmarks/benchmark-fwk/trunk/cac...
I've tried to run a basic replicated test (see attached cachebench.xml)
but I keep getting exceptions like this in both nodes:
Caused by: java.util.concurrent.TimeoutException: Timed out waiting for
a cluster-wide sync to be released. (timeout = 5 seconds)
at
org.infinispan.remoting.transport.jgroups.FlushBasedDistributedSync.blockUntilReleased(FlushBasedDistributedSync.java:51)
at
org.infinispan.remoting.transport.jgroups.JGroupsTransport.invokeRemotely(JGroupsTransport.java:291)
I'm a bit confused by this. What is exactly waiting for? Both nodes join
fine and I'm using tcp.xml. Find attached logs.
FYI, this is the way I'm running this:
Open 1st window and execute:
export MYTESTIP_2=127.0.0.2
./runNode.sh 0 infinispan-4.0.0 repl-sync-RR.xml 2
Open 2nd window and execute:
export MYTESTIP_2=127.0.0.3
./runNode.sh 1 infinispan-4.0.0 repl-sync-RR.xml 2
Cheers,
--
Galder Zamarreño
Sr. Software Maintenance Engineer
JBoss, a division of Red Hat
15 years
Marshalling
by Manik Surtani
I'm not gonna do this for the first alpha, but for the second one, I'd
like to make the JBoss-Marshalling approach to be default and pull out
the legacy marshaller.
To do this, we need:
1. ISPN-49
2. Some confirmation that there is in-fact a performance increase,
and not a decrease. Comparing profiler snapshots would help here.
Galder, do you have some time to look at this next week?
Cheers
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
15 years
DefaultConsistentHash locate
by Vladimir Blagojevic
I'll just shoot questions as I am getting familiar with design and code.
If it makes sense, and to my naive eye it does, why don't we cache
results of locate calls?
15 years
Hibernate Plug-in
by Paul Romlow
I have been doing some work on the Hibernate plug-in and have a few questions:
There is no explicit locking in Infinispan, correct? In several of the
Hibernate APIs there are transaction time stamps, but I'm not sure if
and how they should/could be used, ideas? I am also having some
trouble with mapping Hibernate's concept of a version to Infinispan.
For an example, please see
org.hibernate.cache.access.CollectionRegionAccessStrategy
specifically the putFromLoad and lockItem/lockRegion methods.
Is there any way to get the memory/disk information in
org.hibernate.cache.Region?
Apologies for the lack of direct links, but hibernate.org is down for
maintenance.
One last thing, if there is any documentation about writing
Hibernate-specific unit tests, could someone point me in the right
direction? org.hibernate.junit org.hibernate.test
It looks like the BaseCacheProviderTest should be deprecated, since it
relies on the deprecated CacheProvider.
Thanks,
paul
15 years
Changes to ReplListener
by Manik Surtani
I've made a few changes to the ReplListener helper class that lives in
the test harness. The ReplListener can now be constructed to eagerly
listen for commands, and reconciliate these with expectations set in
expect() so that commands seen between construction of the listener
and calling expect() are also recorded and noted.
Enjoy!
Manik
Begin forwarded message:
> From: infinispan-commits(a)lists.jboss.org
> Date: 22 April 2009 10:51:08 BST
> To: infinispan-commits(a)lists.jboss.org
> Subject: [infinispan-commits] Infinispan SVN: r158 - trunk/core/src/
> test/java/org/infinispan/test.
> Reply-To: infinispan-commits(a)lists.jboss.org
>
> Author: manik.surtani(a)jboss.com
> Date: 2009-04-22 05:51:08 -0400 (Wed, 22 Apr 2009)
> New Revision: 158
>
> Modified:
> trunk/core/src/test/java/org/infinispan/test/ReplListener.java
> Log:
> Ability to eagerly record commands
>
> Modified: trunk/core/src/test/java/org/infinispan/test/
> ReplListener.java
> ===================================================================
> --- trunk/core/src/test/java/org/infinispan/test/ReplListener.java
> 2009-04-21 13:37:17 UTC (rev 157)
> +++ trunk/core/src/test/java/org/infinispan/test/ReplListener.java
> 2009-04-22 09:51:08 UTC (rev 158)
> @@ -19,12 +19,37 @@
> * attachReplicationListener(cache);
> r.expect(RemoveCommand.class); // ... r.waitForRPC(); </code>
> */
> public class ReplListener {
> - Cache c;
> - Set<Class<? extends VisitableCommand>> expectedCommands;
> + Cache<?, ?> c;
> + volatile Set<Class<? extends VisitableCommand>> expectedCommands;
> + Set<Class<? extends VisitableCommand>> eagerCommands;
> + boolean recordCommandsEagerly;
> CountDownLatch latch = new CountDownLatch(1);
>
> - public ReplListener(Cache c) {
> + /**
> + * This listener atatches itself to a cache and when {@link
> #expect(Class[])} is invoked, will start checking for
> + * invocations of the command on the cache, waiting for all
> expected commands to be received in {@link
> + * #waitForRpc()}.
> + *
> + * @param c cache on which to attach listener
> + */
> + public ReplListener(Cache<?, ?> c) {
> + this(c, false);
> + }
> +
> + /**
> + * As {@link #ReplListener(org.infinispan.Cache)} except that
> you can optionally configure whether command recording
> + * is eager (false by default).
> + * <p/>
> + * If <tt>recordCommandsEagerly</tt> is true, then commands are
> recorded from the moment the listener is attached to
> + * the cache, even before {@link #expect(Class[])} is invoked.
> As such, when {@link #expect(Class[])} is called, the
> + * list of commands to wait for will take into account commands
> already seen thanks to eager recording.
> + *
> + * @param c cache on which to attach listener
> + * @param recordCommandsEagerly whether to record commands eagerly
> + */
> + public ReplListener(Cache<?, ?> c, boolean
> recordCommandsEagerly) {
> this.c = c;
> + this.recordCommandsEagerly = recordCommandsEagerly;
> this.c.getAdvancedCache().addInterceptor(new
> ReplListenerInterceptor(), 1);
> }
>
> @@ -70,6 +95,8 @@
> this.expectedCommands = new HashSet<Class<? extends
> VisitableCommand>>();
> }
> this.expectedCommands.addAll(Arrays.asList(expectedCommands));
> +
> + if (recordCommandsEagerly)
> this.expectedCommands.removeAll(eagerCommands);
> }
>
> /**
> @@ -99,6 +126,10 @@
> }
> }
>
> + public Cache<?, ?> getCache() {
> + return c;
> + }
> +
> protected class ReplListenerInterceptor extends
> CommandInterceptor {
> @Override
> protected Object handleDefault(InvocationContext ctx,
> VisitableCommand cmd) throws Throwable {
> @@ -124,7 +155,11 @@
> expectedCommands.remove(cmd.getClass());
> if (expectedCommands.isEmpty()) latch.countDown();
> } else {
> - System.out.println("Received unexpected command: " +
> cmd);
> + if (recordCommandsEagerly) {
> + eagerCommands.add(cmd.getClass());
> + } else {
> + System.out.println("Received unexpected command: " +
> cmd);
> + }
> }
> }
> }
>
> _______________________________________________
> infinispan-commits mailing list
> infinispan-commits(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-commits
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
15 years
