[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, 7 months
[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, 7 months
[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, 7 months
[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, 7 months
[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, 7 months
[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, 7 months
[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, 7 months