November 2014 - infinispan-issues

[JBoss JIRA] (ISPN-5004) ProtobufMetadataManagerMBean should be located in infinispan-remote-query-client module

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-5004?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-5004: -------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/3091 > ProtobufMetadataManagerMBean should be located in infinispan-remote-query-client module > --------------------------------------------------------------------------------------- > > Key: ISPN-5004 > URL: https://issues.jboss.org/browse/ISPN-5004 > Project: Infinispan > Issue Type: Enhancement > Components: Remote Querying > Affects Versions: 7.0.0.Final > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 7.1.0.Alpha1 > > > It is currently located in infinispan-remote-query-server module, which is a mistake. Clients should not need to depend on the server module. > The interface should also be extended to add methods for retrieving the list of existing files and the errors status of each file. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4697) Single cache operation generates two sequential synchronous calls to the indexing engine

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4697?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4697: ----------------------------------------------- Adrian Nistor <anistor(a)redhat.com> changed the Status of [bug 1166648|https://bugzilla.redhat.com/show_bug.cgi?id=1166648] from NEW to MODIFIED > Single cache operation generates two sequential synchronous calls to the indexing engine > ---------------------------------------------------------------------------------------- > > Key: ISPN-4697 > URL: https://issues.jboss.org/browse/ISPN-4697 > Project: Infinispan > Issue Type: Enhancement > Components: Embedded Querying > Affects Versions: 7.0.0.Beta1 > Reporter: Sanne Grinovero > Assignee: Gustavo Fernandes > Fix For: 7.0.0.CR1 > > > For a similar reason as explained in ISPN-4650, the method > {{org.infinispan.query.backend.QueryInterceptor.processPutKeyValueCommand(PutKeyValueCommand, InvocationContext, Object, TransactionContext)}} > is likely to invoke a {{removeFromIndexes}} first and then an {{updateIndexes}}. > When using transactions, the {{transactionContext}} will enqueue both operations for execution in the same call to the backend, but when no transaction is in progress, this will generate two sequential and independent calls to the backend. > When the backend happens to be the {{InfinispanIndexManager}}, this implies we're generating two sequential synchronous RPCs rather than bacthing the two operations in a single Update statement: the first call is completely redundant in most cases, and can be incorporated in the second call for all remaining edge cases. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5004) ProtobufMetadataManagerMBean should be located in infinispan-remote-query-client module

by Adrian Nistor (JIRA)

Adrian Nistor created ISPN-5004: ----------------------------------- Summary: ProtobufMetadataManagerMBean should be located in infinispan-remote-query-client module Key: ISPN-5004 URL: https://issues.jboss.org/browse/ISPN-5004 Project: Infinispan Issue Type: Enhancement Components: Remote Querying Affects Versions: 7.0.0.Final Reporter: Adrian Nistor Assignee: Adrian Nistor Fix For: 7.1.0.Alpha1 It is currently located in infinispan-remote-query-server module, which is a mistake. Clients should not need to depend on the server module. The interface should also be extended to add methods for retrieving the list of existing files and the errors status of each file. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4904) PartitionHandlingInterceptor should not do checks when Flag.CACHE_MODE_LOCAL is supplied

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4904?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4904: ----------------------------------------------- Roman Macor <rmacor(a)redhat.com> changed the Status of [bug 1161783|https://bugzilla.redhat.com/show_bug.cgi?id=1161783] from ON_QA to VERIFIED > PartitionHandlingInterceptor should not do checks when Flag.CACHE_MODE_LOCAL is supplied > ---------------------------------------------------------------------------------------- > > Key: ISPN-4904 > URL: https://issues.jboss.org/browse/ISPN-4904 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 7.0.0.CR2 > Reporter: William Burns > Assignee: William Burns > Fix For: 7.0.0.Final > > > The PartitionHandlingInterceptor currently checks every key irrespective of flags. Since CACHE_MODE_LOCAL flag doesn't involve other nodes we should ignore these checks as the user must know what they are doing. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4890) Entry iterator should throw AvailabilityException in degraded mode

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4890?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4890: ----------------------------------------------- Roman Macor <rmacor(a)redhat.com> changed the Status of [bug 1161783|https://bugzilla.redhat.com/show_bug.cgi?id=1161783] from ON_QA to VERIFIED > Entry iterator should throw AvailabilityException in degraded mode > ------------------------------------------------------------------ > > Key: ISPN-4890 > URL: https://issues.jboss.org/browse/ISPN-4890 > Project: Infinispan > Issue Type: Bug > Components: Core, Test Suite - Core > Affects Versions: 7.0.0.CR2 > Reporter: Dan Berindei > Assignee: William Burns > Priority: Blocker > Labels: testsuite_stability > Fix For: 7.0.0.Final > > > When the distributed entry iterator gets a suspect exception, it assumes that the CH will be soon updated to remove the leaver, and retries to contact the primary owner of the segment. > But if the cache is in degraded mode, the consistent hash is no longer updated, and the entry iterator enters an infinite loop. > {noformat} > 11:58:35,622 TRACE (testng-DelayedAvailabilityUpdateTest:) [DistributedEntryRetriever] Request to NodeC-51013=[50, 51, 20, 52, 21, 53, 22, 54, 23, 24, 25, 26, 27, 28, 29] for cd886604-960b-431a-81a0-efbb51eed57f was suspect, must resend to a new node! > 11:58:35,622 TRACE (testng-DelayedAvailabilityUpdateTest:) [DistributedEntryRetriever] Request to NodeC-51013=[50, 51, 20, 52, 21, 53, 22, 54, 23, 24, 25, 26, 27, 28, 29] for cd886604-960b-431a-81a0-efbb51eed57f was suspect, must resend to a new node! > 11:58:35,622 TRACE (testng-DelayedAvailabilityUpdateTest:) [DistributedEntryRetriever] Request to NodeC-51013=[50, 51, 20, 52, 21, 53, 22, 54, 23, 24, 25, 26, 27, 28, 29] for cd886604-960b-431a-81a0-efbb51eed57f was suspect, must resend to a new node! > ... > {noformat} > This is visible when running the partition handling tests (e.g. DelayedAvailabilityUpdateTest) with trace logging enabled, as {{TestingUtil.killCaches()}} logs the cache contents at trace level. As an aside, {{TestingUtil.killCaches()}} should probably use {{Flag.CACHE_MODE_LOCAL}} to print only the entries on each node. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4792) RemoteClusterListener still invokes filter/converter

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4792?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4792: ----------------------------------------------- Roman Macor <rmacor(a)redhat.com> changed the Status of [bug 1154044|https://bugzilla.redhat.com/show_bug.cgi?id=1154044] from ON_QA to VERIFIED > RemoteClusterListener still invokes filter/converter > ---------------------------------------------------- > > Key: ISPN-4792 > URL: https://issues.jboss.org/browse/ISPN-4792 > Project: Infinispan > Issue Type: Enhancement > Components: Listeners > Affects Versions: 7.0.0.Beta2 > Reporter: William Burns > Assignee: William Burns > Fix For: 7.0.0.CR1 > > > When using a distributed cluster listener it installs a listener on each of the nodes to receive notifications. Cluster listeners only raise post events, but on remote nodes (ones where the listener wasn't originally installed) they invoke the filter and converter even on pre events which is not needed. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4871) Remove KeyValueFilterFactory and ConverterFactory to prevent confusion

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4871?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4871: ----------------------------------------------- Roman Macor <rmacor(a)redhat.com> changed the Status of [bug 1154044|https://bugzilla.redhat.com/show_bug.cgi?id=1154044] from ON_QA to VERIFIED > Remove KeyValueFilterFactory and ConverterFactory to prevent confusion > ---------------------------------------------------------------------- > > Key: ISPN-4871 > URL: https://issues.jboss.org/browse/ISPN-4871 > Project: Infinispan > Issue Type: Enhancement > Affects Versions: 7.0.0.CR2 > Reporter: William Burns > Assignee: William Burns > Fix For: 7.0.0.Final > > > When ISPN-4753 was added we moved to CacheEventFilterFactory and CacheEventConverterFactory. Thinking about this more it is confusing to have both factories when the one is not used currently. We should remove it. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4850) Allow for filter and conversion to be done in one step for cache listeners

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4850?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4850: ----------------------------------------------- Roman Macor <rmacor(a)redhat.com> changed the Status of [bug 1154044|https://bugzilla.redhat.com/show_bug.cgi?id=1154044] from ON_QA to VERIFIED > Allow for filter and conversion to be done in one step for cache listeners > -------------------------------------------------------------------------- > > Key: ISPN-4850 > URL: https://issues.jboss.org/browse/ISPN-4850 > Project: Infinispan > Issue Type: Enhancement > Components: Listeners > Affects Versions: 7.0.0.CR1 > Reporter: William Burns > Assignee: William Burns > Fix For: 7.0.0.Final > > > Currently the cache listeners can install a CacheEventFilter and CacheEventConverter to be used. However each one requires separate invocations. It would be desireable to have this done as a single invocation akin to what we did for ISPN-4640. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4697) Single cache operation generates two sequential synchronous calls to the indexing engine

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4697?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated ISPN-4697: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1166648 > Single cache operation generates two sequential synchronous calls to the indexing engine > ---------------------------------------------------------------------------------------- > > Key: ISPN-4697 > URL: https://issues.jboss.org/browse/ISPN-4697 > Project: Infinispan > Issue Type: Enhancement > Components: Embedded Querying > Affects Versions: 7.0.0.Beta1 > Reporter: Sanne Grinovero > Assignee: Gustavo Fernandes > Fix For: 7.0.0.CR1 > > > For a similar reason as explained in ISPN-4650, the method > {{org.infinispan.query.backend.QueryInterceptor.processPutKeyValueCommand(PutKeyValueCommand, InvocationContext, Object, TransactionContext)}} > is likely to invoke a {{removeFromIndexes}} first and then an {{updateIndexes}}. > When using transactions, the {{transactionContext}} will enqueue both operations for execution in the same call to the backend, but when no transaction is in progress, this will generate two sequential and independent calls to the backend. > When the backend happens to be the {{InfinispanIndexManager}}, this implies we're generating two sequential synchronous RPCs rather than bacthing the two operations in a single Update statement: the first call is completely redundant in most cases, and can be incorporated in the second call for all remaining edge cases. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4995) ClusteredGet served for non-member of CH

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-4995?page=com.atlassian.jira.plugin.... ] Dan Berindei commented on ISPN-4995: ------------------------------------ [~rvansa] in my example the second get is *causally after* the first get because, well, the user is doing it after the first get. If the order of the get operations didn't matter, you could ignore the order of the get operations in your example as well and it would be ok. > ClusteredGet served for non-member of CH > ---------------------------------------- > > Key: ISPN-4995 > URL: https://issues.jboss.org/browse/ISPN-4995 > Project: Infinispan > Issue Type: Bug > Components: Core, State Transfer > Reporter: Radim Vansa > Priority: Critical > > When nodes accept ClusteredGetCommand from node that is not member of CH, it can happen that when one thread does > {code} > put(K1, V1); > put(K2, V2) > {code} > and another gets > {code} > get(K2) -> V2 > get(K1) -> V0 (some old value) > {code} > edg-perf01, 02 and 03 share this view and topology: > {code} > 04:40:08,714 TRACE [org.jgroups.protocols.FD_SOCK] (INT-8,edg-perf01-63779) edg-perf01-63779: i-have-sock: edg-perf02-45117 --> 172.18.1.3:37476 (cache is {edg-perf01-63779=172.18.1.1:40099, edg-perf02-45117=172.18.1.3:37476}) > 04:40:08,715 TRACE [org.infinispan.topology.ClusterTopologyManagerImpl] (transport-thread--p2-t6) Received new cluster view: 8, isCoordinator = true, becameCoordinator = false > 04:40:11,203 DEBUG [org.infinispan.topology.LocalTopologyManagerImpl] (transport-thread--p2-t1) Updating local consistent hash(es) for cache testCache: new topology = CacheTopology{id=16, rebalanceId=4, currentC > H=DefaultConsistentHash{ns = 512, owners = (3)[edg-perf02-45117: 171+170, edg-perf03-6264: 171+171, edg-perf01-63779: 170+171]}, pendingCH=null, unionCH=null, actualMembers=[edg-perf02-45117, edg-perf03-6264, edg-perf01-63779]} > {code} > Later, edg-perf02 and edg-perf03 get new view and install a new topology, where edg-perf01 does not exist: > {code} > 04:41:13,681 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-2,edg-perf03-6264) ISPN000093: Received new, MERGED cluster view for channel default: MergeView::[edg-perf02-45117|9] (3) [edg-perf02-45117, edg-perf03-6264, edg-perf04-10989], 1 subgroups: [edg-perf04-10989|7] (1) [edg-perf04-10989] > 04:41:13,681 TRACE [org.infinispan.topology.ClusterTopologyManagerImpl] (transport-thread--p2-t22) Received new cluster view: 9, isCoordinator = false, becameCoordinator = false > 04:41:13,760 TRACE [org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher] (remote-thread--p3-t32) Attempting to execute non-CacheRpcCommand command: CacheTopologyControlCommand{cache=testCache, type=CH_UPDATE, sender=edg-perf02-45117, joinInfo=null, topologyId=18, rebalanceId=4, currentCH=DefaultConsistentHash{ns = 512, owners = (2)[edg-perf02-45117: 256+85, edg-perf03-6264: 256+86]}, pendingCH=null, availabilityMode=AVAILABLE, actualMembers=[edg-perf02-45117, edg-perf03-6264], throwable=null, viewId=9}[sender=edg-perf02-45117] > {code} > After that, edg-perf04 writes to {{key_00000000000020DB}} which is currently owned only by edg-perf03 - this key servers as K1 in example above. It is not backed up to edg-perf01, but edg-perf01 still thinks it's an owner of this key as it did not get any new view (this is a log from edg-perf03) : > {code} > 04:41:30,884 TRACE [org.infinispan.remoting.rpc.RpcManagerImpl] (remote-thread--p3-t45) edg-perf03-6264 invoking PutKeyValueCommand{key=key_00000000000020DB, value=[33 #4: 0, 169, 284, 634, ], flags=[SKIP_CACHE_LOAD, SKIP_REMOTE_LOOKUP], putIfAbsent=false, valueMatcher=MATCH_ALWAYS, metadata=EmbeddedMetadata{version=null}, successful=true} to recipient list [edg-perf03-6264] with options RpcOptions{timeout=60000, unit=MILLISECONDS, fifoOrder=true, totalOrder=false, responseFilter=null, responseMode=SYNCHRONOUS, skipReplicationQueue=false} > {code} > Later, edg-perf04 writes to another key {{stressor_33}} (K2 in the example) value with operationId=650 (previous value is 600) which is replicated to edg-perf02 and edg-perf03. > Now a merge view with all 4 nodes is installed: > {code} > 04:41:31,258 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-2,edg-perf01-63779) ISPN000093: Received new, MERGED cluster view for channel default: MergeView::[edg-perf01-63779|10] (4) [edg-perf01-63779, edg-perf03-6264, edg-perf02-45117, edg-perf04-10989], 6 subgroups: [edg-perf02-45117|7] (2) [edg-perf02-45117, edg-perf03-6264], [edg-perf01-63779|4] (2) [edg-perf01-63779, edg-perf02-45117], [edg-perf02-45117|9] (3) [edg-perf02-45117, edg-perf03-6264, edg-perf04-10989], [edg-perf03-6264|4] (2) [edg-perf03-6264, edg-perf04-10989], [edg-perf01-63779|8] (3) [edg-perf01-63779, edg-perf02-45117, edg-perf03-6264], [edg-perf01-63779|6] (1) [edg-perf01-63779] > 04:41:31,258 TRACE [org.infinispan.topology.ClusterTopologyManagerImpl] (transport-thread--p2-t2) Received new cluster view: 10, isCoordinator = true, becameCoordinator = false > {code} > edg-perf01 now issues a remote get to edg-perf02 for key stressor_33 and receives the correct answer (operationId=650): > {code} > 04:41:32,494 TRACE [org.infinispan.remoting.rpc.RpcManagerImpl] (BackgroundOps-Checker-1) Response(s) to ClusteredGetCommand{key=stressor_33, flags=null} is {edg-perf02-45117=SuccessfulResponse{responseValue=ImmortalCacheValue {value=LastOperation{operationId=650, seed=0000A15A4C2DD25A}}} } > {code} > However, when edg-perf01 reads {{key_00000000000020DB}}, it loads the old value from local data container as no CH update/rebalance happened so far: > {code} > 04:41:32,496 TRACE [org.infinispan.partitionhandling.impl.PartitionHandlingManagerImpl] (BackgroundOps-Checker-1) Checking availability for key=key_00000000000020DB, status=AVAILABLE > 04:41:32,497 ERROR [org.radargun.stages.cache.background.LogChecker] (BackgroundOps-Checker-1) Missing operation 634 for thread 33 on key 8411 (key_00000000000020DB) > 04:41:32,499 DEBUG [org.radargun.service.InfinispanDebugable] (BackgroundOps-Checker-1) Debug info for key testCache key_00000000000020DB: owners=edg-perf01-63779, edg-perf03-6264, local=true, uncertain=false, container.key_00000000000020DB=ImmortalCacheEntry[key=key_00000000000020DB, value=[33 #3: 0, 169, 284, ], created=-1, isCreated=false, lastUsed=-1, isChanged=false, expires=-1, isExpired=false, canExpire=false, isEvicted=true, isRemoved=false, isValid=false, lifespan=-1, maxIdle=-1], segmentId=173 > {code} > Note that this was found on branch https://github.com/infinispan/infinispan/pull/3062/files trying to fix ISPN-4949. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 4 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues November 2014