January 2014 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-3960) Eviction notification from entry expired in cache store

by Radim Vansa (JIRA)

Radim Vansa created ISPN-3960: --------------------------------- Summary: Eviction notification from entry expired in cache store Key: ISPN-3960 URL: https://issues.jboss.org/browse/ISPN-3960 Project: Infinispan Issue Type: Bug Components: Loaders and Stores Affects Versions: 6.0.1.Final Reporter: Radim Vansa Assignee: Dan Berindei Looking on PersistenceManagerImpl, it seems to me that if cache store expires an entry, CacheEntryEvicted event is fired. There is no expiration event currently, but that's no excuse for firing the wrong event. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3942) HotRod client keep trying recover a connection to a cluster member after shutdown

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-3942?page=com.atlassian.jira.plugin.... ] Work on ISPN-3942 started by Pedro Ruivo. > HotRod client keep trying recover a connection to a cluster member after shutdown > --------------------------------------------------------------------------------- > > Key: ISPN-3942 > URL: https://issues.jboss.org/browse/ISPN-3942 > Project: Infinispan > Issue Type: Bug > Components: Remote Protocols > Affects Versions: 6.0.1.Final, 7.0.0.Alpha1 > Environment: Infinispan server with HotRod client in server-client mode and replicated caches. > Reporter: Wolf-Dieter Fink > Assignee: Pedro Ruivo > Priority: Critical > Labels: clustered, hotrod, hotrod-java-client > Attachments: hotrod-client.log > > > If a HotRod client is connected to a server cluster and one of the servers do a correct shutdown, the client keep try to reconnect the server after the cluster view has changed. > There is only a replicated cache configured. > From the server-logfile the new cluster view is established > 16:00:22,290 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-3,shared=udp) ISPN000094: Received new cluster view: [node1/clustered|2] (1) [node1/clustered] > There is no failure from the application perspective, but there there is always a retry if the RoundRobin return the unavailable server. > This might end in a performance or failure issue if there is a larger cluster and a part going out of work for some reason. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3957) Preload with async cache store is not efficient

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3957?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated ISPN-3957: ------------------------------------------ Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1059489, https://bugzilla.redhat.com/show_bug.cgi?id=1060199 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1059489) > Preload with async cache store is not efficient > ----------------------------------------------- > > Key: ISPN-3957 > URL: https://issues.jboss.org/browse/ISPN-3957 > Project: Infinispan > Issue Type: Enhancement > Components: Loaders and Stores > Affects Versions: 5.2.7.Final > Reporter: Mircea Markus > Assignee: Dan Berindei > Fix For: 5.2.8.Final, 7.0.0.Alpha1, 7.0.0.Final > > > Configuring on a AdvancedCacheLoader preload=true and asyn=true cause it to load each entry in the store in a loop, each entry being loaded through an store read. > This is caused by the way loadAll is implemented in the AsynLoader: in order to enforce consistency with whatever is in memory it does some special handling. The thing is, though, that we don't need this advanced async loader logic during the initial preload, as the async cache loader is empty. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3942) HotRod client keep trying recover a connection to a cluster member after shutdown

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-3942?page=com.atlassian.jira.plugin.... ] Dan Berindei reassigned ISPN-3942: ---------------------------------- Assignee: Pedro Ruivo (was: Galder Zamarreño) It's tricky to get logs from the server when running the whole test suite, because the worker thread names don't include the test name. > HotRod client keep trying recover a connection to a cluster member after shutdown > --------------------------------------------------------------------------------- > > Key: ISPN-3942 > URL: https://issues.jboss.org/browse/ISPN-3942 > Project: Infinispan > Issue Type: Bug > Components: Remote Protocols > Affects Versions: 6.0.1.Final, 7.0.0.Alpha1 > Environment: Infinispan server with HotRod client in server-client mode and replicated caches. > Reporter: Wolf-Dieter Fink > Assignee: Pedro Ruivo > Priority: Critical > Labels: clustered, hotrod, hotrod-java-client > Attachments: hotrod-client.log > > > If a HotRod client is connected to a server cluster and one of the servers do a correct shutdown, the client keep try to reconnect the server after the cluster view has changed. > There is only a replicated cache configured. > From the server-logfile the new cluster view is established > 16:00:22,290 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-3,shared=udp) ISPN000094: Received new cluster view: [node1/clustered|2] (1) [node1/clustered] > There is no failure from the application perspective, but there there is always a retry if the RoundRobin return the unavailable server. > This might end in a performance or failure issue if there is a larger cluster and a part going out of work for some reason. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3942) HotRod client keep trying recover a connection to a cluster member after shutdown

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3942?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3942: -------------------------------- Priority: Critical (was: Major) > HotRod client keep trying recover a connection to a cluster member after shutdown > --------------------------------------------------------------------------------- > > Key: ISPN-3942 > URL: https://issues.jboss.org/browse/ISPN-3942 > Project: Infinispan > Issue Type: Bug > Components: Remote Protocols > Affects Versions: 6.0.1.Final, 7.0.0.Alpha1 > Environment: Infinispan server with HotRod client in server-client mode and replicated caches. > Reporter: Wolf-Dieter Fink > Assignee: Galder Zamarreño > Priority: Critical > Labels: clustered, hotrod, hotrod-java-client > Attachments: hotrod-client.log > > > If a HotRod client is connected to a server cluster and one of the servers do a correct shutdown, the client keep try to reconnect the server after the cluster view has changed. > There is only a replicated cache configured. > From the server-logfile the new cluster view is established > 16:00:22,290 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-3,shared=udp) ISPN000094: Received new cluster view: [node1/clustered|2] (1) [node1/clustered] > There is no failure from the application perspective, but there there is always a retry if the RoundRobin return the unavailable server. > This might end in a performance or failure issue if there is a larger cluster and a part going out of work for some reason. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3492) Upgrade JPA Cache Store to 6.0 API

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/ISPN-3492?page=com.atlassian.jira.plugin.... ] Radim Vansa updated ISPN-3492: ------------------------------ Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan-cachestore-jpa/pull/3 > Upgrade JPA Cache Store to 6.0 API > ---------------------------------- > > Key: ISPN-3492 > URL: https://issues.jboss.org/browse/ISPN-3492 > Project: Infinispan > Issue Type: Enhancement > Components: Loaders and Stores > Reporter: Ray Tsang > Assignee: Radim Vansa > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3959) JdbcBinaryStore's expiration locks buckets indefinitely

