[JBoss JIRA] (ISPN-8429) TX manager fails to lock off-heap entries
by Vojtech Juranek (JIRA)
[ https://issues.jboss.org/browse/ISPN-8429?page=com.atlassian.jira.plugin.... ]
Vojtech Juranek commented on ISPN-8429:
---------------------------------------
[~pruivo] could you please elaborate more? If I understand the test correctly, it starts transaction, stores entry ({{<String, String>}}) into the cache, prepares commit and checks if the entry is locked. From user perspective it should behave in the same way, no matter if underlying container stores entries as object or byte arrays. The fact that off-heap stores entties as byte arrays is an implementation detail and shouldn't affect existing API, IMHO.
> TX manager fails to lock off-heap entries
> -----------------------------------------
>
> Key: ISPN-8429
> URL: https://issues.jboss.org/browse/ISPN-8429
> Project: Infinispan
> Issue Type: Bug
> Components: Off Heap, Transactions
> Affects Versions: 9.0.1.Final, 9.1.1.Final
> Reporter: Vojtech Juranek
>
> TX manager seems to fail lock off-heap entries properly. E.g. running {{LocalOptimisticTxTest}} with off-heap container fails with
> {noformat}
> java.lang.AssertionError: expected [true] but found [false]
> at org.testng.Assert.fail(Assert.java:94)
> at org.testng.Assert.failNotEquals(Assert.java:494)
> at org.testng.Assert.assertTrue(Assert.java:42)
> at org.testng.Assert.assertTrue(Assert.java:52)
> at org.infinispan.tx.locking.LocalOptimisticTxTest.assertLocking(LocalOptimisticTxTest.java:63)
> at org.infinispan.tx.locking.AbstractLocalTest.testPut(AbstractLocalTest.java:29)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months
[JBoss JIRA] (ISPN-8429) TX manager fails to lock off-heap entries
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-8429?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo commented on ISPN-8429:
-----------------------------------
[~vjuranek] you can't just enable off-heap in the local tests. The local tests expect to have the {{String}} stored (and locked) but with off-heap the string is stored as binary. You will have to update the test to handle off-heap.
I guess this JIRA can be closed :)
> TX manager fails to lock off-heap entries
> -----------------------------------------
>
> Key: ISPN-8429
> URL: https://issues.jboss.org/browse/ISPN-8429
> Project: Infinispan
> Issue Type: Bug
> Components: Off Heap, Transactions
> Affects Versions: 9.0.1.Final, 9.1.1.Final
> Reporter: Vojtech Juranek
>
> TX manager seems to fail lock off-heap entries properly. E.g. running {{LocalOptimisticTxTest}} with off-heap container fails with
> {noformat}
> java.lang.AssertionError: expected [true] but found [false]
> at org.testng.Assert.fail(Assert.java:94)
> at org.testng.Assert.failNotEquals(Assert.java:494)
> at org.testng.Assert.assertTrue(Assert.java:42)
> at org.testng.Assert.assertTrue(Assert.java:52)
> at org.infinispan.tx.locking.LocalOptimisticTxTest.assertLocking(LocalOptimisticTxTest.java:63)
> at org.infinispan.tx.locking.AbstractLocalTest.testPut(AbstractLocalTest.java:29)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months
[JBoss JIRA] (ISPN-8429) TX manager fails to lock off-heap entries
by Vojtech Juranek (JIRA)
[ https://issues.jboss.org/browse/ISPN-8429?page=com.atlassian.jira.plugin.... ]
Vojtech Juranek commented on ISPN-8429:
---------------------------------------
this test (with {{LocalPessimisticTxTest}}) is part of https://github.com/infinispan/infinispan/pull/5525 (where it's commented out not to fail in CI)
> TX manager fails to lock off-heap entries
> -----------------------------------------
>
> Key: ISPN-8429
> URL: https://issues.jboss.org/browse/ISPN-8429
> Project: Infinispan
> Issue Type: Bug
> Components: Off Heap, Transactions
> Affects Versions: 9.0.1.Final, 9.1.1.Final
> Reporter: Vojtech Juranek
>
> TX manager seems to fail lock off-heap entries properly. E.g. running {{LocalOptimisticTxTest}} with off-heap container fails with
> {noformat}
> java.lang.AssertionError: expected [true] but found [false]
> at org.testng.Assert.fail(Assert.java:94)
> at org.testng.Assert.failNotEquals(Assert.java:494)
> at org.testng.Assert.assertTrue(Assert.java:42)
> at org.testng.Assert.assertTrue(Assert.java:52)
> at org.infinispan.tx.locking.LocalOptimisticTxTest.assertLocking(LocalOptimisticTxTest.java:63)
> at org.infinispan.tx.locking.AbstractLocalTest.testPut(AbstractLocalTest.java:29)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months
[JBoss JIRA] (ISPN-8429) TX manager fails to lock off-heap entries
by Vojtech Juranek (JIRA)
Vojtech Juranek created ISPN-8429:
-------------------------------------
Summary: TX manager fails to lock off-heap entries
Key: ISPN-8429
URL: https://issues.jboss.org/browse/ISPN-8429
Project: Infinispan
Issue Type: Bug
Components: Off Heap, Transactions
Affects Versions: 9.1.1.Final, 9.0.1.Final
Reporter: Vojtech Juranek
TX manager seems to fail lock off-heap entries properly. E.g. running {{LocalOptimisticTxTest}} with off-heap container fails with
{noformat}
java.lang.AssertionError: expected [true] but found [false]
at org.testng.Assert.fail(Assert.java:94)
at org.testng.Assert.failNotEquals(Assert.java:494)
at org.testng.Assert.assertTrue(Assert.java:42)
at org.testng.Assert.assertTrue(Assert.java:52)
at org.infinispan.tx.locking.LocalOptimisticTxTest.assertLocking(LocalOptimisticTxTest.java:63)
at org.infinispan.tx.locking.AbstractLocalTest.testPut(AbstractLocalTest.java:29)
{noformat}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months
[JBoss JIRA] (ISPN-8427) Support for non-String keys in the rest server
by Gustavo Fernandes (JIRA)
[ https://issues.jboss.org/browse/ISPN-8427?page=com.atlassian.jira.plugin.... ]
Gustavo Fernandes updated ISPN-8427:
------------------------------------
Description:
The rest server assumes keys are always String, causing limited interoperability between remote endpoints.
When a cache is written via Hot Rod, by default keys will be stored as {{byte[]}} produced via {{JBossMarshaller}} (the default marshaller), or a UTF-8 byte[] in case the {{UT8Marshaller}} is chosen.
The Rest server should accept keys in different formats than String, using an encoding for byte[] values like Base64, and pass in an special header with the key media type so that the server can use it.
With this capability, compat mode could be avoided when writing from Hot Rod and reading from Rest and vice versa
was:
The rest server assumes keys are always String, causing limited interoperability between remote endpoints.
When a cache is written via Hot Rod, by default keys will be stored as {{byte[]}} produced via {{JBossMarshaller}} (the default marshaller), or via UTF-8 in case the {{UT8Marshaller}} is chosen.
The Rest server should accept keys in different formats than String, using an encoding for byte[] values like Base64, and pass in an special header with the key media type so that the server can use it.
With this capability, compat mode could be avoided when writing from Hot Rod and reading from Rest and vice versa
> Support for non-String keys in the rest server
> ----------------------------------------------
>
> Key: ISPN-8427
> URL: https://issues.jboss.org/browse/ISPN-8427
> Project: Infinispan
> Issue Type: Enhancement
> Components: Server
> Affects Versions: 9.2.0.Alpha1
> Reporter: Gustavo Fernandes
> Assignee: Gustavo Fernandes
>
> The rest server assumes keys are always String, causing limited interoperability between remote endpoints.
> When a cache is written via Hot Rod, by default keys will be stored as {{byte[]}} produced via {{JBossMarshaller}} (the default marshaller), or a UTF-8 byte[] in case the {{UT8Marshaller}} is chosen.
> The Rest server should accept keys in different formats than String, using an encoding for byte[] values like Base64, and pass in an special header with the key media type so that the server can use it.
> With this capability, compat mode could be avoided when writing from Hot Rod and reading from Rest and vice versa
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months
[JBoss JIRA] (ISPN-8427) Support for non-String keys in the rest server
by Gustavo Fernandes (JIRA)
[ https://issues.jboss.org/browse/ISPN-8427?page=com.atlassian.jira.plugin.... ]
Gustavo Fernandes updated ISPN-8427:
------------------------------------
Description:
The rest server assumes keys are always String, causing limited interoperability between remote endpoints.
When a cache is written via Hot Rod, by default keys will be stored as marshalled {{java.lang.String}} via {{JBossMarshaller}} (the default marshaller), or via UTF-8 in case the {{UT8Marshaller}} is chosen.
The Rest server should accept keys in different formats than String, using an encoding for byte[] values like Base64, and pass in an special header with the key media type so that the server can use it.
With this capability, compat mode could be avoided when writing from Hot Rod and reading from Rest and vice versa
was:
The rest server assumes keys are always String, causing interoperability between remote endpoints limited.
When a cache is written via Hot Rod, by default keys will be stored as marshalled {{java.lang.String}} via {{JBossMarshaller}} (the default marshaller), or via UTF-8 in case the {{UT8Marshaller}} is chosen.
The Rest server should accept keys in different formats than String, using an encoding for byte[] values like Base64, and pass in an special header with the key media type so that the server can use it.
With this capability, compat mode could be avoided when writing from Hot Rod and reading from Rest and vice versa
> Support for non-String keys in the rest server
> ----------------------------------------------
>
> Key: ISPN-8427
> URL: https://issues.jboss.org/browse/ISPN-8427
> Project: Infinispan
> Issue Type: Enhancement
> Components: Server
> Affects Versions: 9.2.0.Alpha1
> Reporter: Gustavo Fernandes
> Assignee: Gustavo Fernandes
>
> The rest server assumes keys are always String, causing limited interoperability between remote endpoints.
> When a cache is written via Hot Rod, by default keys will be stored as marshalled {{java.lang.String}} via {{JBossMarshaller}} (the default marshaller), or via UTF-8 in case the {{UT8Marshaller}} is chosen.
> The Rest server should accept keys in different formats than String, using an encoding for byte[] values like Base64, and pass in an special header with the key media type so that the server can use it.
> With this capability, compat mode could be avoided when writing from Hot Rod and reading from Rest and vice versa
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months