[JBoss JIRA] (ISPN-9660) Histogram stats
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-9660?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-9660:
----------------------------------
Sprint: Sprint 10.0.0.Alpha1, Sprint 10.0.0.Alpha2, Sprint 10.0.0.Beta1, DataGrid Sprint #31, DataGrid Sprint #32, DataGrid Sprint #33 (was: Sprint 10.0.0.Alpha1, Sprint 10.0.0.Alpha2, Sprint 10.0.0.Beta1, DataGrid Sprint #31, DataGrid Sprint #32)
> Histogram stats
> ---------------
>
> Key: ISPN-9660
> URL: https://issues.jboss.org/browse/ISPN-9660
> Project: Infinispan
> Issue Type: Feature Request
> Components: JMX, reporting and management
> Affects Versions: 9.4.0.Final
> Reporter: Tristan Tarrant
> Assignee: Nistor Adrian
> Priority: Major
> Fix For: 10.0.0.Final
>
>
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 7 months
[JBoss JIRA] (ISPN-7889) BaseDistributionInterceptor.remoteGet may cause concurrency issues
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-7889?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-7889:
----------------------------------
Sprint: Sprint 10.0.0.Alpha1, Sprint 10.0.0.Alpha2, Sprint 10.0.0.Alpha0, Sprint 10.0.0.Beta1, DataGrid Sprint #31, DataGrid Sprint #32, DataGrid Sprint #33 (was: Sprint 10.0.0.Alpha1, Sprint 10.0.0.Alpha2, Sprint 10.0.0.Alpha0, Sprint 10.0.0.Beta1, DataGrid Sprint #31, DataGrid Sprint #32)
> BaseDistributionInterceptor.remoteGet may cause concurrency issues
> ------------------------------------------------------------------
>
> Key: ISPN-7889
> URL: https://issues.jboss.org/browse/ISPN-7889
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 9.1.0.Alpha1
> Reporter: Radim Vansa
> Assignee: Dan Berindei
> Priority: Major
> Fix For: 10.0.0.Alpha3, 9.4.6.Final
>
>
> {{BaseDistributionInterceptor.remoteGet}} or any call that accesses the context in an async future handler that is called multiple times in parallel may lead to concurrent modifications of the context.
> These calls are usually handled using {{CompletableFuture.allOf()}} or using a CF with counter, but if one of the calls results in exceptional completion of the composed future, the processing continues (e.g. with a retry). The other parallel operation handlers are not stopped, though.
> {{BaseDistributionInterceptor.remoteGet}} shouldn't be called in parallel because it does not even synchronize regular successful invocations.
> A problem like this caused failures in {{GetAllCommandStressTest}}, and the issue was addressed for {{GetAllCommand}} in ISPN-7884.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 7 months
[JBoss JIRA] (ISPN-9555) ComponentRegistry should enforce that registered components implement the interface/contract
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-9555?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-9555:
----------------------------------
Sprint: Sprint 10.0.0.Alpha1, Sprint 10.0.0.Alpha2, Sprint 9.4.0.Final, Sprint 10.0.0.Alpha0, Sprint 10.0.0.Beta1, DataGrid Sprint #31, DataGrid Sprint #32, DataGrid Sprint #33 (was: Sprint 10.0.0.Alpha1, Sprint 10.0.0.Alpha2, Sprint 9.4.0.Final, Sprint 10.0.0.Alpha0, Sprint 10.0.0.Beta1, DataGrid Sprint #31, DataGrid Sprint #32)
> ComponentRegistry should enforce that registered components implement the interface/contract
> --------------------------------------------------------------------------------------------
>
> Key: ISPN-9555
> URL: https://issues.jboss.org/browse/ISPN-9555
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Reporter: Nistor Adrian
> Assignee: Dan Berindei
> Priority: Major
> Fix For: 10.0.0.Final
>
>
> ComponentRegistry.registerComponent(impl, interface) does not currently check that the impl really is assignable to the interface.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 7 months
[JBoss JIRA] (ISPN-9291) BasePartitionHandlingTest.Partition.installMergeView() doesn't compute the merge digest
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-9291?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-9291:
----------------------------------
Sprint: Sprint 9.4.0.Beta1, Sprint 9.4.0.CR1, Sprint 9.4.0.CR3, Sprint 10.0.0.Alpha1, Sprint 10.0.0.Alpha2, Sprint 9.4.0.Final, Sprint 10.0.0.Alpha0, Sprint 10.0.0.Beta1, DataGrid Sprint #31, DataGrid Sprint #32, DataGrid Sprint #33 (was: Sprint 9.4.0.Beta1, Sprint 9.4.0.CR1, Sprint 9.4.0.CR3, Sprint 10.0.0.Alpha1, Sprint 10.0.0.Alpha2, Sprint 9.4.0.Final, Sprint 10.0.0.Alpha0, Sprint 10.0.0.Beta1, DataGrid Sprint #31, DataGrid Sprint #32)
> BasePartitionHandlingTest.Partition.installMergeView() doesn't compute the merge digest
> ---------------------------------------------------------------------------------------
>
> Key: ISPN-9291
> URL: https://issues.jboss.org/browse/ISPN-9291
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite - Core
> Affects Versions: 9.3.0.CR1
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Minor
> Labels: testsuite_stability
> Fix For: 10.0.0.Beta4, 9.4.16.Final
>
>
> The partition handling tests use {{BasePartitionHandlingTest.Partition.installMergeView(view1, view2)}} to install the merge view without waiting for {{MERGE3}} to run, making them much faster. Unfortunately, the implementation is incorrect: {{GMS.installView(view)}} only works for regular views, merge views need to be installed with {{GMS.installView(mergeView, digest)}}.
> The result is that the nodes that got isolated from the coordinator request the retransmission of all the {{NAKACK2}} messages (including view updates) since the cluster first started. The isolated nodes cannot install the merge view until they deliver all the older messages (even without knowing whether they're OOB or not). But if {{STABLE}} ran and cleared a range of messages already, the retransmission request cannot be satisfied, so the view updates will never be delivered.
> This is easily reproducible in {{CrashedNodeDuringConflictResolutionTest}} if we add a delay before updating the topology in {{StateConsumerImpl}}. The test installs the merge view manually, but then kills NodeC and expects the cluster to install the new view automatically. NodeD can't install the new view because it's waiting for earlier messages from NodeA:
> {noformat}
> 18:27:13,054 INFO (testng-test:[]) [TestSuiteProgress] Test starting: org.infinispan.conflict.impl.CrashedNodeDuringConflictResolutionTest.testPartitionMergePolicy[DIST_SYNC]
> 18:27:13,640 DEBUG (testng-test:[]) [GMS] test-NodeA-39513: installing view MergeView::[test-NodeA-39513|10] (4) [test-NodeA-39513, test-NodeB-9439, test-NodeC-43706, test-NodeD-59078], 2 subgroups: [test-NodeA-39513|8] (2) [test-NodeA-39513, test-NodeB-9439], [test-NodeC-43706|9] (2) [test-NodeC-43706, test-NodeD-59078]
> 18:27:13,674 DEBUG (testng-test:[]) [GMS] test-NodeD-59078: installing view MergeView::[test-NodeA-39513|10] (4) [test-NodeA-39513, test-NodeB-9439, test-NodeC-43706, test-NodeD-59078], 2 subgroups: [test-NodeA-39513|8] (2) [test-NodeA-39513, test-NodeB-9439], [test-NodeC-43706|9] (2) [test-NodeC-43706, test-NodeD-59078]
> 18:27:13,828 TRACE (jgroups-7,test-NodeD-59078:[]) [NAKACK2] test-NodeD-59078: sending XMIT_REQ ((1): {50}) to test-NodeA-39513
> 18:27:13,966 TRACE (Timer runner-1,test-NodeD-59078:[]) [NAKACK2] test-NodeD-59078: sending XMIT_REQ ((49): {1-49}) to test-NodeA-39513
> 18:27:14,067 TRACE (Timer runner-1,test-NodeD-59078:[]) [NAKACK2] test-NodeD-59078: sending XMIT_REQ ((45): {1-45}) to test-NodeA-39513
> 18:27:14,504 DEBUG (testng-test:[]) [DefaultCacheManager] Stopping cache manager ISPN on test-NodeC-43706
> 18:27:18,642 TRACE (VERIFY_SUSPECT.TimerThread-89,test-NodeA-39513:[]) [GMS] test-NodeA-39513: joiners=[], suspected=[test-NodeC-43706], leaving=[], new view: [test-NodeA-39513|11] (3) [test-NodeA-39513, test-NodeB-9439, test-NodeD-59078]
> 18:27:18,643 TRACE (VERIFY_SUSPECT.TimerThread-89,test-NodeA-39513:[]) [GMS] test-NodeA-39513: mcasting view [test-NodeA-39513|11] (3) [test-NodeA-39513, test-NodeB-9439, test-NodeD-59078]
> 18:27:18,646 DEBUG (VERIFY_SUSPECT.TimerThread-89,test-NodeA-39513:[]) [GMS] test-NodeA-39513: installing view [test-NodeA-39513|11] (3) [test-NodeA-39513, test-NodeB-9439, test-NodeD-59078]
> 18:27:18,652 TRACE (VERIFY_SUSPECT.TimerThread-89,test-NodeA-39513:[]) [TCP_NIO2] test-NodeA-39513: sending msg to null, src=test-NodeA-39513, headers are GMS: GmsHeader[VIEW], NAKACK2: [MSG, seqno=63], TP: [cluster_name=ISPN]
> 18:27:18,656 TRACE (jgroups-20,test-NodeA-39513:[]) [TCP_NIO2] test-NodeA-39513: received [dst: test-NodeA-39513, src: test-NodeB-9439 (3 headers), size=0 bytes, flags=OOB|INTERNAL], headers are GMS: GmsHeader[VIEW_ACK], UNICAST3: DATA, seqno=100, TP: [cluster_name=ISPN]
> 18:27:20,554 TRACE (Timer runner-1,test-NodeD-59078:[]) [NAKACK2] test-NodeD-59078: sending XMIT_REQ ((45): {1-45}) to test-NodeA-39513
> 18:27:20,653 WARN (VERIFY_SUSPECT.TimerThread-89,test-NodeA-39513:[]) [GMS] test-NodeA-39513: failed to collect all ACKs (expected=2) for view [test-NodeA-39513|11] after 2000ms, missing 1 ACKs from (1) test-NodeD-59078
> 18:27:20,656 TRACE (Timer runner-1,test-NodeD-59078:[]) [NAKACK2] test-NodeD-59078: sending XMIT_REQ ((45): {1-45}) to test-NodeA-39513
> 18:27:20,756 TRACE (Timer runner-1,test-NodeD-59078:[]) [NAKACK2] test-NodeD-59078: sending XMIT_REQ ((45): {1-45}) to test-NodeA-39513
> ...
> 18:28:14,412 TRACE (Timer runner-1,test-NodeD-59078:[]) [NAKACK2] test-NodeD-59078: sending XMIT_REQ ((45): {1-45}) to test-NodeA-39513
> 18:28:14,513 TRACE (Timer runner-1,test-NodeD-59078:[]) [NAKACK2] test-NodeD-59078: sending XMIT_REQ ((45): {1-45}) to test-NodeA-39513
> 18:28:14,589 ERROR (testng-test:[]) [TestSuiteProgress] Test failed: org.infinispan.conflict.impl.CrashedNodeDuringConflictResolutionTest.testPartitionMergePolicy[DIST_SYNC]
> java.lang.RuntimeException: Cache ___defaultcache timed out waiting for rebalancing to complete on node test-NodeA-39513, current topology is CacheTopology{id=21, phase=CONFLICT_RESOLUTION, rebalanceId=7, currentCH=PartitionerConsistentHash:DefaultConsistentHash{ns=256, owners = (3)[test-NodeD-59078: 256+0, test-NodeA-39513: 0+256, test-NodeB-9439: 0+256]}, pendingCH=null, unionCH=null, actualMembers=[test-NodeD-59078, test-NodeA-39513, test-NodeB-9439], persistentUUIDs=[828108c4-4251-49fc-9481-ff6392bea9fb, 1d4b6f07-b71b-41a1-adfb-abbe68944a9f, 3a1ece05-c282-433e-9eb5-7b3e0f1932aa]}. rebalanceInProgress=true, currentChIsBalanced=true
> at org.infinispan.test.TestingUtil.waitForNoRebalance(TestingUtil.java:392) ~[test-classes/:?]
> at org.infinispan.conflict.impl.CrashedNodeDuringConflictResolutionTest.performMerge(CrashedNodeDuringConflictResolutionTest.java:113) ~[test-classes/:?]
> at org.infinispan.conflict.impl.BaseMergePolicyTest.testPartitionMergePolicy(BaseMergePolicyTest.java:137) ~[test-classes/:?]
> {noformat}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 7 months
[JBoss JIRA] (ISPN-9036) Parameterized branding for C++
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-9036?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-9036:
----------------------------------
Sprint: Sprint 9.3.0.Alpha1, Sprint 9.3.0.Beta1, Sprint 9.3.0.CR1, Sprint 9.3.0.Final, Sprint 9.4.0.Beta1, Sprint 9.4.0.CR1, Sprint 9.4.0.CR3, Sprint 10.0.0.Alpha1, Sprint 10.0.0.Alpha2, Sprint 9.4.0.Final, Sprint 10.0.0.Alpha0, Sprint 10.0.0.Beta1, DataGrid Sprint #31, DataGrid Sprint #32, DataGrid Sprint #33 (was: Sprint 9.3.0.Alpha1, Sprint 9.3.0.Beta1, Sprint 9.3.0.CR1, Sprint 9.3.0.Final, Sprint 9.4.0.Beta1, Sprint 9.4.0.CR1, Sprint 9.4.0.CR3, Sprint 10.0.0.Alpha1, Sprint 10.0.0.Alpha2, Sprint 9.4.0.Final, Sprint 10.0.0.Alpha0, Sprint 10.0.0.Beta1, DataGrid Sprint #31, DataGrid Sprint #32)
> Parameterized branding for C++
> ------------------------------
>
> Key: ISPN-9036
> URL: https://issues.jboss.org/browse/ISPN-9036
> Project: Infinispan
> Issue Type: Enhancement
> Reporter: Tristan Tarrant
> Assignee: Vittorio Rigamonti
> Priority: Major
>
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 7 months
[JBoss JIRA] (ISPN-8861) DIST Iteration shouldn't go remote when a shared cache store is present
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-8861?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-8861:
----------------------------------
Sprint: Sprint 9.4.0.CR1, Sprint 9.4.0.CR3, Sprint 10.0.0.Alpha1, Sprint 10.0.0.Alpha2, Sprint 9.4.0.Final, Sprint 10.0.0.Alpha0, Sprint 10.0.0.Beta1, DataGrid Sprint #31, DataGrid Sprint #32, DataGrid Sprint #33 (was: Sprint 9.4.0.CR1, Sprint 9.4.0.CR3, Sprint 10.0.0.Alpha1, Sprint 10.0.0.Alpha2, Sprint 9.4.0.Final, Sprint 10.0.0.Alpha0, Sprint 10.0.0.Beta1, DataGrid Sprint #31, DataGrid Sprint #32)
> DIST Iteration shouldn't go remote when a shared cache store is present
> -----------------------------------------------------------------------
>
> Key: ISPN-8861
> URL: https://issues.jboss.org/browse/ISPN-8861
> Project: Infinispan
> Issue Type: Enhancement
> Components: Loaders and Stores
> Reporter: Will Burns
> Assignee: Will Burns
> Priority: Major
> Fix For: 10.0.0.Final
>
>
> When a user runs a distributed iteration operation with a shared cache store, this shouldn't go remote as the local node would have all the data available to it. This is similar to the optimization when we don't go remote if the current node is an owner for all required segments.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 7 months
[JBoss JIRA] (ISPN-7624) Change CacheLoaderInterceptor to ignore in memory for certain operations when passivation is not enabled
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-7624?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-7624:
----------------------------------
Sprint: Sprint 9.4.0.CR1, Sprint 9.4.0.CR3, Sprint 10.0.0.Alpha1, Sprint 10.0.0.Alpha2, Sprint 9.4.0.Final, Sprint 10.0.0.Alpha0, Sprint 10.0.0.Beta1, DataGrid Sprint #31, DataGrid Sprint #32, DataGrid Sprint #33 (was: Sprint 9.4.0.CR1, Sprint 9.4.0.CR3, Sprint 10.0.0.Alpha1, Sprint 10.0.0.Alpha2, Sprint 9.4.0.Final, Sprint 10.0.0.Alpha0, Sprint 10.0.0.Beta1, DataGrid Sprint #31, DataGrid Sprint #32)
> Change CacheLoaderInterceptor to ignore in memory for certain operations when passivation is not enabled
> --------------------------------------------------------------------------------------------------------
>
> Key: ISPN-7624
> URL: https://issues.jboss.org/browse/ISPN-7624
> Project: Infinispan
> Issue Type: Bug
> Components: Loaders and Stores
> Reporter: Will Burns
> Assignee: Will Burns
> Priority: Major
>
> CacheLoader currently reads all in memory entries and then the store for bulk operations. This can be changed to only load from the store when passivation is not used as it should contain all entries that aren't in memory.
> The only issue is that if Flag.SKIP_CACHE_STORE was used on a write. In this case we could store a boolean in the interceptor so that if this Flag is ever used we always do both. Very few users use this Flag and it should improve performance a bit and entries should be seen more consistently.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 7 months
[JBoss JIRA] (ISPN-9847) Extend configuration to allow inline JGroups configuration and inheritance
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-9847?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-9847:
----------------------------------
Sprint: Sprint 10.0.0.Beta1, DataGrid Sprint #31, DataGrid Sprint #32, DataGrid Sprint #33 (was: Sprint 10.0.0.Beta1, DataGrid Sprint #31, DataGrid Sprint #32)
> Extend configuration to allow inline JGroups configuration and inheritance
> --------------------------------------------------------------------------
>
> Key: ISPN-9847
> URL: https://issues.jboss.org/browse/ISPN-9847
> Project: Infinispan
> Issue Type: Enhancement
> Components: Configuration, Core
> Affects Versions: 10.0.0.Alpha2
> Reporter: Tristan Tarrant
> Assignee: Tristan Tarrant
> Priority: Major
> Fix For: 10.0.0.Beta1, 10.0.0.Final
>
>
> Allowing inline JGroups configurations to increase usability.
> Also support the following extra features:
> * stack inheritance with protocol replacement/override
> * easier xsite configuration
> {code:xml}
> <jgroups transport="org.infinispan.remoting.transport.jgroups.JGroupsTransport">
> <!-- Load external JGroups stacks -->
> <stack-file name="udp" path="stacks/udp.xml"/>
> <stack-file name="tcp" path="stacks/tcp.xml"/>
> <!-- Inline definition -->
> <stack name="mping">
> <TCP bind_port="7800" port_range="30" recv_buf_size="20000000" send_buf_size="640000"
> sock_conn_timeout="300" bundler_type="no-bundler"
> thread_pool.min_threads="0" thread_pool.max_threads="25" thread_pool.keep_alive_time="5000"/>
> <MPING bind_addr="127.0.0.1" break_on_coord_rsp="true"
> mcast_addr="${jgroups.mping.mcast_addr:228.2.4.6}"
> mcast_port="${jgroups.mping.mcast_port:43366}"
> ip_ttl="${jgroups.udp.ip_ttl:2}"/>
> <MERGE3/>
> <FD_SOCK/>
> <FD_ALL timeout="3000"
> interval="1000"
> timeout_check_interval="1000"
> />
> <VERIFY_SUSPECT timeout="1000"/>
> <pbcast.NAKACK2
> use_mcast_xmit="false"
> xmit_interval="100"
> xmit_table_num_rows="50"
> xmit_table_msgs_per_row="1024"
> xmit_table_max_compaction_time="30000"/>
> <UNICAST3
> xmit_interval="100"
> xmit_table_num_rows="50"
> xmit_table_msgs_per_row="1024"
> xmit_table_max_compaction_time="30000"
> />
> <RSVP />
> <pbcast.STABLE stability_delay="200"
> desired_avg_gossip="2000"
> max_bytes="1M"
> />
> <pbcast.GMS print_local_addr="false"
> join_timeout="${jgroups.join_timeout:2000}"/>
> <MFC max_credits="2M" min_threshold="0.40"/>
> <FRAG3/>
> </stack>
> <!-- Use the "tcp" stack but override some protocol attributes -->
> <stack name="mytcp" extends="tcp">
> <MERGE3 max_interval="20000"/>
> </stack>
> <!-- Use the "tcp" stack but replace the discovery -->
> <stack name="tcpgossip" extends="tcp">
> <TCPGOSSIP initial_hosts="${jgroups.tunnel.gossip_router_hosts:localhost[12001]}" stack.combine="replace:TCP_NIO2"/>
> </stack>
> <!-- Add a relay configuration using a previously declared stack to talk to the remote site -->
> <stack name="xsite" extends="udp">
> <relay site="LON">
> <remote-site name="NYC" stack="tcpgossip"/>
> </relay>
> </stack>
> </jgroups>
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 7 months
[JBoss JIRA] (ISPN-4075) State transfer should preserve the creation timestamp of entries
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-4075?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-4075:
----------------------------------
Sprint: Sprint 10.0.0.Alpha2, Sprint 10.0.0.Beta1, DataGrid Sprint #31, DataGrid Sprint #32, DataGrid Sprint #33 (was: Sprint 10.0.0.Alpha2, Sprint 10.0.0.Beta1, DataGrid Sprint #31, DataGrid Sprint #32)
> State transfer should preserve the creation timestamp of entries
> ----------------------------------------------------------------
>
> Key: ISPN-4075
> URL: https://issues.jboss.org/browse/ISPN-4075
> Project: Infinispan
> Issue Type: Feature Request
> Components: Core
> Affects Versions: 6.0.1.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Major
> Fix For: 9.4.7.Final, 10.0.0.Beta1, 10.0.0.Final
>
>
> State transfer inserts values with the current time as the creation time. Since the entries store the expected lifespan and not the expected expiration time, entries on the receiving node could expire much later than intended.
> The argument probably doesn't apply to the timestamp of the last usage. Since state transfer process could be interpreted as a reader, it should be fine to extend the update the time of the last usage both on the sending node and on the receiving node.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 7 months