[JBoss JIRA] (ISPN-5967) Verify Infinispan 8.1 is binary compatible for Hibernate 2LC
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-5967?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño commented on ISPN-5967:
----------------------------------------
Binary compatibility remains but some new errors have been detected in the testsuite that were not present before:
{code}
org.hibernate.test.cache.infinispan.collection.CollectionRegionAccessStrategyTest > testRemoveAll[JTA, INVALIDATION_SYNC,AccessType[transactional]] FAILED
java.lang.AssertionError
org.hibernate.test.cache.infinispan.collection.CollectionRegionAccessStrategyTest > testRemoveAll[non-JTA, INVALIDATION_SYNC,AccessType[transactional]] FAILED
java.lang.AssertionError
org.hibernate.test.cache.infinispan.entity.EntityRegionAccessStrategyTest > testRemoveAll[JTA, INVALIDATION_SYNC,AccessType[transactional]] FAILED
java.lang.AssertionError
org.hibernate.test.cache.infinispan.entity.EntityRegionAccessStrategyTest > testRemoveAll[non-JTA, INVALIDATION_SYNC,AccessType[transactional]] FAILED
java.lang.AssertionError
org.hibernate.test.cache.infinispan.functional.cluster.EntityCollectionInvalidationTest > testAll[transactional, INVALIDATION_SYNC] FAILED
java.lang.AssertionError at EntityCollectionInvalidationTest.java:349
org.hibernate.test.cache.infinispan.functional.cluster.EntityCollectionInvalidationTest > testConcurrentLoadAndRemoval[transactional, INVALIDATION_SYNC] FAILED
org.hibernate.service.UnknownServiceException at EntityCollectionInvalidationTest.java:188
org.hibernate.service.UnknownServiceException at EntityCollectionInvalidationTest.java:331
org.hibernate.test.cache.infinispan.functional.cluster.NaturalIdInvalidationTest > testAll[transactional, INVALIDATION_SYNC] FAILED
java.lang.AssertionError at NaturalIdInvalidationTest.java:147
{code}
> Verify Infinispan 8.1 is binary compatible for Hibernate 2LC
> ------------------------------------------------------------
>
> Key: ISPN-5967
> URL: https://issues.jboss.org/browse/ISPN-5967
> Project: Infinispan
> Issue Type: Task
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Priority: Blocker
> Fix For: 8.1.0.Final
>
>
> Make sure Hibernate 2LC testsuite can be run with Infinispan 8.1 just by swapping jars.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 1 month
[JBoss JIRA] (ISPN-5992) REST server does not set value equivalence properly
by Radim Vansa (JIRA)
Radim Vansa created ISPN-5992:
---------------------------------
Summary: REST server does not set value equivalence properly
Key: ISPN-5992
URL: https://issues.jboss.org/browse/ISPN-5992
Project: Infinispan
Issue Type: Bug
Components: Server
Affects Versions: 8.0.2.Final
Reporter: Radim Vansa
REST server uses String-based keys; therefore AnyEquivalence works on keys. However, the data accepted are byte[], and value equivalence is set to AnyEquivalence, too. This means that replace() command which is used in {{Server.putOrReplace}} does not work when the write is executed on non-owner.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 1 month
[JBoss JIRA] (ISPN-5879) XSite client failover - ensure TcpTransportFactory.trySwitchCluster thread safety
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-5879?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-5879:
-----------------------------------------------
Vaclav Dedik <vdedik(a)redhat.com> changed the Status of [bug 1273795|https://bugzilla.redhat.com/show_bug.cgi?id=1273795] from ASSIGNED to POST
> XSite client failover - ensure TcpTransportFactory.trySwitchCluster thread safety
> ---------------------------------------------------------------------------------
>
> Key: ISPN-5879
> URL: https://issues.jboss.org/browse/ISPN-5879
> Project: Infinispan
> Issue Type: Bug
> Components: Cross-Site Replication, Remote Protocols
> Reporter: Matej Čimbora
> Assignee: Galder Zamarreño
> Priority: Critical
> Fix For: 8.1.0.CR1
>
>
> When reusing a HotRod client with several threads, site can be accidentally switched multiple times by threads invoking TcpTransportFactory.trySwitchCluster. This occurs when the threads attain 'maxRetries' limit at the same time, each of them being able to invoke TcpTransportFactory..updateServers with different 'clusterAddresses' parameter. This can lead to unpredictable result (e.g. switching back to failed cluster, while the other one (backup) is up and running).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 1 month