[JBoss JIRA] (ISPN-5884) ClusteredListenerReplTest.testPrimaryOwnerGoesDownAfterBackupRaisesEvent random failures
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-5884?page=com.atlassian.jira.plugin.... ]
William Burns updated ISPN-5884:
--------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> ClusteredListenerReplTest.testPrimaryOwnerGoesDownAfterBackupRaisesEvent random failures
> ----------------------------------------------------------------------------------------
>
> Key: ISPN-5884
> URL: https://issues.jboss.org/browse/ISPN-5884
> Project: Infinispan
> Issue Type: Bug
> Components: Core, Test Suite - Core
> Affects Versions: 8.1.0.Alpha2
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Blocker
> Fix For: 8.1.0.Beta1, 8.0.2.Final
>
>
> {{ClusteredListenerReplTest}} uses a {{BlockingInterceptor}} to ensure a write command is blocked on the backup owners while the primary owner is killed.
> The {{BlockingInterceptor}} is removed after the primary owner was killed, but only on one of the backups. This is enough if the node 0 becomes the primary owner of the key, because the command is retried before the previous invocation is unblocked, and {{BlockingInterceptor}} only blocks one command at a time. But if node 2 becomes the primary owner, the retry happens after the initial command was unblocked, and it blocks in {{BlockingInterceptor}}.
> The fix would be to remove the interceptor from both nodes.
> I also believe the "block one command at a time" logic should be removed, because it makes tests too dependent on timing.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 4 months
[JBoss JIRA] (ISPN-5891) IntegrationTest.testConcurrentETagChanges always fails
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-5891?page=com.atlassian.jira.plugin.... ]
William Burns updated ISPN-5891:
--------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> IntegrationTest.testConcurrentETagChanges always fails
> ------------------------------------------------------
>
> Key: ISPN-5891
> URL: https://issues.jboss.org/browse/ISPN-5891
> Project: Infinispan
> Issue Type: Bug
> Components: Server, Test Suite - Server
> Affects Versions: 8.1.0.Alpha2
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Blocker
> Labels: testsuite_stability
> Fix For: 8.1.0.Beta1
>
>
> The test always fails since the ISPN-5857 fix was integrated.
> When executing a {{PUT}} operation, the REST server always looks up the previous value, and if it exists, it executes a {{cache.replace(k, old, new)}} cache operation instead of a regular push. But the cache is configured with {{value-equivalence=AnyEquivalence}}, so the replace fails if the REST server is not the primary owner.
> It was successful before the ISPN-5857 fix only because the server was the primary owner of the key, and then only because {{ValueMatcher.equal()}} checks identity first.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 4 months
[JBoss JIRA] (ISPN-5893) ClusteredCacheConfigurationIT.testQueueFlushIntervalMemcached always fails
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-5893?page=com.atlassian.jira.plugin.... ]
William Burns updated ISPN-5893:
--------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> ClusteredCacheConfigurationIT.testQueueFlushIntervalMemcached always fails
> --------------------------------------------------------------------------
>
> Key: ISPN-5893
> URL: https://issues.jboss.org/browse/ISPN-5893
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite - Server
> Affects Versions: 8.1.0.Alpha2
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Blocker
> Labels: testsuite_stability
> Fix For: 8.1.0.Beta1
>
>
> Since the ISPN-5857 fix, ClusteredCacheConfigurationIT.testQueueFlushIntervalMemcached always fails.
> The problem is that the "k1" key no longer has node 1 as the primary owner. Because replication between the primary (node 2) and the backup (node 1) is asynchronous, a get after a put on node 1 almost never finds the value.
> The simple fix would be to swap the roles of node 1 and node 2 in the test.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 4 months
[JBoss JIRA] (ISPN-5791) Query DSL : Projecting a Date field multiple times will render it as string
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-5791?page=com.atlassian.jira.plugin.... ]
Adrian Nistor updated ISPN-5791:
--------------------------------
Fix Version/s: 8.0.2.Final
> Query DSL : Projecting a Date field multiple times will render it as string
> ---------------------------------------------------------------------------
>
> Key: ISPN-5791
> URL: https://issues.jboss.org/browse/ISPN-5791
> Project: Infinispan
> Issue Type: Bug
> Components: Embedded Querying
> Affects Versions: 8.0.1.Final, 8.1.0.Alpha1
> Reporter: Adrian Nistor
> Assignee: Adrian Nistor
> Fix For: 8.1.0.Beta1, 8.0.2.Final
>
>
> Adding this in QueryDslConditionsTest fails. The second date projection is a String instead of being a Date. First projection is OK. The problem is gone if cache is not indexed, which makes me think it is more of a problem in CacheQuery.
> {code}
> public void testDuplicateDateProjection() throws Exception {
> QueryFactory qf = getQueryFactory();
> Query q = qf.from(getModelFactory().getTransactionImplClass())
> .select("id", "date", "date")
> .having("description").eq("Hotel")
> .toBuilder().build();
> List<Object[]> list = q.list();
> assertEquals(1, list.size());
> assertEquals(1, list.size());
> assertEquals(3, list.get(0).length);
> assertEquals(3, list.get(0)[0]);
> assertEquals(makeDate("2013-02-27"), list.get(0)[1]);
> assertEquals(makeDate("2013-02-27"), list.get(0)[2]);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 4 months
[JBoss JIRA] (ISPN-5791) Query DSL : Projecting a Date field multiple times will render it as string
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-5791?page=com.atlassian.jira.plugin.... ]
Adrian Nistor updated ISPN-5791:
--------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/3789
> Query DSL : Projecting a Date field multiple times will render it as string
> ---------------------------------------------------------------------------
>
> Key: ISPN-5791
> URL: https://issues.jboss.org/browse/ISPN-5791
> Project: Infinispan
> Issue Type: Bug
> Components: Embedded Querying
> Affects Versions: 8.0.1.Final, 8.1.0.Alpha1
> Reporter: Adrian Nistor
> Assignee: Adrian Nistor
> Fix For: 8.1.0.Beta1
>
>
> Adding this in QueryDslConditionsTest fails. The second date projection is a String instead of being a Date. First projection is OK. The problem is gone if cache is not indexed, which makes me think it is more of a problem in CacheQuery.
> {code}
> public void testDuplicateDateProjection() throws Exception {
> QueryFactory qf = getQueryFactory();
> Query q = qf.from(getModelFactory().getTransactionImplClass())
> .select("id", "date", "date")
> .having("description").eq("Hotel")
> .toBuilder().build();
> List<Object[]> list = q.list();
> assertEquals(1, list.size());
> assertEquals(1, list.size());
> assertEquals(3, list.get(0).length);
> assertEquals(3, list.get(0)[0]);
> assertEquals(makeDate("2013-02-27"), list.get(0)[1]);
> assertEquals(makeDate("2013-02-27"), list.get(0)[2]);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 4 months