September 2015 - infinispan-issues

[JBoss JIRA] (ISPN-5780) SumAccumulator should behave according to JPA spec

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-5780?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-5780: -------------------------------- Status: Pull Request Sent (was: Coding In Progress) Git Pull Request: https://github.com/infinispan/infinispan/pull/3717 > SumAccumulator should behave according to JPA spec > -------------------------------------------------- > > Key: ISPN-5780 > URL: https://issues.jboss.org/browse/ISPN-5780 > Project: Infinispan > Issue Type: Bug > Components: Embedded Querying > Affects Versions: 8.0.0.Final > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 8.1.0.Alpha1 > > > Currently it just preserves the type of the field, which can easily lead to overflow. The JPA spec tries to avoid it by widening the numeric type, see 10.2.7.4. JPQL Aggregate Functions of JPA spec here: http://docs.oracle.com/cd/E12839_01/apirefs.1111/e13946/ejb3_langref.html -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5783) Cache.put(null, null) leaks an implicit transaction

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-5783?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-5783: ------------------------------- Status: Open (was: New) > Cache.put(null, null) leaks an implicit transaction > --------------------------------------------------- > > Key: ISPN-5783 > URL: https://issues.jboss.org/browse/ISPN-5783 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 8.0.1.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 8.1.0.Alpha1 > > > {{null}} keys and values are not supported, and {{Cache.put(null, null)}} will throw a {{NullPointerException}}. But the null check happens after the implicit transaction was created, and it doesn't clean it up before throwing the exception. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5783) Cache.put(null, null) leaks an implicit transaction

by Dan Berindei (JIRA)

Dan Berindei created ISPN-5783: ---------------------------------- Summary: Cache.put(null, null) leaks an implicit transaction Key: ISPN-5783 URL: https://issues.jboss.org/browse/ISPN-5783 Project: Infinispan Issue Type: Bug Components: Core Affects Versions: 8.0.1.Final Reporter: Dan Berindei Assignee: Dan Berindei Fix For: 8.1.0.Alpha1 {{null}} keys and values are not supported, and {{Cache.put(null, null)}} will throw a {{NullPointerException}}. But the null check happens after the implicit transaction was created, and it doesn't clean it up before throwing the exception. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5758) HotRod client try to unmarhall an object on get() no matter whether the put() use a byte[] or not

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-5758?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-5758: ----------------------------------- Status: Pull Request Sent (was: Coding In Progress) Git Pull Request: https://github.com/infinispan/infinispan/pull/3716 > HotRod client try to unmarhall an object on get() no matter whether the put() use a byte[] or not > ------------------------------------------------------------------------------------------------- > > Key: ISPN-5758 > URL: https://issues.jboss.org/browse/ISPN-5758 > Project: Infinispan > Issue Type: Bug > Components: hot, Marshalling > Affects Versions: 8.0.1.Final > Reporter: Wolf-Dieter Fink > Assignee: Galder Zamarreño > Labels: hotrod, hotrod-java-client > Fix For: 8.1.0.Alpha1, 8.1.0.Final > > Attachments: reproducer.zip > > > If a client put an object as byte[] into the cache, which is a self serialized class, the get will return the original class (if it is in the class path) instead of the byte[]. > This is incompatible to ISPN5 here the byte[] is returned in any case. > It seems this in unintentional due to the smart 'compatibility' mode at client side > https://github.com/infinispan/infinispan/blob/master/client/hotrod-client... > The client should be able to get the same class type back -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5357) Hot Rod protocol 3.0

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-5357?page=com.atlassian.jira.plugin.... ] Galder Zamarreño commented on ISPN-5357: ---------------------------------------- Separate response status into two fields: the status itself (success, error, failure...etc), and a flags section indicating whether the previous value is returned, or compatibility is enabled (see ISPN-5758) > Hot Rod protocol 3.0 > -------------------- > > Key: ISPN-5357 > URL: https://issues.jboss.org/browse/ISPN-5357 > Project: Infinispan > Issue Type: Enhancement > Reporter: Galder Zamarreño > > A binary protocol rethink is needed to take better advantage of CPUs and buffering. This is based on the ideas of Martin Thompson's Simple Binary Encoding [blog post|http://mechanical-sympathy.blogspot.cz/2014/05/simple-binary-encoding.html] > In essence, we need to move Hot Rod protocol towards having mostly fixed size fields, hence getting rid of `vInt` and `vLong` formats which although safe some bytes, they hinder long stream reading patterns. > An optional part here would be whether to consider using SBE directly, but this JIRA should be mostly oriented at making sure we have a protocol that can be read fast and efficiently. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5716) Functional documentation still references *Lambda* classes

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-5716?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-5716: ----------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 8.0.1.Final (was: 8.0.2.Final) Resolution: Done > Functional documentation still references *Lambda* classes > ---------------------------------------------------------- > > Key: ISPN-5716 > URL: https://issues.jboss.org/browse/ISPN-5716 > Project: Infinispan > Issue Type: Bug > Components: Documentation-Core > Affects Versions: 8.0.0.Final > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 8.1.0.Final, 8.0.1.Final > > > To avoid confusion, these were changed to have *Functions* in them. Fix documentation. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5736) Verify Hot Rod protocol documentation inconsistencies

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-5736?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-5736: ------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 8.0.1.Final (was: 8.0.2.Final) Resolution: Done > Verify Hot Rod protocol documentation inconsistencies > ----------------------------------------------------- > > Key: ISPN-5736 > URL: https://issues.jboss.org/browse/ISPN-5736 > Project: Infinispan > Issue Type: Task > Components: Documentation-Core > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 8.1.0.Final, 8.0.1.Final > > > Link for Hot Rod protocol 1.4 directs to: http://infinispan.org/docs/8.0.x/user_guide/user_guide.html#_hot_rod_prot... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4720) Values data reverts in Compatibilty mode in Infinispan 8.0.0Beta3

