Hotrod client intelligence
by Mircea Markus
Hi,
Right now we have the following intelligence levels in HR:
(0x01) basic client, interested in neither cluster nor hash information
(0x02) topology-aware client, interested in cluster information
(0x03) hash-distribution-aware client, that is interested in both cluster and hash information
the 4th is to be added, which is transactionable client.
Right now 3 depends on 2, so a unique number can clearly identify the level. With 4, there might be different combinations: e.g. 4 and 2 or 4 and 3. Or even 4 and 1.
We need a way to specify this intelligence combo: perhaps using bit masks?
IMO, this should be done before going Final as it is a change in the protocol itself.
wdyt?
Cheers,
Mircea
16 years
Topology Id in Hotrod header
by Mircea Markus
Hi,
The header for a request is composed of:
Magic Message Id Version Opcode Cache Name Length Cache Name Flags Client Intelligence Topology Id
We send "Topology Id " even if the client is not topology aware. Wouldn't it be more effective to only expect it if the client's intelligence is 02 or 03 and not send it otherwise?
Cheers,
Mircea
16 years
Possible error of dependency on infinispan-query pom
by Israel Lacerra
Hi everybody,
I'm making some tests and I am using infinispan-gui-demo. So I have to
include "infispan-query" as a dependency in infinispan-gui-demo. After this,
and including my code that make some use of infispan-query module, I get
this when I start the cache:
Exception in thread "pool-1-thread-1" java.lang.NoClassDefFoundError:
org/slf4j/impl/StaticLoggerBinder
at org.slf4j.LoggerFactory.getSingleton(LoggerFactory.java:223)
at org.slf4j.LoggerFactory.bind(LoggerFactory.java:120)
at org.slf4j.LoggerFactory.performInitialization(LoggerFactory.java:111)
at org.slf4j.LoggerFactory.getILoggerFactory(LoggerFactory.java:269)
at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:242)
at org.hibernate.search.util.LoggerFactory.make(LoggerFactory.java:38)
at org.hibernate.search.Version.<clinit>(Version.java:40)
at
org.hibernate.search.impl.SearchFactoryImpl.<clinit>(SearchFactoryImpl.java:102)
at org.infinispan.query.backend.QueryHelper.<init>(QueryHelper.java:104)
at org.infinispan.demo.InfinispanDemo$10.run(InfinispanDemo.java:377)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)
Caused by: java.lang.ClassNotFoundException:
org.slf4j.impl.StaticLoggerBinder
at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
... 13 more
If I change the scope of slf4j-log4j12 to default scope in
infinispan-query's pom, the problem disappears.
Probably I miss something on the maven behaviour or something like it. But
maybe the scope is incorrect.
thanks!
16 years
Standardising on property names and system parameters
by Manik Surtani
Guys,
I have seen a number of places in the codebase where we take in system parameters. In some cases this is to control certain unit test options such as:
http://fisheye.jboss.org/browse/Infinispan/trunk/cachestore/jdbc/src/test...
http://fisheye.jboss.org/browse/Infinispan/trunk/cachestore/cloud/src/int...
http://fisheye.jboss.org/browse/Infinispan/trunk/core/src/test/java/org/i...
And in some cases these control runtime options such as:
http://fisheye.jboss.org/browse/Infinispan/trunk/core/src/main/java/org/i...
http://fisheye.jboss.org/browse/Infinispan/trunk/server/rest/src/main/sca...
http://fisheye.jboss.org/browse/Infinispan/trunk/server/core/src/main/sca...
And we occasionally use Properties to configure certain bits, such as certain Hot Rod and Memcached server options:
http://fisheye.jboss.org/browse/Infinispan/trunk/server/core/src/main/sca...
And even Hot Rod client configs.
http://fisheye.jboss.org/browse/Infinispan/trunk/client/hotrod-client/src...
And here are some examples of what the keys to these properties are:
infinispan.jclouds.username
infinispan.jdbc
infinispan.tm
infinispan.config.schema
infinispan.server.rest.cfg
program.name
infinispan.server.host
infinispan.hotrod-client.servers-default
I would like to standardise on these a bit. It would (a) make it easier to document and (b) provide a greater level of consistency. So here is what I propose:
* All system and property keys start with "infinispan."
* Properties destined to control the way the test suite runs should have ".test."
* The next bit should be the relevant affected module. E.g., ".server.hotrod." or ".server.rest." or ".client.hotrod.", or ".server." for stuff that is common across all server endpoints.
* and the last bit could be descriptive to what the key controls. E.g., ".host".
So, from above, the examples would look like:
infinispan.test.cachestore.jclouds.username
infinispan.test.cachestore.jdbc.driver
infinispan.test.core.tm
infinispan.core.config.schema
infinispan.server.cfg
(program.name? Don't know what this is... )
infinispan.server.host
infinispan.client.hotrod.servers
What do you guys think? If we agree on this, this would involve:
1) Read the correct, new property
2) Still read the "legacy" property but spit out a warning
3) Update READMEs, javadocs, sample scripts, and wikis/FAQs.
and then we would need to stick with this convention for all future stuff.
Thoughts?
Cheers
Manik
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
16 years
HotRodMarshaller interface
by Manik Surtani
Guys,
I just created ISPN-532 (HotRodMarshaller needs cleaning up) targeted for Radegast CR2 and Final. I know it is late in the day to be making API changes in an interface, but I would much rather this is done right prior to being baked into Final and hence eternity. :)
http://fisheye.jboss.org/browse/Infinispan/trunk/client/hotrod-client/src...
So I have 3 issues to address with this interface.
1. Methods on the interface
The purpose of this is simple: the 2 methods, readObject() and marshallObject() are meant to perform diametrically opposed tasks (byte[] -> object in one case, object -> byte[] in the other) but the names are far from that.
I propose either of the following:
1) readObject() and writeObject()
2) Simply, read() and write()
3) Or if we want to follow org.infinispan.marshall.Marshaller conventions, objectFromByteBuffer(), objectToByteBuffer()
My preference would be (3).
2. Interface name and package
Further, any reason why we call this HotRodMarshaller? Isn't it just a marshaller that serializes arbitrary objects <--> byte[] and should contain no HotRod-specific logic? I can see why we did not use the org.infinispan.marshall.Marshaller interface for this (too complex?) but perhaps we could create a org.infinispan.marshall.BasicMarshaller which just contains objectFromByteBuffer() and objectToByteBuffer(), and Marshaller can extend BasicMarshaller for Infinispan's internals and HotRod clients can directly implement BasicMarshaller?
This would allow people who write custom marshallers to reuse them for both the HotRod client as well as for Infinispan's internal marshalling.
3. isKeyHint parameter on marshallObject()
What is this for? And surely there is a more elegant/generic way to achieve this?
Cheers
Manik
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
16 years
DIST_SYNC behaving as async
by Sanne Grinovero
Hello,
I'm attempting to debug a cache which should be configured in sync,
but doesn't pass this trivial test when using the latest 4.1 snapshot:
nodeOne.put("key1", Integer.valueOf(7));
assert Integer.valueOf(7).equals(nodeTwo.get("key1")) ;
unless I introduce a short delay between the put and the get.
Of course when debugging it won't fail, I see the picked configuration
is the correct one;
I see useReplQueue=false, mode = DIST_SYNC, and the following interceptor chain:
>> org.infinispan.interceptors.InvocationContextInterceptor
>> org.infinispan.interceptors.CacheMgmtInterceptor
>> org.infinispan.interceptors.DistTxInterceptor
>> org.infinispan.interceptors.NotificationInterceptor
>> org.infinispan.interceptors.CacheLoaderInterceptor
>> org.infinispan.interceptors.DistCacheStoreInterceptor
>> org.infinispan.interceptors.DistLockingInterceptor
>> org.infinispan.interceptors.DistributionInterceptor
>> org.infinispan.interceptors.CallInterceptor
any ideas to what else I could check?
thanks,
Sanne
16 years
logs in test
by Mircea Markus
Hi *,
Test-logging was improved to use "nicer" names for jgroups nodes:
"(Incoming-2,Infinispan-Cluster,AAAAA-63786) Received new cluster view: [AAAAA-63786|1] [AAAAA-63786, BBBBB-32445]"
Notice the AAAAA and BBBB, this gives a clue on node's position in the jgroups view and should make logs easier to follow.
Cheers,
Mircea
16 years
Flags ignored during batch operations
by Sanne Grinovero
Hello,
I was quite surprised to hit a timeout on lock acquire on a method
flagged with SKIP_LOCKING.
Debugging I've found that in case a batch operation is running and no
transaction is active org.infinispan.interceptors.BatchingInterceptor
creates a new InvocationContext, ignoring the existing one, and so the
invocation proceeds but the flags I defined are cleared.
What is the reason to create a new InvocationContext? Could that be
changed to at least carry over the defined flags?
I've been playing with it by using setFlags(existingFlags) and have
already experienced another little performance boost with Lucene,
especially as it's now respecting SKIP_REMOTE_LOOKUP too, but I'm not
going to change this without understanding.
Sanne
16 years
