[JBoss JIRA] (ISPN-8643) ClientConnectionPoolingTest.testMaxActiveReached random failures
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-8643?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-8643:
----------------------------------
Fix Version/s: 9.4.2.Final
(was: 9.4.1.Final)
> ClientConnectionPoolingTest.testMaxActiveReached random failures
> ----------------------------------------------------------------
>
> Key: ISPN-8643
> URL: https://issues.jboss.org/browse/ISPN-8643
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite - Server
> Affects Versions: 9.2.0.Beta2
> Reporter: Dan Berindei
> Priority: Major
> Labels: testsuite_stability
> Fix For: 9.4.2.Final
>
>
> Looks like waiting for 1s for all the connections to be releases is not enough:
> {noformat}
> java.lang.AssertionError:
> at org.infinispan.test.AbstractInfinispanTest.eventually(AbstractInfinispanTest.java:229)
> at org.infinispan.test.AbstractInfinispanTest.eventually(AbstractInfinispanTest.java:211)
> at org.infinispan.test.AbstractInfinispanTest.eventually(AbstractInfinispanTest.java:187)
> at org.infinispan.client.hotrod.ClientConnectionPoolingTest.testMaxActiveReached(ClientConnectionPoolingTest.java:208)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> http://ci.infinispan.org/job/Infinispan/job/master/336
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month
[JBoss JIRA] (ISPN-8628) Simplify QueryEngine handling of Broadcast vs Fetch queries
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-8628?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-8628:
----------------------------------
Fix Version/s: 9.4.2.Final
(was: 9.4.1.Final)
> Simplify QueryEngine handling of Broadcast vs Fetch queries
> -----------------------------------------------------------
>
> Key: ISPN-8628
> URL: https://issues.jboss.org/browse/ISPN-8628
> Project: Infinispan
> Issue Type: Task
> Reporter: Gustavo Fernandes
> Assignee: Adrian Nistor
> Priority: Minor
> Fix For: 9.4.2.Final
>
>
> [~anistor] commented
> The existence of RemoteQueryDefinition and HsQueryRequest seems to be a symptom of misplaced responsibility. It all starts with QueryDefinition.initialize, which IMO should actually be placed inside QueryEngine, not QueryDefinition. Doing that refactoring will remove the need for RemoteQueryDefinition, which now exists just to differentiate between embedded and remote case, but that differentiation can be done inside the query engine itself. Also, HsQueryRequest is just a data holder that carries the return value of QueryEngine.createHsQuery. If QueryDefinition.initialize is moved to QueryEngine we would also not need this anymore.
> I did not think about it in detail but maybe we would also need to make QueryDefinition mutable for QueryEngine and immutable for external parties. In that case we can extract QueryDefinition as an immutable interface (exposing getters only) and it's implementation class could have package local setters accessible to QueryEngine only.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month
[JBoss JIRA] (ISPN-9367) State transfer should preserve the creation timestamp of entries
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-9367?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-9367:
----------------------------------
Fix Version/s: 9.4.2.Final
(was: 9.4.1.Final)
> State transfer should preserve the creation timestamp of entries
> ----------------------------------------------------------------
>
> Key: ISPN-9367
> URL: https://issues.jboss.org/browse/ISPN-9367
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 9.3.0.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Major
> Fix For: 9.4.2.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)
7 years, 1 month
[JBoss JIRA] (ISPN-9366) Cache.size optimizations
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-9366?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-9366:
----------------------------------
Fix Version/s: 9.4.2.Final
(was: 9.4.1.Final)
> Cache.size optimizations
> ------------------------
>
> Key: ISPN-9366
> URL: https://issues.jboss.org/browse/ISPN-9366
> Project: Infinispan
> Issue Type: Enhancement
> Reporter: William Burns
> Assignee: William Burns
> Priority: Major
> Fix For: 9.4.2.Final
>
>
> Now that we have a segmented data container and segmented store we can add optimizations for the Cache.size operation in various configurations.
> If a store is configured, passivation must be disabled for any of these optimizations related to stores to work
> # Shared store can just invoke Store.size
> # No store & no expired entries can invoke DataContainer.sizeIncludingExpired(IntSet)
> # Non shared store can invoke Store.size(IntSet)
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month
[JBoss JIRA] (ISPN-9319) Cache.lock(key) should throw AvailabilityException in degraded mode
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-9319?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-9319:
----------------------------------
Fix Version/s: 9.4.2.Final
(was: 9.4.1.Final)
> Cache.lock(key) should throw AvailabilityException in degraded mode
> -------------------------------------------------------------------
>
> Key: ISPN-9319
> URL: https://issues.jboss.org/browse/ISPN-9319
> Project: Infinispan
> Issue Type: Bug
> Components: Core, Test Suite - Core
> Affects Versions: 9.3.0.CR1
> Reporter: Dan Berindei
> Priority: Major
> Fix For: 9.4.2.Final
>
>
> We need a test for {{cache.lock(key)}} when one of the owners is not an actual member of the cluster and the cache is in degraded mode. {{PartitionHandlingInterceptor}} doesn't handle {{LockControlCommand}} explicitly, so it might end up throwing {{TimeoutException}} after waiting for a new topology. We should make sure it throws an {{AvailabilityException}} instead.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month