Re: [infinispan-dev] Infinispan xsite perf test demo
Thanks Bela, I enjoyed the demo! I suggest adding some sort of visualization (maybe just a few diagrams within the demo) of what is actually happening with the data would help understanding for users who are just starting with xsite. Rado On 14/12/12 12:09, Bela Ban wrote: FYI, I've uploaded a 10-minute video [1] to YouTube showing how I setup and run a perf test for Infinispan xsite replication [2]. The test (including all configuration) is available at [3]. This was run with a snapshot of Infinispan (roughly 5.2.0.Beta6) and JGroups 3.3.0.Alpha1. Enjoy ! [1] http://www.youtube.com/watch?v=owOs430vLZo [2] https://docs.jboss.org/author/display/ISPN/Cross+site+replication [3] https://github.com/belaban/IspnPerfTest ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] HotRod server and Rolling Upgrades
Even then, #2 would only be a temporary solution until we have #4, right? Would https://issues.jboss.org/browse/ISPN-2281 help in any way? - M On 11 Dec 2012, at 17:37, Dennis Reed der...@redhat.com wrote: I don't like #1. Seems more complicated, harder to maintain debug than the others. In my opinion the best option would be #4 (eliminate the different formats), but that probably can't be done in a minor release? Between 2 and 3, I'd prefer #2, handling it in the base class so it's automatically inherited by any custom classes that extend it. Since the use case isn't limited to rolling upgrades; you could have a HotRod cache with a full-time RemoteCacheStore. -Dennis On 12/11/2012 07:02 AM, Tristan Tarrant wrote: So, I thought we had everything ready to go for HotRod rolling upgrades: have HotRod server full of data (the source) configure a new HotRod server (the target) with a RemoteCacheStore pointing to the source (using rawValues) clients switch over to the target server which on cache misses should seamlessly fetch entries from the source issue a dump keys on the source fetch the dumped keys from the target disable the RCS on the target and switch off the source for good PROFIT$$$ Unfortunately there is a teeny tiny flaw in the plan: entries in a HotRod-managed cache are ByteArrayKey/CacheValue pairs and unfortunately, when the target reads from the RCS they get unwrapped into their byte[] equivalents. The solutions we have are: have a special marshaller placed on the RemoteCacheStore's RemoteCacheManager which rewraps the entries. Unfortunately marshallers can't distinguish between keys and values, so this would probably require some horrid ThreadLocal trickery Add a new option to RemoteCacheStore so that it rewraps entries in the ByteArrayKey/CacheValue format. Unfortunately the CacheValue class is part of server-core, but the dependency could be made optional, and in the context of the Rolling Upgrade scenario it is a non-issue, since it will be in the classpath Introduce a new MigrationRemoteCacheStore which does the same as the above, but without changing RCS itself. My personal favourite is number 2, but I trust your better judgement. I think these are merely workarounds and we should have a better way for entry wrappers (such as the cache servers) to localize the entries for their own particular needs. Also I believe we need a better way to attach metadata to entries in a portable way so that we don't need these value wrappers. Tristan ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Manik Surtani ma...@jboss.org twitter.com/maniksurtani Platform Architect, JBoss Data Grid http://red.ht/data-grid ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] HotRod server and Rolling Upgrades
I would really like ISPN-2281 to be solved by the proper solution, i.e. attach any additional metadata required by the servers (or any other data enricher) to the InternalCacheEntry and not as part of the value itself. Metadata would be some kind of sparse structure whose values could also be inherited implicitly by Cache-level metadata (to save memory). Let's think about data typing: a string is a string is a string, and not some weirdly marshalled byte array (which may be influenced by Marshaller, protocol value wrapper, phase of the moon, etc). Protocols would say this is a string (e.g. REST via Content-type: text/plain, InVM by just storing a java.lang.String) and the server would store it in an as-native-as-possible format, recording the type along with it. When someone retrieves it it needs to be translated to something the client understands. Obviously if I'm going to have a Cache of Strings, that metadata would be global to the cache and entries would not have that information. Was this ever planned ? Canned ? Banned ? Tristan On 12/14/2012 01:14 PM, Manik Surtani wrote: Even then, #2 would only be a temporary solution until we have #4, right? Would https://issues.jboss.org/browse/ISPN-2281 help in any way? - M On 11 Dec 2012, at 17:37, Dennis Reed der...@redhat.com mailto:der...@redhat.com wrote: I don't like #1. Seems more complicated, harder to maintain debug than the others. In my opinion the best option would be #4 (eliminate the different formats), but that probably can't be done in a minor release? Between 2 and 3, I'd prefer #2, handling it in the base class so it's automatically inherited by any custom classes that extend it. Since the use case isn't limited to rolling upgrades; you could have a HotRod cache with a full-time RemoteCacheStore. -Dennis On 12/11/2012 07:02 AM, Tristan Tarrant wrote: So, I thought we had everything ready to go for HotRod rolling upgrades: * have HotRod server full of data (the source) * configure a new HotRod server (the target) with a RemoteCacheStore pointing to the source (using rawValues) * clients switch over to the target server which on cache misses should seamlessly fetch entries from the source * issue a dump keys on the source * fetch the dumped keys from the target * disable the RCS on the target and switch off the source for good * PROFIT$$$ Unfortunately there is a teeny tiny flaw in the plan: entries in a HotRod-managed cache are ByteArrayKey/CacheValue pairs and unfortunately, when the target reads from the RCS they get unwrapped into their byte[] equivalents. The solutions we have are: 1. have a special marshaller placed on the RemoteCacheStore's RemoteCacheManager which rewraps the entries. Unfortunately marshallers can't distinguish between keys and values, so this would probably require some horrid ThreadLocal trickery 2. Add a new option to RemoteCacheStore so that it rewraps entries in the ByteArrayKey/CacheValue format. Unfortunately the CacheValue class is part of server-core, but the dependency could be made optional, and in the context of the Rolling Upgrade scenario it is a non-issue, since it will be in the classpath 3. Introduce a new MigrationRemoteCacheStore which does the same as the above, but without changing RCS itself. My personal favourite is number 2, but I trust your better judgement. I think these are merely workarounds and we should have a better way for entry wrappers (such as the cache servers) to localize the entries for their own particular needs. Also I believe we need a better way to attach metadata to entries in a portable way so that we don't need these value wrappers. Tristan ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org mailto:infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Manik Surtani ma...@jboss.org mailto:ma...@jboss.org twitter.com/maniksurtani http://twitter.com/maniksurtani Platform Architect, JBoss Data Grid http://red.ht/data-grid ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
[infinispan-dev] Failing test in Query module
Hi all, I've just updated my Infinispan fork, and after running the tests for query module, found out that the org.infinispan.query.distributed.MultiNodeReplicatedTest.testIndexingWorkDistribution() is failing constantly. Just wanted to ask whether anyone is looking into it? The failure message is: org.infinispan.remoting.transport.jgroups.SuspectException: Suspected member: MultiNodeReplicatedTest-NodeD-48101 at org.infinispan.remoting.transport.AbstractTransport.parseResponseAndAddToResponseList(AbstractTransport.java:102) at org.infinispan.remoting.transport.jgroups.JGroupsTransport.invokeRemotely(JGroupsTransport.java:541) at org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotely(RpcManagerImpl.java:179) at org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotely(RpcManagerImpl.java:201) at org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotely(RpcManagerImpl.java:258) at org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotely(RpcManagerImpl.java:245) at org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotely(RpcManagerImpl.java:240) at org.infinispan.remoting.rpc.RpcManagerImpl.broadcastRpcCommand(RpcManagerImpl.java:219) at org.infinispan.remoting.rpc.RpcManagerImpl.broadcastRpcCommand(RpcManagerImpl.java:211) at org.infinispan.interceptors.ReplicationInterceptor.handleCrudMethod(ReplicationInterceptor.java:273) at org.infinispan.interceptors.ReplicationInterceptor.visitPutKeyValueCommand(ReplicationInterceptor.java:242) at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:77) at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118) at org.infinispan.interceptors.EntryWrappingInterceptor.invokeNextAndApplyChanges(EntryWrappingInterceptor.java:249) at org.infinispan.interceptors.EntryWrappingInterceptor.visitPutKeyValueCommand(EntryWrappingInterceptor.java:162) at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:77) at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118) at org.infinispan.query.backend.QueryInterceptor.visitPutKeyValueCommand(QueryInterceptor.java:127) at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:77) at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118) at org.infinispan.interceptors.locking.NonTransactionalLockingInterceptor.visitPutKeyValueCommand(NonTransactionalLockingInterceptor.java:82) at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:77) at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118) at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:132) at org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:62) at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:77) at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118) at org.infinispan.statetransfer.StateTransferInterceptor.handleTopologyAffectedCommand(StateTransferInterceptor.java:215) at org.infinispan.statetransfer.StateTransferInterceptor.handleWriteCommand(StateTransferInterceptor.java:193) at org.infinispan.statetransfer.StateTransferInterceptor.visitPutKeyValueCommand(StateTransferInterceptor.java:136) at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:77) at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118) at org.infinispan.interceptors.CacheMgmtInterceptor.visitPutKeyValueCommand(CacheMgmtInterceptor.java:127) at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:77) at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118) at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:128) at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:92) at org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:62) at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:77) at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:343) at org.infinispan.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1146) at org.infinispan.CacheImpl.putInternal(CacheImpl.java:744)
Re: [infinispan-dev] 5.2.0.Beta6 schedule
On 13 Dec 2012, at 18:14, Mircea Markus wrote: https://github.com/infinispan/infinispan/pull/1503 ^^^ this is the last remaining pice, which contains a bunch of NBST critical fixes, so we agreed (thanks Martin) to release with this in on Dec 17 Monday (lunch time). Cheers, -- Mircea Markus Infinispan lead (www.infinispan.org) ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] Infinispan xsite perf test demo
That was very very nice to see. Assuming you also asked for feedback to improve this as a talk: 1# you stress several times that reads are going to be local, so very fast. I think you meant local to the site ? as some ~33% of entries will need to be fetched from peers on the same site. 2# you aren't actually running this on multiple sites are you? When pointing out the different IP addresses you say something about needing them to be different, but I didn't understand if you needed them different because they are in different places, or to separate otherwise local machines to have them appear as in different places. 3# Since get operations are always local (site), they are as you say not meaningful for the benchmark; now since put operations are also not meaningful as it's async .. what is the benchmark measuring? 4# There seems to be some degree of redundancy when explaining LON/SFO/NYC setting as the local site vs the backup sites. Wouldn't it make more sense to be able to configure all backup sites the same and have it automatically ignore the self element as a backup site? So your script would only need to specify what the local site is. If that makes any sense it would even be nice to extend this to the IP addresses being defined in the zones area, so that they are applied both to the JGroups configuration for the local cluster and to the bridge configuration. 5# I was initially surprised to see x-site configuration as part of a cache configuration; I understand the reasons for options like strategy which one might want to specify differently on each cache, but what about take offline ? that sounds more something which should be globally managed at the channel level - not sure if in JGroups directly but if it's to be handled in Infinispan I would expect to have all caches use the same policy, consistent with FD. Also it doesn't looks like you have much of a choice in to which sites you want to replicate, as relay is setup at the jgroups level so affecting all caches: is relay going to be ignored by caches having no x-site enabled? And is it going to be relayed only to one site if the Infinispan configuration lists a single site? Not sure if this makes any sense, I just found it contrasting with my naive expectations of how such a configuration would look like. thanks a lot, I hope this is proof enough that your video was pretty catchy :) Cheers, Sanne On 14 December 2012 11:47, Radoslav Husar rhu...@redhat.com wrote: Thanks Bela, I enjoyed the demo! I suggest adding some sort of visualization (maybe just a few diagrams within the demo) of what is actually happening with the data would help understanding for users who are just starting with xsite. Rado On 14/12/12 12:09, Bela Ban wrote: FYI, I've uploaded a 10-minute video [1] to YouTube showing how I setup and run a perf test for Infinispan xsite replication [2]. The test (including all configuration) is available at [3]. This was run with a snapshot of Infinispan (roughly 5.2.0.Beta6) and JGroups 3.3.0.Alpha1. Enjoy ! [1] http://www.youtube.com/watch?v=owOs430vLZo [2] https://docs.jboss.org/author/display/ISPN/Cross+site+replication [3] https://github.com/belaban/IspnPerfTest ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] Infinispan xsite perf test demo
Great stuff Bela! Btw, is xsite replication bidirectional? LON has SFO as backup, and SFO also has LON as backup. On Fri, Dec 14, 2012 at 8:01 PM, Sanne Grinovero sa...@infinispan.orgwrote: That was very very nice to see. Assuming you also asked for feedback to improve this as a talk: 1# you stress several times that reads are going to be local, so very fast. I think you meant local to the site ? as some ~33% of entries will need to be fetched from peers on the same site. 2# you aren't actually running this on multiple sites are you? When pointing out the different IP addresses you say something about needing them to be different, but I didn't understand if you needed them different because they are in different places, or to separate otherwise local machines to have them appear as in different places. 3# Since get operations are always local (site), they are as you say not meaningful for the benchmark; now since put operations are also not meaningful as it's async .. what is the benchmark measuring? 4# There seems to be some degree of redundancy when explaining LON/SFO/NYC setting as the local site vs the backup sites. Wouldn't it make more sense to be able to configure all backup sites the same and have it automatically ignore the self element as a backup site? So your script would only need to specify what the local site is. If that makes any sense it would even be nice to extend this to the IP addresses being defined in the zones area, so that they are applied both to the JGroups configuration for the local cluster and to the bridge configuration. 5# I was initially surprised to see x-site configuration as part of a cache configuration; I understand the reasons for options like strategy which one might want to specify differently on each cache, but what about take offline ? that sounds more something which should be globally managed at the channel level - not sure if in JGroups directly but if it's to be handled in Infinispan I would expect to have all caches use the same policy, consistent with FD. Also it doesn't looks like you have much of a choice in to which sites you want to replicate, as relay is setup at the jgroups level so affecting all caches: is relay going to be ignored by caches having no x-site enabled? And is it going to be relayed only to one site if the Infinispan configuration lists a single site? Not sure if this makes any sense, I just found it contrasting with my naive expectations of how such a configuration would look like. thanks a lot, I hope this is proof enough that your video was pretty catchy :) Cheers, Sanne On 14 December 2012 11:47, Radoslav Husar rhu...@redhat.com wrote: Thanks Bela, I enjoyed the demo! I suggest adding some sort of visualization (maybe just a few diagrams within the demo) of what is actually happening with the data would help understanding for users who are just starting with xsite. Rado On 14/12/12 12:09, Bela Ban wrote: FYI, I've uploaded a 10-minute video [1] to YouTube showing how I setup and run a perf test for Infinispan xsite replication [2]. The test (including all configuration) is available at [3]. This was run with a snapshot of Infinispan (roughly 5.2.0.Beta6) and JGroups 3.3.0.Alpha1. Enjoy ! [1] http://www.youtube.com/watch?v=owOs430vLZo [2] https://docs.jboss.org/author/display/ISPN/Cross+site+replication [3] https://github.com/belaban/IspnPerfTest ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
