September 2015 - infinispan-issues

[JBoss JIRA] (ISPN-5753) SIFS can reincarnate deleted entries during startup

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/ISPN-5753?page=com.atlassian.jira.plugin.... ] Radim Vansa updated ISPN-5753: ------------------------------ Status: Open (was: New) > SIFS can reincarnate deleted entries during startup > --------------------------------------------------- > > Key: ISPN-5753 > URL: https://issues.jboss.org/browse/ISPN-5753 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores > Affects Versions: 8.0.1.Final, 7.2.5.Final > Reporter: Radim Vansa > Assignee: Radim Vansa > > Since we don't keep deleted entries in index, we can't see that an entry was deleted (don't know it's last seqId) if files are read in unlucky order. Then we could add the entry into the index even though it was deleted. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5753) SIFS can reincarnate deleted entries during startup

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/ISPN-5753?page=com.atlassian.jira.plugin.... ] Radim Vansa updated ISPN-5753: ------------------------------ Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/3715 > SIFS can reincarnate deleted entries during startup > --------------------------------------------------- > > Key: ISPN-5753 > URL: https://issues.jboss.org/browse/ISPN-5753 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores > Affects Versions: 8.0.1.Final, 7.2.5.Final > Reporter: Radim Vansa > Assignee: Radim Vansa > > Since we don't keep deleted entries in index, we can't see that an entry was deleted (don't know it's last seqId) if files are read in unlucky order. Then we could add the entry into the index even though it was deleted. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5497) MetadataAPIDefaultExpiryTest.testDefaultLifespanReplaceWithOldValue and MetadataAPIDefaultExpiryTest.testDefaultLifespanPutIfAbsent fail randomly

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-5497?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-5497: ---------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 8.1.0.Alpha1 8.1.0.Final 8.0.2.Final Resolution: Done > MetadataAPIDefaultExpiryTest.testDefaultLifespanReplaceWithOldValue and MetadataAPIDefaultExpiryTest.testDefaultLifespanPutIfAbsent fail randomly > ------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: ISPN-5497 > URL: https://issues.jboss.org/browse/ISPN-5497 > Project: Infinispan > Issue Type: Bug > Affects Versions: 7.2.1.Final > Reporter: Roman Macor > Assignee: Dan Berindei > Fix For: 8.1.0.Alpha1, 8.1.0.Final, 8.0.2.Final > > > MetadataAPIDefaultExpiryTest.testDefaultLifespanPutIfAbsent and MetadataAPIDefaultExpiryTest.testDefaultLifespanReplaceWithOldValue fail randomly with assertion error > org.infinispan.api.MetadataAPIDefaultExpiryTest.testDefaultLifespanReplaceWithOldValue > Error Message > expected:<v11> but was:<null> > Stacktrace > java.lang.AssertionError: expected:<v11> but was:<null> > at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:101) > at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:108) > at org.infinispan.api.MetadataAPIDefaultExpiryTest.expectCachedThenExpired(MetadataAPIDefaultExpiryTest.java:85) > at org.infinispan.api.MetadataAPIDefaultExpiryTest.testDefaultLifespanReplaceWithOldValue(MetadataAPIDefaultExpiryTest.java:49) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:80) > at org.testng.internal.Invoker.invokeMethod(Invoker.java:714) > at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901) > at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231) > at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127) > at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111) > at org.testng.TestRunner.privateRun(TestRunner.java:767) > at org.testng.TestRunner.run(TestRunner.java:617) > at org.testng.SuiteRunner.runTest(SuiteRunner.java:334) > at org.testng.SuiteRunner.access$000(SuiteRunner.java:37) > at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:368) > at org.testng.internal.thread.ThreadUtil$2.call(ThreadUtil.java:64) > at java.util.concurrent.FutureTask.run(FutureTask.java:262) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:745) > org.infinispan.api.MetadataAPIDefaultExpiryTest.testDefaultLifespanPutIfAbsent > Error Message > expected:<v1> but was:<null> > Stacktrace > java.lang.AssertionError: expected:<v1> but was:<null> > at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:101) > at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:108) > at org.infinispan.api.MetadataAPIDefaultExpiryTest.expectCachedThenExpired(MetadataAPIDefaultExpiryTest.java:85) > at org.infinispan.api.MetadataAPIDefaultExpiryTest.testDefaultLifespanPutIfAbsent(MetadataAPIDefaultExpiryTest.java:57) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:80) > at org.testng.internal.Invoker.invokeMethod(Invoker.java:714) > at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901) > at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231) > at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127) > at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111) > at org.testng.TestRunner.privateRun(TestRunner.java:767) > at org.testng.TestRunner.run(TestRunner.java:617) > at org.testng.SuiteRunner.runTest(SuiteRunner.java:334) > at org.testng.SuiteRunner.access$000(SuiteRunner.java:37) > at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:368) > at org.testng.internal.thread.ThreadUtil$2.call(ThreadUtil.java:64) > at java.util.concurrent.FutureTask.run(FutureTask.java:262) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:745) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5740) HotRod client write buffer is too large

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-5740?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-5740: ---------------------------------- Fix Version/s: 8.0.2.Final > HotRod client write buffer is too large > --------------------------------------- > > Key: ISPN-5740 > URL: https://issues.jboss.org/browse/ISPN-5740 > Project: Infinispan > Issue Type: Bug > Components: Server > Affects Versions: 8.0.0.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 8.1.0.Alpha1, 8.1.0.Final, 8.0.2.Final > > > The ISPN-1015 fix added a buffer to the HotRod client transport to reduce the number of syscalls. But that buffer's size is not fixed, instead it's based on {{Socket.getSendBufferSize()}}, which in turn is based on the kernel's {{net.core.wmem_max}}. > JGroups needs {{net.core.wmem_max}} greater or equal than {{UDP.ucast_send_buf_size}}, which is 1MB by default. That is probably too much for the {{TcpTransport}}'s buffer, because the buffer is also duplicated in the OS. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5740) HotRod client write buffer is too large

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-5740?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-5740: ---------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 8.1.0.Final Resolution: Done > HotRod client write buffer is too large > --------------------------------------- > > Key: ISPN-5740 > URL: https://issues.jboss.org/browse/ISPN-5740 > Project: Infinispan > Issue Type: Bug > Components: Server > Affects Versions: 8.0.0.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 8.1.0.Alpha1, 8.1.0.Final > > > The ISPN-1015 fix added a buffer to the HotRod client transport to reduce the number of syscalls. But that buffer's size is not fixed, instead it's based on {{Socket.getSendBufferSize()}}, which in turn is based on the kernel's {{net.core.wmem_max}}. > JGroups needs {{net.core.wmem_max}} greater or equal than {{UDP.ucast_send_buf_size}}, which is 1MB by default. That is probably too much for the {{TcpTransport}}'s buffer, because the buffer is also duplicated in the OS. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5781) Upgrade server to WildFly 10.0.0.CR1

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-5781?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-5781: ---------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/3714 > Upgrade server to WildFly 10.0.0.CR1 > ------------------------------------ > > Key: ISPN-5781 > URL: https://issues.jboss.org/browse/ISPN-5781 > Project: Infinispan > Issue Type: Task > Components: Server > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 8.1.0.Final > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5781) Upgrade server to WildFly 10.0.0.CR1

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-5781?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-5781: ---------------------------------- Status: Open (was: New) > Upgrade server to WildFly 10.0.0.CR1 > ------------------------------------ > > Key: ISPN-5781 > URL: https://issues.jboss.org/browse/ISPN-5781 > Project: Infinispan > Issue Type: Task > Components: Server > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 8.1.0.Final > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 6 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: ----------------------------------- Fix Version/s: 8.1.0.Alpha1 8.1.0.Final > 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)

10 years, 6 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.... ] Work on ISPN-5758 started by Galder Zamarreño. ---------------------------------------------- > 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)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5520) Add XSite failover for HotRod clients

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-5520?page=com.atlassian.jira.plugin.... ] Work on ISPN-5520 started by Galder Zamarreño. ---------------------------------------------- > Add XSite failover for HotRod clients > ------------------------------------- > > Key: ISPN-5520 > URL: https://issues.jboss.org/browse/ISPN-5520 > Project: Infinispan > Issue Type: Feature Request > Components: Cross-Site Replication, Remote Protocols > Reporter: Tristan Tarrant > Assignee: Galder Zamarreño > Priority: Critical > Fix For: 8.1.0.Final > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 6 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 September 2015