by Radim Vansa (JIRA)

Radim Vansa created ISPN-3959: --------------------------------- Summary: JdbcBinaryStore's expiration locks buckets indefinitely Key: ISPN-3959 URL: https://issues.jboss.org/browse/ISPN-3959 Project: Infinispan Issue Type: Bug Reporter: Radim Vansa Assignee: Mircea Markus The buckets are locked in eviction thread (in the main purge method), while unlocked in BucketPurger.call() which is executed in persistence thread. The unlock fails and the buckets stay locked indefinitely. Another error is that the Bucket class is not serializable. This is also a bug in BaseStoreTest as this uses WithinThreadExecutor as the executor for purging while usually this is done in different thread. Moreover, as the purge method is actually not obliged to purge anything, the test does not test the purging itself, but rather a check for expired entry when it is loaded (contains operation). The purging should be enforced by purge listener (calling the purge method until all entries are purged). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3956) L1WriteSynchronizer can cause locking with concurrent gets when value is not present

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3956?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-3956: ----------------------------------------------- Dan Berindei <dberinde(a)redhat.com> changed the Status of [bug 1059814|https://bugzilla.redhat.com/show_bug.cgi?id=1059814] from POST to MODIFIED > L1WriteSynchronizer can cause locking with concurrent gets when value is not present > ------------------------------------------------------------------------------------ > > Key: ISPN-3956 > URL: https://issues.jboss.org/browse/ISPN-3956 > Project: Infinispan > Issue Type: Bug > Components: L1 > Affects Versions: 6.0.0.Final > Reporter: William Burns > Assignee: William Burns > Fix For: 7.0.0.Alpha1, 7.0.0.Final > > > This has been seen previously only on IBM JDK 6 ISPN-3889, however an end user also now can reproduce this issue https://community.jboss.org/thread/236590 > The issue is that we don't set the remote lookup value to be null when nothing is found and thus any threads that are waiting for the remote lookup were never notified of this. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3947) HotRod client keep trying recover connections to a failed cluster

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3947?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-3947: ----------------------------------------------- Dan Berindei <dberinde(a)redhat.com> changed the Status of [bug 1058887|https://bugzilla.redhat.com/show_bug.cgi?id=1058887] from POST to MODIFIED > HotRod client keep trying recover connections to a failed cluster > ----------------------------------------------------------------- > > Key: ISPN-3947 > URL: https://issues.jboss.org/browse/ISPN-3947 > Project: Infinispan > Issue Type: Feature Request > Components: Remote Protocols > Affects Versions: 6.0.1.Final, 7.0.0.Alpha1 > Reporter: Wolf-Dieter Fink > Assignee: Galder Zamarreño > Priority: Critical > Labels: hotrod, hotrod-java-client > Fix For: 7.0.0.Alpha1, 7.0.0.Final > > > If an infinispan-server cluster is not longer reachable for some reason, i.e. network disconnect, the hot-rod client try to re-establish the lost connections. > The client library will retry this by a fixed calculation based on the max numbers of connections from the pool or 10 multiplied with the number of available servers. > This can lead in a very long time until the application can continue and react as it will wait for the read- or connect-timeout for each try. > To improve this behaviour there should be a configurable limit of retries per server and/or a timeout in total. > This will give the application the chance to handle a remote-cache failure and reply to the user instead of hanging for minutes (with the default settings) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3958) ReplTopologyChangeTest.testDropServer random failures

by Dan Berindei (JIRA)

Dan Berindei created ISPN-3958: ---------------------------------- Summary: ReplTopologyChangeTest.testDropServer random failures Key: ISPN-3958 URL: https://issues.jboss.org/browse/ISPN-3958 Project: Infinispan Issue Type: Bug Components: Test Suite - Server Affects Versions: 6.0.1.Final Reporter: Dan Berindei Assignee: Mircea Markus Fix For: 7.0.0.Final {{ReplTopologyChangeTest.expectTopologyChange()}} assumes that it will take less than 10 put operations to receive an updated topology after killing a node. Some times, however, that is not enough for the server to send the new topology: {noformat} 21:30:46,438 ERROR (testng-ReplTopologyChangeTest:) [UnitTestTestNGListener] Test testDropServer(org.infinispan.client.hotrod.ReplTopologyChangeTest) failed. java.lang.AssertionError: localhost/127.0.0.1:15269 not found in [/127.0.0.1:15266, /127.0.0.1:15269, /127.0.0.1:15263] expected:<false> but was:<true> 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:185) at org.infinispan.client.hotrod.ReplTopologyChangeTest.expectTopologyChange(ReplTopologyChangeTest.java:141) at org.infinispan.client.hotrod.ReplTopologyChangeTest.testDropServer(ReplTopologyChangeTest.java:123) {noformat} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 2 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues January 2014