January 2015 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-4182) ClusteredCacheWithAsyncDirTest does not properly ensure each db url is unique for parallel tests

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-4182?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-4182: ---------------------------------- Fix Version/s: 7.1.0.CR1 (was: 7.1.0.Beta1) > ClusteredCacheWithAsyncDirTest does not properly ensure each db url is unique for parallel tests > ------------------------------------------------------------------------------------------------ > > Key: ISPN-4182 > URL: https://issues.jboss.org/browse/ISPN-4182 > Project: Infinispan > Issue Type: Bug > Components: Embedded Querying > Affects Versions: 7.0.0.Alpha1 > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Labels: 630 > Fix For: 7.1.0.CR1 > > > The test should ensure the db url is not the same across nodes of all parallel tests because they all run in the same jvm and the H2 instances might collide. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4247) JPA cachestore fails with Oracle12c and PostgreadPlus 9

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-4247?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-4247: ---------------------------------- Fix Version/s: 7.1.0.CR1 (was: 7.1.0.Beta1) > JPA cachestore fails with Oracle12c and PostgreadPlus 9 > ------------------------------------------------------- > > Key: ISPN-4247 > URL: https://issues.jboss.org/browse/ISPN-4247 > Project: Infinispan > Issue Type: Bug > Components: Core > Reporter: Vojtech Juranek > Labels: 63gablocker > Fix For: 7.0.0.Alpha4, 7.1.0.CR1 > > > JPA cache store fails on Oracle12c and PostgreadPlus 9 as Hibernate is not able to determine the dialect to be used: > {noformat} > [java] Caused by: org.hibernate.HibernateException: Unable to determine Dialect to use [name=Oracle, majorVersion=12]; user must register resolver or explicitly set 'hibernate.dialect' > {noformat} > resp. > {noformat} > [java] Caused by: org.hibernate.HibernateException: Unable to determine Dialect to use [name=EnterpriseDB, majorVersion=9]; user must register resolver or explicitly set 'hibernate.dialect' > {noformat} > To fix it, HIbernate upgrade is needed. PotgresPlus is fixed in 4.3.0.Beta4 (tracking JIRA is [HHH-8349|https://hibernate.atlassian.net/browse/HHH-8349]), Oracle12c is fixed in Hibernate 5.0.0 (tracking JIRA is [HHH-9044|https://hibernate.atlassian.net/browse/HHH-9044]) -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4159) DefaultTwoWayKey2StringMapper encodes objects to strings in a manner that is incompatible with string handling of some databases

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-4159?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-4159: ---------------------------------- Fix Version/s: 7.1.0.CR1 (was: 7.1.0.Beta1) > DefaultTwoWayKey2StringMapper encodes objects to strings in a manner that is incompatible with string handling of some databases > -------------------------------------------------------------------------------------------------------------------------------- > > Key: ISPN-4159 > URL: https://issues.jboss.org/browse/ISPN-4159 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores > Affects Versions: 6.0.0.Final > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 7.1.0.CR1 > > > DefaultTwoWayKey2StringMapper uses two neat tricks. > 1. it does not encode all supported types, it only encodes non-Strings. Strings are kept unmodified. > 2. it uses a special prefix (unicode char 0xfeff) to mark which strings were encoded and which are plain. > Unfortunately some databases, notably MySql, interpret the endianness mark (0xfeff, 0xfffe), convert to native byte order and then drop it. > This leaves us with no clue the string is not an actual String but an encoded representation of another type. This misinterpretation leads later to ClassCastExceptions in various places in core and user code. > Proposed fix: get rid of #1 and #2 optimisations. Encode all objects, including Strings and always use the ?n prefix (where n stands for the original type). Drop the 0xFEFF marker prefix. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4140) Clear command doesn't acquire any remote locks in pessimistic mode

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-4140?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-4140: ---------------------------------- Fix Version/s: 7.1.0.CR1 (was: 7.1.0.Beta1) > Clear command doesn't acquire any remote locks in pessimistic mode > ------------------------------------------------------------------ > > Key: ISPN-4140 > URL: https://issues.jboss.org/browse/ISPN-4140 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 6.0.2.Final > Reporter: Dan Berindei > Fix For: 7.1.0.CR1 > > > This is related to ISPN-2530. The 1-phase prepare command is now sent remotely, but it doesn't acquire any locks. The clear command doesn't trigger any remote LockControlCommands either. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4077) Infinispan REST server welcome page has links to old documetation pages

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-4077?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-4077: ---------------------------------- Fix Version/s: 7.1.0.CR1 (was: 7.1.0.Beta1) > Infinispan REST server welcome page has links to old documetation pages > ----------------------------------------------------------------------- > > Key: ISPN-4077 > URL: https://issues.jboss.org/browse/ISPN-4077 > Project: Infinispan > Issue Type: Bug > Components: Remote Protocols, Server > Affects Versions: 6.0.0.Final > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 7.1.0.CR1 > > > Links to old CMS should be switched towards the new infinispan.org. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4167) DummyBaseTransactionManager doesn't clean up when rollback fails

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-4167?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-4167: ---------------------------------- Fix Version/s: 7.1.0.CR1 (was: 7.1.0.Beta1) > DummyBaseTransactionManager doesn't clean up when rollback fails > ---------------------------------------------------------------- > > Key: ISPN-4167 > URL: https://issues.jboss.org/browse/ISPN-4167 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 6.0.2.Final > Reporter: Dan Berindei > Fix For: 7.1.0.CR1 > > > If the rollback fails, the thread local holding the current transaction is not cleared, and it becomes impossible to start a new transaction on the same thread. > One way this can happen is when Infinispan registers as a XA transaction, but DummyTransactionManager is not configured to use XA Xids: > {noformat} > 12:47:57,169 ERROR (testng-ReplicationExceptionTest:) [DummyTransaction] ISPN000098: Exception while rollback > java.lang.UnsupportedOperationException > at org.infinispan.transaction.tm.DummyNoXaXid.getBranchQualifier(DummyNoXaXid.java:30) > at org.infinispan.transaction.xa.recovery.SerializableXid.<init>(SerializableXid.java:37) > at org.infinispan.transaction.xa.TransactionXaAdapter.convertXid(TransactionXaAdapter.java:251) > at org.infinispan.transaction.xa.TransactionXaAdapter.rollback(TransactionXaAdapter.java:122) > at org.infinispan.transaction.tm.DummyTransaction.runRollback(DummyTransaction.java:281) > at org.infinispan.transaction.tm.DummyTransaction.rollback(DummyTransaction.java:88) > at org.infinispan.transaction.tm.DummyBaseTransactionManager.rollback(DummyBaseTransactionManager.java:104) > at org.infinispan.CacheImpl.tryRollback(CacheImpl.java:1442) > at org.infinispan.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1418) > at org.infinispan.CacheImpl.putInternal(CacheImpl.java:894) > at org.infinispan.CacheImpl.put(CacheImpl.java:886) > at org.infinispan.CacheImpl.put(CacheImpl.java:1461) > at org.infinispan.CacheImpl.put(CacheImpl.java:225) > at org.infinispan.tx.synchronisation.ReplicationExceptionTest.testSyncReplTimeout(ReplicationExceptionTest.java:54) > {noformat} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4088) Modify signature of Query/CacheQuery.getResultSize() and related offset/pagination methods to return long

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-4088?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-4088: ---------------------------------- Fix Version/s: 7.1.0.CR1 (was: 7.1.0.Beta1) > Modify signature of Query/CacheQuery.getResultSize() and related offset/pagination methods to return long > --------------------------------------------------------------------------------------------------------- > > Key: ISPN-4088 > URL: https://issues.jboss.org/browse/ISPN-4088 > Project: Infinispan > Issue Type: Feature Request > Components: Embedded Querying, Remote Querying > Affects Versions: 6.0.0.Final > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Labels: 64QueryBlockers > Fix For: 7.1.0.CR1 > > > The method exists in both new DSL and the classic query api. > It should be clarified whether this method and the related pagination methods should use int or long for specifying offsets within the data, also should decide if the total number of results / results per page is a long or an int - and update all involved method signatures to have a unitary treatment of this issue. > It appears that recent Lucene versions can offer the number of results as long, while older ones offer it as int (should be verified). > This issue was raised in a github conversation here: https://github.com/infinispan/infinispan/pull/2410 -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4176) Forcing a commit via recovery RecoveryAdminOperations may create a duplicate GlobalTransaction

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-4176?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-4176: ---------------------------------- Fix Version/s: 7.1.0.CR1 (was: 7.1.0.Beta1) > Forcing a commit via recovery RecoveryAdminOperations may create a duplicate GlobalTransaction > ---------------------------------------------------------------------------------------------- > > Key: ISPN-4176 > URL: https://issues.jboss.org/browse/ISPN-4176 > Project: Infinispan > Issue Type: Bug > Components: Core, Transactions > Affects Versions: 6.0.2.Final > Reporter: Dan Berindei > Fix For: 7.1.0.CR1 > > > {{RecoveryManagerImpl.forceTransactionCompletion()}} modifies the {{GlobalTransaction.address}} of the transaction being committed so that the local node is the originator. But the {{GlobalTransaction.id}} stays the same, we could have two transactions with the same {{GlobalTransaction}} - which shouldn't be possible. > We can't remove the code that changes the {{GlobalTransaction.address}}, because we use it as the originator in other parts of the code. So the only option is to generate a new id as well. > But there is another problem: RecoveryAwareTransactionTable.cleanupStaleTransactions() doesn't release the locks acquired by that transaction on the primary node. So forcing a commit with a different GlobalTransaction will not be able to acquire the locks that were held by the original transaction. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4136) Declarative config for REST rawValues

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-4136?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-4136: ---------------------------------- Fix Version/s: 7.1.0.CR1 (was: 7.1.0.Beta1) > Declarative config for REST rawValues > ------------------------------------- > > Key: ISPN-4136 > URL: https://issues.jboss.org/browse/ISPN-4136 > Project: Infinispan > Issue Type: Task > Components: Configuration > Reporter: Tristan Tarrant > Fix For: 7.1.0.CR1 > > > Once ISPN-3514 is in we can add support for the REST rawValues boolean in the new 7.0 parser -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4390) CHMv8 leaks ThreadLocal

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-4390?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-4390: ---------------------------------- Fix Version/s: 7.1.0.CR1 (was: 7.1.0.Beta1) > CHMv8 leaks ThreadLocal > ----------------------- > > Key: ISPN-4390 > URL: https://issues.jboss.org/browse/ISPN-4390 > Project: Infinispan > Issue Type: Bug > Components: Core > Reporter: Sanne Grinovero > Fix For: 7.1.0.CR1 > > > As discussed on: http://lists.jboss.org/pipermail/infinispan-dev/2014-June/015055.html -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues January 2015