can we get replica IP from cache events ?
by Mohan Dhawan
Hi All,
Is it possible to find out which replica performed the cache operation
that generated the cache event ? In other words, can we get the IP of
the replica that modified the cache entry ? If yes, then how.
Any help is appreciated.
Regards,
mohan
11 years, 1 month
Re: [infinispan-dev] [hibernate-dev] [Search] @Transformable vs @ProvidedId
by Sanne Grinovero
There is an additional complex choice to make.
Considering that Infinispan has this separate notion of Key vs Value, and
both have to contribute to building the final indexed Document, why is it
that we allow the decision of which index is being targeted to be made by
*the type of the value*?
I think the index definition belongs as a responsibility to the *type of
the identifier*, the value should at most help to identify a shard among
the ones identified by its key.
!!! ->
We might want to consider imposing a hard limitation of not allowing a
single index to be shared across multiple key types. This implies the
@Indexed annotation and its other key options should be defined on the
keys, not the values.
If we did that, it wouldn't matter if the index is defined on the key or on
the value as there would be a 1:1 possible combination.
Does anyone see this as a strong limitation or usability concern?
This would also resolve a couple of performance problems.
Beyond this, considering it's valid (and sometimes useful) to store
PersonFile p = ...
cache.put( p.taxcode, p );
cache.put( p.uniquename, p );
As a user I think I might even want to define an alternative index mapping
for PersonFile, depending on if it's being stored by uniquename or by
taxcode.
That's totally doable with the Search engine, but how do you envision the
user to define this mapping? He can't use annotations on PersonFile, so the
user needs to be able to register some form of programmatic mapping linked
to the different key types.
There is an additional flaw, which is that I'm implying that taxcode and
uniquname are of a different type: otherwise we couldn't distinguish the
two different meanings of the two put operations. This is generally a fair
assumption as you wouldn't want to have key collisions if you're storing in
such a fashion, but there might be a known business rule for which such a
collision is impossible (i.e. the two codes having a different format). So
while you probably shouldn't do this in a strong domain, it's a legal usage
of the Cache API.
Considering these pitfalls I think I have successfully convinced myself
that we should not allow for a different mapping for the same type of key.
Question remains if it's more correct to bind the index identification (the
name) to the key type.
@Hardy yes I will need the Infinispan team's thoughts too, but don't feel
excluded, there aren't many smart engineers around knowing about the
Infinispan/Query usage :)
Cheers,
Sanne
On 7 August 2014 22:50, Hardy Ferentschik <hardy(a)hibernate.org> wrote:
>
> On 7 Jan 2014, at 23:42, Sanne Grinovero <sanne(a)hibernate.org> wrote:
>
> >
> >
> >
> > On 7 August 2014 22:37, Hardy Ferentschik <hardy(a)hibernate.org> wrote:
> >
> > On 7 Jan 2014, at 19:56, Sanne Grinovero <sanne(a)hibernate.org> wrote:
> >
> > > I was hoping to drop @ProvidedId today as the original "marker"
> > > functionality is no longer needed: since we have
> > >
> > >
> org.hibernate.search.cfg.spi.SearchConfiguration.isIdProvidedImplicit()
> > >
> > > the option can be implicitly applied to all indexed entries, and the
> > > annotation is mostly redundant in Infinispan since we added this.
> > >
> > > But actually it turns out it's a bit more complex as it servers a
> second
> > > function as well: it's the only way for users to be able to specify a
> > > FieldBridge for the ID.. so the functionality of this annotation is not
> > > consumed yet.
> >
> > Wouldn’t an additional explicit @FieldBridge annotation work as well?
> >
> > Yes! But we'd need to apply it to the key type.
> > This implies changing it to allow target @Target(TYPE), which doesn't
> make much sense for our ORM users, but also the name "FieldBridge" is
> rather odd to be applied on a type and not a field.
>
> Fair enough. I also know too little about the Infinispan usage of Search
> in this case.
> Either way, @ProvidedId should go, at least from a pure Search point of
> view.
>
> —Hardy
>
>
11 years, 2 months
Re: [infinispan-dev] [hibernate-dev] [Search] @Transformable vs @ProvidedId
by Sanne Grinovero
On 7 August 2014 22:37, Hardy Ferentschik <hardy(a)hibernate.org> wrote:
>
> On 7 Jan 2014, at 19:56, Sanne Grinovero <sanne(a)hibernate.org> wrote:
>
> > I was hoping to drop @ProvidedId today as the original "marker"
> > functionality is no longer needed: since we have
> >
> > org.hibernate.search.cfg.spi.SearchConfiguration.isIdProvidedImplicit()
> >
> > the option can be implicitly applied to all indexed entries, and the
> > annotation is mostly redundant in Infinispan since we added this.
> >
> > But actually it turns out it's a bit more complex as it servers a second
> > function as well: it's the only way for users to be able to specify a
> > FieldBridge for the ID.. so the functionality of this annotation is not
> > consumed yet.
>
> Wouldn’t an additional explicit @FieldBridge annotation work as well?
>
Yes! But we'd need to apply it to the key type.
This implies changing it to allow target @Target(TYPE), which doesn't make
much sense for our ORM users, but also the name "FieldBridge" is rather odd
to be applied on a type and not a field.
11 years, 2 months
Re: [infinispan-dev] DIST-SYNC, put(), a problem and a solution
by А Оленев
Guys,
Am I right that you trying to break CAP theorem? Seems like that because
you want to have consistent backups (end of cache.put() means that primary
node and all backups have the same value) and non-blocking behaviour (from
user's POV).
Sorry if I'm wrong.
Cheers
Alexey
11 years, 2 months
Weird ClassCastException ..
by Sanne Grinovero
I'm (rarely) seeing this exception in one of my stress tests.. any
clue about what could be wrong?
I reported a similar one approx a year ago, in that case it was a
value type being unmarshalled as an instance of Class (was also never
resolved).
2014-08-05 00:22:29,521 WARN [CommandAwareRpcDispatcher]
(OOB-1,main-NodeD-22196) ISPN000220: Problems un-marshalling remote
command from byte buffer
java.lang.ClassCastException: java.lang.String cannot be cast to
org.infinispan.metadata.Metadata
at org.infinispan.commands.write.PutKeyValueCommand.setParameters(PutKeyValueCommand.java:114)
at org.infinispan.commands.RemoteCommandsFactory.fromStream(RemoteCommandsFactory.java:138)
at org.infinispan.marshall.exts.ReplicableCommandExternalizer.readObject(ReplicableCommandExternalizer.java:85)
at org.infinispan.marshall.exts.ReplicableCommandExternalizer.readObject(ReplicableCommandExternalizer.java:1)
at org.infinispan.marshall.core.ExternalizerTable$ExternalizerAdapter.readObject(ExternalizerTable.java:409)
at org.infinispan.marshall.core.ExternalizerTable.readObject(ExternalizerTable.java:214)
at org.infinispan.marshall.core.JBossMarshaller$ExternalizerTableProxy.readObject(JBossMarshaller.java:148)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:351)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:41)
at org.infinispan.marshall.exts.ReplicableCommandExternalizer.readParameters(ReplicableCommandExternalizer.java:101)
at org.infinispan.marshall.exts.CacheRpcCommandExternalizer.readObject(CacheRpcCommandExternalizer.java:153)
at org.infinispan.marshall.exts.CacheRpcCommandExternalizer.readObject(CacheRpcCommandExternalizer.java:1)
at org.infinispan.marshall.core.ExternalizerTable$ExternalizerAdapter.readObject(ExternalizerTable.java:409)
at org.infinispan.marshall.core.ExternalizerTable.readObject(ExternalizerTable.java:214)
at org.infinispan.marshall.core.JBossMarshaller$ExternalizerTableProxy.readObject(JBossMarshaller.java:148)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:351)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:41)
at org.infinispan.commons.marshall.jboss.AbstractJBossMarshaller.objectFromObjectStream(AbstractJBossMarshaller.java:135)
at org.infinispan.marshall.core.VersionAwareMarshaller.objectFromByteBuffer(VersionAwareMarshaller.java:101)
at org.infinispan.commons.marshall.AbstractDelegatingMarshaller.objectFromByteBuffer(AbstractDelegatingMarshaller.java:80)
at org.infinispan.remoting.transport.jgroups.MarshallerAdapter.objectFromBuffer(MarshallerAdapter.java:28)
at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:204)
at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:460)
at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:377)
at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:250)
at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:674)
at org.jgroups.JChannel.up(JChannel.java:733)
at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1030)
at org.jgroups.protocols.RSVP.up(RSVP.java:190)
at org.jgroups.protocols.FRAG2.up(FRAG2.java:165)
at org.jgroups.protocols.FlowControl.up(FlowControl.java:390)
at org.jgroups.protocols.tom.TOA.up(TOA.java:121)
at org.jgroups.protocols.pbcast.GMS.up(GMS.java:1041)
at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:234)
at org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1034)
at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:752)
at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:399)
at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:610)
at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:297)
at org.jgroups.protocols.Discovery.up(Discovery.java:245)
at org.jgroups.protocols.TP.passMessageUp(TP.java:1551)
at org.jgroups.protocols.TP$MyHandler.run(TP.java:1770)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
11 years, 2 months
Testsuite again...
by Pedro Ruivo
Hi,
OSGi integration tests are blocking the test suite. It is failing with:
java.lang.Exception: Could not start bundle
mvn:org.infinispan/infinispan-cachestore-jpa/7.0.0-SNAPSHOT in
feature(s) infinispan-cachestore-jpa-7.0.0-SNAPSHOT: Unresolved
constraint in bundle org.infinispan.cachestore-jpa [70]: Unable to
resolve 70.0: missing requirement [70.0] osgi.wiring.package;
(&(osgi.wiring.package=javax.persistence)(version>=2.1.0)(version<=2.1.0))
Also, the security integration test has a failure:
NodeAuthenticationKrbPassIT.testReadItemOnJoiningNode:71->AbstractNodeAuthentication.testReadItemOnJoiningNode:94
expected:<test_value> but was:<null>
Pedro
11 years, 2 months
Handling dynamic interdependencies of Hot Rod servers and filter/converters - Re: ISPN-3950
by Galder Zamarreño
Hi guys,
Re: https://issues.jboss.org/browse/ISPN-3950
The aim here is to enable deployment of custom Hot Rod filter/converter instances to Hot Rod servers running on top of WF, following a similar model to that used for JDBC drivers.
I came up with an initial solution in [1] but it’s incomplete because it can only handle a single Hot Rod server definition [2]. Digging through this issue has uncoverered a little can of worms:
- It’s possible not only to have N Hot Rod connectors (read: servers) defined in the configuration and they can be added at runtime too via CLI/RHQ.
- Deployments of filter/converters can happen anytime, so we’ve enabled Hot Rod servers to be plugged with these at runtime. For the time being, we’ve agreed that if a filter/converter gets deployed, it’ll be applied to all Hot Rod servers.
I had an earlier chat with Emmanuel and he suggested having some kind of deployment processor that deals with the filter/converter deployments and registers them in some service.
The fun begins now, from my POV, it seems to me that Hot Rod connectors need to depend on the filter/converter deployment tracking service so that if a new Hot Rod connector is added at runtime, it can take all the filter/converter deployments to self. However, the opposite is also plausible, that the filter/converter tracking service depends on all Hot Rod connector services, and that when a filter/converter is deployed, it can be applied to all running Hot Rod servers. This seems like a chicken and egg problem :|
What would be the best approach to handle these type of scenarios?
Cheers,
[1] https://github.com/galderz/infinispan/commit/0a3b37fdab05603654ee81d9ff38...
[2] https://github.com/infinispan/infinispan/pull/2742#discussion_r15750154
--
Galder Zamarreño
galder(a)redhat.com
twitter.com/galderz
11 years, 2 months
