mux usage
by Ales Justin
Could be that I don't fully understand how this mux stuff should work. :-)
As we've been busting heads since Friday ...
This is the code (see below) that sets up dispatcher, and sets the listener.
As you can see I add the msg listener to dispatcher.
And I use dispatcher's ::getProtocolAdapter to setup UpHandler for mux_id.
I then expect the following:
* slave tries sending the msg to master
* this dispatcher adds mux_id / scopeId to the msg
* on master, dispatcher's msg listener should pick up this msg
The problem is that our msg listener is never hit,
meaning no slave msgs are ever received.
Any idea what we're doing wrong or what's missing?
-Ales
---
UpHandler handler = channel.getUpHandler();
if (handler instanceof Muxer) {
Short n = (Short) props.get(MUX_ID);
if (n == null) {
throw new IllegalArgumentException("Missing mux id!");
}
@SuppressWarnings("unchecked")
Muxer<UpHandler> muxer = (Muxer<UpHandler>) handler;
if (muxer.get(n) != null) {
throw new IllegalArgumentException("Muxer with id " + n + " already used!");
}
muxId = n;
ClassLoader cl = (ClassLoader) props.get(CLASSLOADER);
MessageListener wrapper = (cl != null) ? new ClassloaderMessageListener(listener, cl) : listener;
MessageDispatcher dispatcher = new MuxMessageDispatcher(muxId, channel, wrapper, listener, null);
muxer.add(muxId, dispatcher.getProtocolAdapter());
sender = new DispatcherMessageSender(dispatcher);
11 years, 11 months
hs + read past eol
by Ales Justin
@Sanne: looks like a known issue: https://community.jboss.org/thread/197903?tstart=0
I'm using SNAPSHOT of Ispan 5.2 (up master) and HS 4.2. (my tmp-jgroups-mux branch).
With Lucene 3.5.
Any idea?
> ---
>
> Although I see a bunch of errors --- Sanne?
>
> 23:27:20,577 ERROR [org.hibernate.search.exception.impl.LogErrorHandler] (Hibernate Search: Index updates queue processor for index default_test__com.google.appengine.api.datastore.Entity-1) HSEARCH000058: Exception occurred java.io.IOException: Read past EOF
> Primary Failure:
> Entity com.google.appengine.api.datastore.Entity Id T:com.google.appengine.api.datastore.Key:agR0ZXN0cikLEiJfX29yZy5qYm9zcy5jYXBlZHdhcmYuTG9nUmVxdWVzdF9fGJACDA Work Type org.hibernate.search.backend.UpdateLuceneWork
> : java.io.IOException: Read past EOF
> at org.infinispan.lucene.SingleChunkIndexInput.readByte(SingleChunkIndexInput.java:77)
> at org.apache.lucene.store.ChecksumIndexInput.readByte(ChecksumIndexInput.java:41)
> at org.apache.lucene.store.DataInput.readInt(DataInput.java:84)
> at org.apache.lucene.index.SegmentInfos.read(SegmentInfos.java:272)
> at org.apache.lucene.index.IndexFileDeleter.<init>(IndexFileDeleter.java:182)
> at org.apache.lucene.index.IndexWriter.<init>(IndexWriter.java:1178)
> at org.hibernate.search.backend.impl.lucene.IndexWriterHolder.createNewIndexWriter(IndexWriterHolder.java:127)
> at org.hibernate.search.backend.impl.lucene.IndexWriterHolder.getIndexWriter(IndexWriterHolder.java:102)
> at org.hibernate.search.backend.impl.lucene.AbstractWorkspaceImpl.getIndexWriter(AbstractWorkspaceImpl.java:119)
> at org.hibernate.search.backend.impl.lucene.LuceneBackendQueueTask.applyUpdates(LuceneBackendQueueTask.java:99)
> at org.hibernate.search.backend.impl.lucene.LuceneBackendQueueTask.run(LuceneBackendQueueTask.java:67)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) [classes.jar:1.6.0_31]
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) [classes.jar:1.6.0_31]
> at java.util.concurrent.FutureTask.run(FutureTask.java:138) [classes.jar:1.6.0_31]
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [classes.jar:1.6.0_31]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [classes.jar:1.6.0_31]
> at java.lang.Thread.run(Thread.java:680) [classes.jar:1.6.0_31]
>
11 years, 11 months
Re: [infinispan-dev] removing Cache::with(CL)
by Paul Ferraro
The details of the query module are a little out of my realm of
experience. I'm CC'ing infinispan-dev, to open up the larger discussion
to classloading and compatibility with modular environments.
Off the top of my head, it seems like you need a custom
KeyTransformationHandler that can resolve classes using a ModuleLoader
(i.e. module ID + class name). Thoughts?
Paul
On Thu, 2012-05-10 at 23:10 +0200, Ales Justin wrote:
> If I do <subject> I get this CNFE, see below.
>
> Looks like I still need a combination of Cache::with(CL) -- so this code sees Key class,
> and at the same time I don't want Infinispan to depend on GAE API.
> Where I also need to have SML as ClassResolver.
>
> Are you sure setting CL on Cache breaks ClassResolver?
>
> -Ales
>
> ---
>
> 23:00:50,321 ERROR [org.infinispan.query.backend.KeyTransformationHandler] (http-/192.168.1.101:8080-2) ISPN014001: Could not locate key class com.google.appengine.api.datastore.Key: java.lang.ClassNotFoundException: com.google.appengine.api.datastore.Key
> at java.net.URLClassLoader$1.run(URLClassLoader.java:202) [classes.jar:1.6.0_31]
> at java.security.AccessController.doPrivileged(Native Method) [classes.jar:1.6.0_31]
> at java.net.URLClassLoader.findClass(URLClassLoader.java:190) [classes.jar:1.6.0_31]
> at java.lang.ClassLoader.loadClass(ClassLoader.java:306) [classes.jar:1.6.0_31]
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301) [classes.jar:1.6.0_31]
> at java.lang.ClassLoader.loadClass(ClassLoader.java:247) [classes.jar:1.6.0_31]
> at java.lang.Class.forName0(Native Method) [classes.jar:1.6.0_31]
> at java.lang.Class.forName(Class.java:247) [classes.jar:1.6.0_31]
> at org.infinispan.util.Util.loadClassStrict(Util.java:127) [infinispan-core-5.2.0-SNAPSHOT.jar:5.2.0-SNAPSHOT]
> at org.infinispan.query.backend.KeyTransformationHandler.getCustomTransformer(KeyTransformationHandler.java:108)
> at org.infinispan.query.backend.KeyTransformationHandler.stringToKey(KeyTransformationHandler.java:96)
> at org.infinispan.query.impl.CacheQueryImpl.fromEntityInfosToKeys(CacheQueryImpl.java:174)
> at org.infinispan.query.impl.CacheQueryImpl.iterator(CacheQueryImpl.java:144)
> at org.infinispan.query.impl.CacheQueryImpl.iterator(CacheQueryImpl.java:137)
> at org.jboss.capedwarf.datastore.query.PreparedQueryImpl.createQueryIterator(PreparedQueryImpl.java:108) [capedwarf-datastore-1.0.0-SNAPSHOT.jar:1.0.0-SNAPSHOT]
> at org.jboss.capedwarf.datastore.query.PreparedQueryImpl.asQueryResultIterator(PreparedQueryImpl.java:73) [capedwarf-datastore-1.0.0-SNAPSHOT.jar:1.0.0-SNAPSHOT]
> at org.jboss.capedwarf.datastore.query.PreparedQueryImpl.asIterator(PreparedQueryImpl.java:64) [capedwarf-datastore-1.0.0-SNAPSHOT.jar:1.0.0-SNAPSHOT]
> at org.jboss.capedwarf.datastore.query.PreparedQueryImpl.asIterator(PreparedQueryImpl.java:60) [capedwarf-datastore-1.0.0-SNAPSHOT.jar:1.0.0-SNAPSHOT]
> at org.jboss.test.capedwarf.datastore.test.PreparedQueryTestCase.testAsIteratorWithOptionstestCountEntities(PreparedQueryTestCase.java:77) [classes:]
>
11 years, 11 months
Time for a tryLock() ?
by Galder Zamarreño
Looks like rolling back the transaction when a lock timeout is encountered can be problematic: https://community.jboss.org/message/731307#731307
Maybe time to implement a tryLock() that attempts to acquire the lock but does not rollback the transaction if it cannot acquire it?
Thoughts?
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
11 years, 12 months
Cluster wide node name uniqueness
by Thomas Fromm
Hi,
I've the requirement, that I need configurable cluster node names. These
names should be unique inside the cluster, new nodes with already
existing node names inside the cluster should be rejected to joind the
cluster and should fail at startup with an appropiate exception.
Additional, because I need these names in case of view events, something
like CacheManager.getNodeName(Address address)
Its a bit tricky to realise that using only the ISPN API, so I'd prefer
that could be done inside ISPN.
Is this change request possible for 5.2? What o you think?
--tf
12 years
Why Externalizer does not need to extend java.io.Serializable
by Galder Zamarreño
Re: https://issues.jboss.org/browse/ISPN-2029
Just a heads up as a result of an interesting discussion with Paul Ferraro last night:
So far Externalizer interface has extended Serializable and last night I was trying to wonder why that was.
As you guys might remember (https://docs.jboss.org/author/x/PwY5), there's two type of externalizers: user friendly and advanced.
The user friendly ones do not require any pre-registration or anything and thanks to the ability of JBMAR to ship Externalizers to remote nodes, we can support such use case. However, this requires Externalizer impls to be Serializable or Externalizable somehow.
However, that requirement is not there for advanced externalizers cos these must be registered somehow, either via programmatic or XML configuration, so in these case there's no shipping of Externalizer impls at all.
So, I'm gonna remove 'implements Serializable' from org.infinispan.marshall.Externalizer and instead require that any user-friendly externalizers are marker as Serializable or similar.
I'll be making this change in master, but what about 5.1.x? This change is not urgent but clarifies what the externalizer serialization requirements are.
Cheers,
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
12 years
Script to speed up sending pull reqs for OSX
by Galder Zamarreño
Hi,
I've been playing around with a script to speed up pull req sends and I've come up with this for OSX:
#!/bin/sh
BRANCH=`git branch --no-color | sed -e '/^[^*]/d' -e 's/* \(.*\)/\1/'`
open -a "Google Chrome" -g https://github.com/galderz/infinispan/pull/new/${BRANCH}
Basically, takes your local branch and opens a new pull req in the current Google Chrome instance.
It probably can be enhanced further, thoughts?
Cheers,
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
12 years
