February 2015 - infinispan-issues

[JBoss JIRA] (ISPN-5247) RESTAsyncIT.testPutOperation fails randomly

by Roman Macor (JIRA)

Roman Macor created ISPN-5247: --------------------------------- Summary: RESTAsyncIT.testPutOperation fails randomly Key: ISPN-5247 URL: https://issues.jboss.org/browse/ISPN-5247 Project: Infinispan Issue Type: Bug Components: Test Suite - Server Affects Versions: 7.2.0.Alpha1 Reporter: Roman Macor RESTAsyncIT.testPutOperation fails randomly with Error Message PUT : async- 12881, sync- 9373 Stacktrace java.lang.AssertionError: PUT : async- 12881, sync- 9373 at org.junit.Assert.fail(Assert.java:88) at org.junit.Assert.assertTrue(Assert.java:41) at org.infinispan.server.test.client.rest.RESTAsyncIT.testPutOperation(RESTAsyncIT.java:85) -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5180) Hot Rod type converter in Compatibility should not marshall a byte[] again

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-5180?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated ISPN-5180: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1196277 > Hot Rod type converter in Compatibility should not marshall a byte[] again > -------------------------------------------------------------------------- > > Key: ISPN-5180 > URL: https://issues.jboss.org/browse/ISPN-5180 > Project: Infinispan > Issue Type: Bug > Components: Remote Protocols > Affects Versions: 7.0.3.Final, 7.1.0.CR2 > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Priority: Critical > Labels: compatibility > Fix For: 7.1.0.Final > > > When compatibility is enabled, storing a java serialized object with REST, and then retrieving it with Hot Rod results in byte[] being returned instead of the deserilialized object: > {code}java.lang.AssertionError: > Expected :org.infinispan.it.compatibility.EmbeddedRestHotRodTest$Person@22cd6f > Actual :[B@2ff9eb2a > at org.testng.AssertJUnit.fail(AssertJUnit.java:59) > at org.testng.AssertJUnit.failNotEquals(AssertJUnit.java:364) > at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:80) > at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:88) > at org.infinispan.it.compatibility.EmbeddedRestHotRodTest.testCustomObjectRestPutHotRodEmbeddedGet(EmbeddedRestHotRodTest.java:217) > {code} > This is because when the entry is retrieved by Hot Rod and it's going to marshall it for sending it back to the client, it should check if the entry is already a byte[], in which case it should not touch it. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5246) Re-enable the queue for the JGroups internal thread pool in the default configuration

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-5246?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-5246: ----------------------------------------------- Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1196145|https://bugzilla.redhat.com/show_bug.cgi?id=1196145] from NEW to ASSIGNED > Re-enable the queue for the JGroups internal thread pool in the default configuration > ------------------------------------------------------------------------------------- > > Key: ISPN-5246 > URL: https://issues.jboss.org/browse/ISPN-5246 > Project: Infinispan > Issue Type: Task > Components: Configuration > Affects Versions: 7.2.0.Alpha1 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Critical > Fix For: 7.2.0.Final > > > Need to change {{default-jgroups-udp/tcp.xml}} for embedded and {{jgroups-defaults.xml}} for server. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5246) Re-enable the queue for the JGroups internal thread pool in the default configuration

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-5246?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-5246: ------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/3269 > Re-enable the queue for the JGroups internal thread pool in the default configuration > ------------------------------------------------------------------------------------- > > Key: ISPN-5246 > URL: https://issues.jboss.org/browse/ISPN-5246 > Project: Infinispan > Issue Type: Task > Components: Configuration > Affects Versions: 7.2.0.Alpha1 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Critical > Fix For: 7.2.0.Final > > > Need to change {{default-jgroups-udp/tcp.xml}} for embedded and {{jgroups-defaults.xml}} for server. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5221) Java Hotrod client, nearcache broken after a org.infinispan.client.hotrod.exceptions.TransportException:: java.net.SocketTimeoutException

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-5221?page=com.atlassian.jira.plugin.... ] Galder Zamarreño commented on ISPN-5221: ---------------------------------------- Yes, apart from the server side logs, the client configuration might be important here. In particular, the options passed in to the RemoteCacheManager in construction. Also, if you happen to have the GC logs from the server, that'd be great to see what kind of pauses does the server suffer. Finally, I think we can still improve the code in the event listener to better handle `java.net.SocketTimeoutException` instances when trying to read an event. At the moment, it seems like that after such exception the event listener thread stops its work. I think we can do better than that. However, I'd still would like to see the logs, GC logs (if available) and client configuration to see if there's something else. > Java Hotrod client, nearcache broken after a org.infinispan.client.hotrod.exceptions.TransportException:: java.net.SocketTimeoutException > ----------------------------------------------------------------------------------------------------------------------------------------- > > Key: ISPN-5221 > URL: https://issues.jboss.org/browse/ISPN-5221 > Project: Infinispan > Issue Type: Bug > Affects Versions: 7.1.0.Final > Environment: Infinispan 7.1.0Final > Reporter: Enrico Olivelli > Assignee: Galder Zamarreño > Fix For: 7.2.0.Final > > > Using the LAZY nearcache (new in 7.1.0Final) when a java.net.SocketTimeoutException occurs against one of the given HotRod server the RemoteCache becames not usable any more > This happens very frequently in our DEV environment, but I cannot reproduce it inside a test case > This is the stacktrace > {code} > 15/02/13 14:51:39 ERROR event.ClientListenerNotifier: ISPN004043: Unrecoverable error reading event from server xxx.xxx.xxx/10.168.10.117:11222, exiting event reader thread > org.infinispan.client.hotrod.exceptions.TransportException:: java.net.SocketTimeoutException > at org.infinispan.client.hotrod.impl.transport.tcp.TcpTransport.readByte(TcpTransport.java:184) > at org.infinispan.client.hotrod.impl.protocol.Codec20.readMagic(Codec20.java:282) > at org.infinispan.client.hotrod.impl.protocol.Codec20.readEvent(Codec20.java:126) > at org.infinispan.client.hotrod.event.ClientListenerNotifier$EventDispatcher.run(ClientListenerNotifier.java:236) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > Caused by: java.net.SocketTimeoutException > at sun.nio.ch.SocketAdaptor$SocketInputStream.read(SocketAdaptor.java:211) > at sun.nio.ch.ChannelInputStream.read(ChannelInputStream.java:103) > at java.io.BufferedInputStream.fill(BufferedInputStream.java:246) > at java.io.BufferedInputStream.read(BufferedInputStream.java:265) > at org.infinispan.client.hotrod.impl.transport.tcp.TcpTransport.readByte(TcpTransport.java:179) > ... 8 more > {code} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4810) Local Transactional Cache loses data when eviction is enabled and there are multiple readers and one writer

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4810?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4810: ----------------------------------------------- Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1196258|https://bugzilla.redhat.com/show_bug.cgi?id=1196258] from NEW to ASSIGNED > Local Transactional Cache loses data when eviction is enabled and there are multiple readers and one writer > ----------------------------------------------------------------------------------------------------------- > > Key: ISPN-4810 > URL: https://issues.jboss.org/browse/ISPN-4810 > Project: Infinispan > Issue Type: Bug > Affects Versions: 6.0.2.Final > Environment: Windows 7 x64 (NTFS) > Oracle JDK1.7.0_40 > Apache Maven 3.0.5 > Reporter: Horia Chiorean > Assignee: William Burns > Labels: modeshape > Attachments: ispn_concurrent.zip > > > Using Infinispan 6.0.2 and a local, transactional cache backed by a <singleFile> store, with eviction enabled and a small {{max-entries}} setting, we have the following scenario: > * the main thread (i.e. the "writer") starts a transaction, adds a batch of strings into the cache and also appends the same strings into a List cache entry and then commits the transaction > * after the above has finished (i.e. after tx.commit) it fires a number of reader threads where each reader thread > ** checks that the string entries were added into the cache and > ** checks that the entries were correctly appended to the List entry > * the above steps are repeated a number of times > On any given run, based on timing, we're seeing that at some point (after some time) some of the reader threads will not see the latest version of the List entry (i.e. will not see the latest elements that were added into the list) but rather an old, stale List (sort of a "lost update" scenario). > If we either: > * disable eviction or > * set the {{max-entries}} to a large enough value (which I suspect has the same effect - not evicting anything) the problem doesn't show up. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4810) Local Transactional Cache loses data when eviction is enabled and there are multiple readers and one writer

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4810?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated ISPN-4810: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1196258 > Local Transactional Cache loses data when eviction is enabled and there are multiple readers and one writer > ----------------------------------------------------------------------------------------------------------- > > Key: ISPN-4810 > URL: https://issues.jboss.org/browse/ISPN-4810 > Project: Infinispan > Issue Type: Bug > Affects Versions: 6.0.2.Final > Environment: Windows 7 x64 (NTFS) > Oracle JDK1.7.0_40 > Apache Maven 3.0.5 > Reporter: Horia Chiorean > Assignee: William Burns > Labels: modeshape > Attachments: ispn_concurrent.zip > > > Using Infinispan 6.0.2 and a local, transactional cache backed by a <singleFile> store, with eviction enabled and a small {{max-entries}} setting, we have the following scenario: > * the main thread (i.e. the "writer") starts a transaction, adds a batch of strings into the cache and also appends the same strings into a List cache entry and then commits the transaction > * after the above has finished (i.e. after tx.commit) it fires a number of reader threads where each reader thread > ** checks that the string entries were added into the cache and > ** checks that the entries were correctly appended to the List entry > * the above steps are repeated a number of times > On any given run, based on timing, we're seeing that at some point (after some time) some of the reader threads will not see the latest version of the List entry (i.e. will not see the latest elements that were added into the list) but rather an old, stale List (sort of a "lost update" scenario). > If we either: > * disable eviction or > * set the {{max-entries}} to a large enough value (which I suspect has the same effect - not evicting anything) the problem doesn't show up. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5202) Remove deprecated maven.test.exec.skip, use skipTests instead

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-5202?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-5202: ----------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 7.2.0.Beta1 7.2.0.Final Resolution: Done > Remove deprecated maven.test.exec.skip, use skipTests instead > ------------------------------------------------------------- > > Key: ISPN-5202 > URL: https://issues.jboss.org/browse/ISPN-5202 > Project: Infinispan > Issue Type: Enhancement > Affects Versions: 7.1.0.Final > Reporter: Sebastian Łaskawiec > Assignee: Sebastian Łaskawiec > Priority: Optional > Fix For: 7.2.0.Beta1, 7.2.0.Final > > -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5202) Remove deprecated maven.test.exec.skip, use skipTests instead

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-5202?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-5202: ----------------------------------- Fix Version/s: (was: 7.2.0.Final) > Remove deprecated maven.test.exec.skip, use skipTests instead > ------------------------------------------------------------- > > Key: ISPN-5202 > URL: https://issues.jboss.org/browse/ISPN-5202 > Project: Infinispan > Issue Type: Enhancement > Affects Versions: 7.1.0.Final > Reporter: Sebastian Łaskawiec > Assignee: Sebastian Łaskawiec > Priority: Optional > Fix For: 7.2.0.Beta1 > > -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5174) Transaction cannot be recommitted after ownership changes

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-5174?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-5174: ----------------------------------------------- Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1185779|https://bugzilla.redhat.com/show_bug.cgi?id=1185779] from NEW to ASSIGNED > Transaction cannot be recommitted after ownership changes > --------------------------------------------------------- > > Key: ISPN-5174 > URL: https://issues.jboss.org/browse/ISPN-5174 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 7.1.0.CR2 > Reporter: Radim Vansa > Assignee: Dan Berindei > Priority: Critical > > Once transaction is completed, it cannot commit again. If it should commit more keys since it has become an owner of some new keys modified in this transaction, it just ignores the further commit. > There is a race with state transfer which can bring an old value (with StateResponseCommand sent before it is commited) but the value is not set by the ongoing transaction either. > This results with stale value stored on one node. > In my case, The problematic part is transaction <edg-perf01-62141>:15066 (consisting of 10 modifications) which got prepared and committed on edg-perf04 in topology 25. Before the originator finishes, topology changes and 04 requests ongoing transactions: > {code} > 11:06:11,369 TRACE [org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher] (transport-thread-17) Replication task sending StateRequestCommand{cache=testCache, origin=edg-perf04-35097, type=GET_TRANSACTIONS, topologyId=28, segments=[275, 1, 278, 9, 282, 286, 17, 259, 25, 267, 171, 169, 33, 306, 175, 173, 310, 172, 314, 41, 167, 165, 318, 187, 290, 49, 185, 191, 294, 189, 179, 298, 57, 177, 183, 302, 181, 343, 205, 201, 338, 203, 336, 351, 197, 349, 199, 347, 193, 345, 195, 326, 85, 87, 322, 93, 332, 95, 330, 89, 91, 103, 101, 99, 506, 97, 105, 357, 359, 353, 355, 361]} to single recipient edg-perf01-62141 with response mode GET_ALL > 11:06:11,495 DEBUG [org.infinispan.statetransfer.StateConsumerImpl] (transport-thread-17) Applying 6 transactions for cache testCache transferred from node edg-perf01-62141 > {code} > However I don't see how these are applied, since PrepareCommand is not created again - from the code I see only that backup locks are added. Not sure if the transaction is registered at all, since it was already completed on this node (but at that time it did not own key_00000000000002EB). > After originator stores the entry, it sends one more CommitCommand with topology 28: > {code} > 11:06:11,619 TRACE [org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher] (DefaultStressor-2) Replication task sending CommitCommand {gtx=GlobalTransaction:<edg-perf01-62141>:15066:local, cacheName='testCache', topologyId=28} to addresses [edg-perf03-20530, edg-perf04-35097] with response mode GET_ALL > {code} > 04 receives several CommitCommands (both from originator and forwards), but all of them are ignored as the transaction is completed. > I don't see the logs where state transfer is assembled, but it's probably before the entry is stored on originator as the state transfer contains the old entry: > {code} > 11:06:13,449 TRACE [org.infinispan.statetransfer.StateConsumerImpl] (remote-thread-91) Received chunk with keys [key_000000000000065B, key_00000000000006BE, key_FFFFFFFFFFFFE62F, key_0000000000001F42, key_000000000000027B, key_000000000000159D, key_00000000000002EB, key_00000000000002BB] for segment 343 of cache testCache from node edg-perf01-62141 > 11:06:13,454 TRACE [org.infinispan.container.DefaultDataContainer] (remote-thread-91) Store ImmortalCacheEntry{key=key_00000000000002EB, value=[2 #7: 366, 544, 576, 804, 1061, 1181, 1290, ]} in container > {code} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 10 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues February 2015