by Prashant Thakur (JIRA)

[ https://issues.jboss.org/browse/ISPN-4720?page=com.atlassian.jira.plugin.... ] Prashant Thakur updated ISPN-4720: ---------------------------------- Summary: Values data reverts in Compatibilty mode in Infinispan 8.0.0Beta3 (was: Values data reverts in Compatibilty mode in Infinispan 6.0.2) > Values data reverts in Compatibilty mode in Infinispan 8.0.0Beta3 > ----------------------------------------------------------------- > > Key: ISPN-4720 > URL: https://issues.jboss.org/browse/ISPN-4720 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 6.0.2.Final, 7.2.0.Final, 8.0.0.Beta3 > Environment: Linux 3.15.8-200.fc20.x86_64 > Reporter: Prashant Thakur > Assignee: Galder Zamarreño > Priority: Critical > Labels: Infinispan > Fix For: 7.0.0.Alpha3 > > Attachments: BaseDistributionInterceptor.java, distributed_cache_configuration.xml, tc1.zip, tc2.out, tc3.out, tc4.out, TxDistributionInterceptor.java > > > 1) The owners of the keys are Node1 and Node4 > 0911 10:56:56,552 TRACE [org.infinispan.interceptors.distribution.TxDistributionInterceptor] [remote-thread-0] (TxDistributionInterceptor.java:362) - Not doing a remote get for key 1029 since entry is mapped to current node (blrsrv42-19390), or is in L1. Owners are [blrsrv29-4565, blrsrv42-19390] > 2. The request for update came to Node2 a non-owner. > 0911 10:56:56,388 TRACE [org.infinispan.statetransfer.StateTransferInterceptor] [HotRodServerWorker-2] (StateTransferInterceptor.java:203) - handleNonTxWriteCommand for command ReplaceCommand{key=1029, oldValue=TestData{id=1029, field1=XXXXXX}, newValue=TestData{id=1029, field1=cyyy}, metadata=EmbeddedMetadata{version=NumericVersion{version=844433520066561}}, flags=[OPERATION_HOTROD], successful=true, valueMatcher=MATCH_EXPECTED} > 3. The updates are happening in Node1 and overwritten again with old data present in OOB Thread. Because of which the Node1, reverts back to the old data. > 4. While doing a get from Node 1 we again receive the old value -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4720) Values data reverts in Compatibilty mode in Infinispan 6.0.2

by Prashant Thakur (JIRA)

[ https://issues.jboss.org/browse/ISPN-4720?page=com.atlassian.jira.plugin.... ] Prashant Thakur updated ISPN-4720: ---------------------------------- Affects Version/s: 8.0.0.Beta3 > Values data reverts in Compatibilty mode in Infinispan 6.0.2 > ------------------------------------------------------------ > > Key: ISPN-4720 > URL: https://issues.jboss.org/browse/ISPN-4720 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 6.0.2.Final, 7.2.0.Final, 8.0.0.Beta3 > Environment: Linux 3.15.8-200.fc20.x86_64 > Reporter: Prashant Thakur > Assignee: Galder Zamarreño > Priority: Critical > Labels: Infinispan > Fix For: 7.0.0.Alpha3 > > Attachments: BaseDistributionInterceptor.java, distributed_cache_configuration.xml, tc1.zip, tc2.out, tc3.out, tc4.out, TxDistributionInterceptor.java > > > 1) The owners of the keys are Node1 and Node4 > 0911 10:56:56,552 TRACE [org.infinispan.interceptors.distribution.TxDistributionInterceptor] [remote-thread-0] (TxDistributionInterceptor.java:362) - Not doing a remote get for key 1029 since entry is mapped to current node (blrsrv42-19390), or is in L1. Owners are [blrsrv29-4565, blrsrv42-19390] > 2. The request for update came to Node2 a non-owner. > 0911 10:56:56,388 TRACE [org.infinispan.statetransfer.StateTransferInterceptor] [HotRodServerWorker-2] (StateTransferInterceptor.java:203) - handleNonTxWriteCommand for command ReplaceCommand{key=1029, oldValue=TestData{id=1029, field1=XXXXXX}, newValue=TestData{id=1029, field1=cyyy}, metadata=EmbeddedMetadata{version=NumericVersion{version=844433520066561}}, flags=[OPERATION_HOTROD], successful=true, valueMatcher=MATCH_EXPECTED} > 3. The updates are happening in Node1 and overwritten again with old data present in OOB Thread. Because of which the Node1, reverts back to the old data. > 4. While doing a get from Node 1 we again receive the old value -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4720) Values data reverts in Compatibilty mode in Infinispan 6.0.2

by Prashant Thakur (JIRA)

[ https://issues.jboss.org/browse/ISPN-4720?page=com.atlassian.jira.plugin.... ] Prashant Thakur commented on ISPN-4720: --------------------------------------- Hi Galder Zamarreño , can you please let us know if some more information is required. Its breaking in basic default settings as well. Regards, Prashant Thakur > Values data reverts in Compatibilty mode in Infinispan 6.0.2 > ------------------------------------------------------------ > > Key: ISPN-4720 > URL: https://issues.jboss.org/browse/ISPN-4720 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 6.0.2.Final, 7.2.0.Final > Environment: Linux 3.15.8-200.fc20.x86_64 > Reporter: Prashant Thakur > Assignee: Galder Zamarreño > Priority: Critical > Labels: Infinispan > Fix For: 7.0.0.Alpha3 > > Attachments: BaseDistributionInterceptor.java, distributed_cache_configuration.xml, tc1.zip, tc2.out, tc3.out, tc4.out, TxDistributionInterceptor.java > > > 1) The owners of the keys are Node1 and Node4 > 0911 10:56:56,552 TRACE [org.infinispan.interceptors.distribution.TxDistributionInterceptor] [remote-thread-0] (TxDistributionInterceptor.java:362) - Not doing a remote get for key 1029 since entry is mapped to current node (blrsrv42-19390), or is in L1. Owners are [blrsrv29-4565, blrsrv42-19390] > 2. The request for update came to Node2 a non-owner. > 0911 10:56:56,388 TRACE [org.infinispan.statetransfer.StateTransferInterceptor] [HotRodServerWorker-2] (StateTransferInterceptor.java:203) - handleNonTxWriteCommand for command ReplaceCommand{key=1029, oldValue=TestData{id=1029, field1=XXXXXX}, newValue=TestData{id=1029, field1=cyyy}, metadata=EmbeddedMetadata{version=NumericVersion{version=844433520066561}}, flags=[OPERATION_HOTROD], successful=true, valueMatcher=MATCH_EXPECTED} > 3. The updates are happening in Node1 and overwritten again with old data present in OOB Thread. Because of which the Node1, reverts back to the old data. > 4. While doing a get from Node 1 we again receive the old value -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 8 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues September 2015