[JBoss JIRA] (ISPN-7159) CompleteShutdownDistRetryTest.testRetryAfterCompleteShutdown random failures
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-7159?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-7159:
-----------------------------------
Fix Version/s: 9.0.0.Beta3
(was: 9.0.0.Beta2)
> CompleteShutdownDistRetryTest.testRetryAfterCompleteShutdown random failures
> ----------------------------------------------------------------------------
>
> Key: ISPN-7159
> URL: https://issues.jboss.org/browse/ISPN-7159
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite - Server
> Affects Versions: 9.0.0.Alpha4
> Reporter: Dan Berindei
> Priority: Critical
> Labels: testsuite_stability
> Fix For: 9.0.0.Beta3
>
>
> {noformat}
> java.lang.AssertionError: expected:<two> but was:<null>
> at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:101)
> at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:108)
> at org.infinispan.client.hotrod.retry.CompleteShutdownDistRetryTest.testRetryAfterCompleteShutdown(CompleteShutdownDistRetryTest.java:58)
> {noformat}
> I think the problem is that killing node 0 can make node 2's key move from node 2 to node 1, and then it's lost after node 1 is also killed.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (ISPN-7167) ExampleConfigsIT.testTopologyConfigRackAttribute random failures
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-7167?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-7167:
-----------------------------------
Fix Version/s: 9.0.0.Beta3
(was: 9.0.0.Beta2)
> ExampleConfigsIT.testTopologyConfigRackAttribute random failures
> -----------------------------------------------------------------
>
> Key: ISPN-7167
> URL: https://issues.jboss.org/browse/ISPN-7167
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite - Server
> Affects Versions: 9.0.0.Alpha4
> Reporter: Dan Berindei
> Priority: Critical
> Labels: testsuite_stability
> Fix For: 9.0.0.Beta3
>
>
> {noformat}
> java.lang.AssertionError: Unexpected number of entries in server1: 0
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at org.infinispan.server.test.configs.ExampleConfigsIT.verifyTopologyHinting(ExampleConfigsIT.java:482)
> at org.infinispan.server.test.configs.ExampleConfigsIT.testTopologyConfigRackAttribute(ExampleConfigsIT.java:419)
> {noformat}
> The test is also inconsistent about the names of the servers, sometimes it starts counting from 0 and sometimes it starts counting from 1.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (ISPN-7227) SearchNewEntityJmsMasterSlaveUsingInfinispanAndModulesIT fails
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-7227?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-7227:
-----------------------------------
Fix Version/s: 9.0.0.Beta3
(was: 9.0.0.Beta2)
> SearchNewEntityJmsMasterSlaveUsingInfinispanAndModulesIT fails
> --------------------------------------------------------------
>
> Key: ISPN-7227
> URL: https://issues.jboss.org/browse/ISPN-7227
> Project: Infinispan
> Issue Type: Bug
> Components: Integration
> Affects Versions: 9.0.0.Alpha4
> Reporter: Vojtech Juranek
> Assignee: Vojtech Juranek
> Fix For: 9.0.0.Beta3, 9.0.0.Final
>
>
> {{SearchNewEntityJmsMasterSlaveUsingInfinispanAndModulesIT}} fails with
> {noformat}
> Caused by: java.lang.Exception: {"WFLYCTL0080: Failed services" => {"jboss.persistenceunit.\"master.war#pu-master\"" => "org.jboss.msc.service.StartException in service jboss.persistenceunit.\"master.war#pu-master\": javax.persistence.PersistenceException: [PersistenceUnit: pu-master] Unable to build Hibernate SessionFactory
> Caused by: javax.persistence.PersistenceException: [PersistenceUnit: pu-master] Unable to build Hibernate SessionFactory
> Caused by: org.hibernate.search.exception.SearchException: HSEARCH000103: Unable to initialize IndexManager named 'org.infinispan.test.integration.as.jms.model.RegisteredMember'
> Caused by: org.hibernate.search.exception.SearchException: HSEARCH000252: Unable to initialize directory provider org.infinispan.hibernate.search.spi.InfinispanDirectoryProvider for index org.infinispan.test.integration.as.jms.model.RegisteredMember
> Caused by: org.infinispan.manager.EmbeddedCacheManagerStartupException: org.infinispan.commons.CacheConfigurationException: ISPN000085: Error while trying to create a channel using the specified configuration file: default-configs/default-jgroups-udp.xml
> Caused by: org.infinispan.commons.CacheConfigurationException: ISPN000085: Error while trying to create a channel using the specified configuration file: default-configs/default-jgroups-udp.xml
> Caused by: java.lang.IllegalArgumentException: JGRP000001: configuration error: the following properties in UDP are not recognized: {oob_thread_pool.max_threads=200, internal_thread_pool.max_threads=20, internal_thread_pool.keep_alive_time=60000, thread_pool.queue_enabled=false, internal_thread_pool.min_threads=5, oob_thread_pool.keep_alive_time=60000, oob_thread_pool.min_threads=20, oob_thread_pool.queue_enabled=false, internal_thread_pool.queue_max_size=500, internal_thread_pool.queue_enabled=true}"}}
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (ISPN-7230) XSite view should be logged at INFO
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-7230?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-7230:
-----------------------------------
Fix Version/s: 9.0.0.Beta3
(was: 9.0.0.Beta2)
> XSite view should be logged at INFO
> -----------------------------------
>
> Key: ISPN-7230
> URL: https://issues.jboss.org/browse/ISPN-7230
> Project: Infinispan
> Issue Type: Feature Request
> Components: Cross-Site Replication
> Affects Versions: 9.0.0.Alpha4, 8.2.5.Final
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Fix For: 9.0.0.Beta3, 9.0.0.Final
>
>
> XSite view should be printed as INFO message. Currently, the only log messages printed are:
> Site A:
> {code}
> 11:19:00,398 INFO [org.jgroups.protocols.relay.RELAY2]
> (Timer-2,gs-macbook-pro-3) _gs-macbook-pro-3:LON:
> joined bridge cluster 'xsite'
> {code}
> Site B:
> {code}
> 11:19:31,329 INFO [org.jgroups.protocols.relay.RELAY2]
> (Timer-3,gs-macbook-pro-3) _gs-macbook-pro-3:NYC:
> joined bridge cluster 'xsite'
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (ISPN-7272) Remove replication statistics from RpcManagerImpl
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-7272?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-7272:
-----------------------------------
Fix Version/s: 9.0.0.Beta3
(was: 9.0.0.Beta2)
> Remove replication statistics from RpcManagerImpl
> -------------------------------------------------
>
> Key: ISPN-7272
> URL: https://issues.jboss.org/browse/ISPN-7272
> Project: Infinispan
> Issue Type: Task
> Components: Core
> Affects Versions: 9.0.0.Alpha4, 8.1.6.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Fix For: 9.0.0.Beta3
>
>
> The replication statistics exposed by {{RpcManagerImpl}} are too low-level. For instance, in non-transactional caches, the times of the RPCs from the primary to the backups are counted both on the primary and on the originator (as part of the originator-to-primary RPC). They also aren't split by operation, like the {{CacheMgmtInterceptor}} statistics, which makes them even less useful.
> The triangle algorithm changes things again, but only for distributed caches, so there is now one more way of interpreting the {{RpcManagerImpl}} statistics. It would be better to remove them altogether.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (ISPN-7300) Operator '-' doesn't work in fulltext querying
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-7300?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-7300:
-----------------------------------
Fix Version/s: 9.0.0.Beta3
(was: 9.0.0.Beta2)
> Operator '-' doesn't work in fulltext querying
> ----------------------------------------------
>
> Key: ISPN-7300
> URL: https://issues.jboss.org/browse/ISPN-7300
> Project: Infinispan
> Issue Type: Bug
> Components: Embedded Querying, Remote Querying
> Affects Versions: 9.0.0.Beta1
> Reporter: Jiří Holuša
> Assignee: Adrian Nistor
> Fix For: 9.0.0.Beta3
>
>
> Given following query:
> {code}
> from Entity t where t.longDescription : (-'really')
> {code}
> I would expect to return all entities that doesn't contain the word 'really' (opposite to +), but it seems to be not working.
> PR contains test for it as well as other tests for extending query testsuite.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (ISPN-7324) DDAsyncInterceptor indirection slows down replicated reads
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-7324?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-7324:
-----------------------------------
Fix Version/s: 9.0.0.Beta3
(was: 9.0.0.Beta2)
> DDAsyncInterceptor indirection slows down replicated reads
> ----------------------------------------------------------
>
> Key: ISPN-7324
> URL: https://issues.jboss.org/browse/ISPN-7324
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 9.0.0.Beta1
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Labels: performance
> Fix For: 9.0.0.Beta3
>
>
> Local reads are fast enough, but the additional interceptors and stage callbacks in (transactional) replicated mode seem to impact with the async interceptor stack a lot more than the classic one.
> One thing that's different with the new interceptors is that {{invokeNext()}} doesn't call {{command.acceptVisitor(nextInterceptor)}} directly. Instead it calls {{nextInterceptor.visitCommand()}}, and the interceptor decides whether to use double-dispatch (by extending {{DDAsyncInterceptor}}) or another strategy.
> In theory this allows us to use simpler interceptors, e.g. having just the methods {{visitReadCommand()}}, {{visitWriteCommand()}}, and {{visitTxCommand()}}. {{CallInterceptor}} already calls {{command.perform()}} for each command. For now, however, most interceptors extend {{DDAsyncInterceptor}}, and tx replicated reads are slower than in 9.0.0.Alpha0.
> With transactions, the {{VisitableCommand.acceptVisitor(}} call site in {{DDAsyncInterceptor.visitCommand}} is megamorphic (since the initial preload uses put, prepare, and commit). Adding a special check in {{invokeNext()}} to invoke {{command.acceptVisitor(nextInterceptor)}} didn't help, but adding a special check for {{GetKeyValueCommand}} made a big difference on my machine:
> |9.0.0.Alpha0 (CommandInterceptor)|4937351.255 ±(99.9%) 61665.164 ops/s|
> |9.0.0.Beta1 (AsyncInterceptor)|4387466.151 ±(99.9%) 78665.887 ops/s|
> |master before ISPN-6802 and ISPN-6803| 4247769.260 ±(99.9%) 133767.371 ops/s|
> |master| 4710798.986 ±(99.9%) 166062.177 ops/s|
> |master with GKVC special case| 5749357.895 ±(99.9%) 87338.878 ops/s|
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months