January 2014 - infinispan-issues - Jboss List Archives

[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.... ] Pedro Ruivo updated ISPN-3942: ------------------------------ Fix Version/s: 7.0.0.Alpha1 7.0.0.Final > 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 > Fix For: 7.0.0.Alpha1, 7.0.0.Final > > 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, 11 months

1
0
0 / 0

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

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3942?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-3942: ----------------------------------------------- Pedro Ruivo <pruivo(a)redhat.com> changed the Status of [bug 1059277|https://bugzilla.redhat.com/show_bug.cgi?id=1059277] from NEW to POST > 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, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3762) Test org.infinispan.client.hotrod.ClientSocketReadTimeoutTest.testPutTimeout fail on all environments

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3762?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-3762: ----------------------------------------------- Pedro Ruivo <pruivo(a)redhat.com> changed the Status of [bug 1034719|https://bugzilla.redhat.com/show_bug.cgi?id=1034719] from NEW to POST > Test org.infinispan.client.hotrod.ClientSocketReadTimeoutTest.testPutTimeout fail on all environments > ----------------------------------------------------------------------------------------------------- > > Key: ISPN-3762 > URL: https://issues.jboss.org/browse/ISPN-3762 > Project: Infinispan > Issue Type: Bug > Components: Remote Protocols > Affects Versions: 6.0.0.Final > Reporter: Jiří Holuša > Assignee: Galder Zamarreño > Attachments: log.txt > > > The test org.infinispan.client.hotrod.ClientSocketReadTimeoutTest.testPutTimeout fails every time on all environments. -- 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, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3845) CACHE_MODE_LOCAL flag only works in primary owner for non-tx caches

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3845?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-3845: ----------------------------------------------- Pedro Ruivo <pruivo(a)redhat.com> changed the Status of [bug 1060311|https://bugzilla.redhat.com/show_bug.cgi?id=1060311] from NEW to POST > CACHE_MODE_LOCAL flag only works in primary owner for non-tx caches > ------------------------------------------------------------------- > > Key: ISPN-3845 > URL: https://issues.jboss.org/browse/ISPN-3845 > Project: Infinispan > Issue Type: Bug > Affects Versions: 6.0.0.Final > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Labels: testsuite_stability > Fix For: 7.0.0.Alpha1 > > > the flag is not forcing the EntryWrappingInterceptor to wrap the entry. the result is the entry will not be stored in the cache. > It's causing the random failures in: > {noformat} > HotRodReplicationTest.testReplicatedPutWithTopologyChanges > HotRod11ReplicationTest.testReplicatedPutWithTopologyChanges > HotRod12ReplicationTest.testReplicatedPutWithTopologyChanges > {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, 11 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.... ] Pedro Ruivo updated ISPN-3942: ------------------------------ Git Pull Request: https://github.com/infinispan/infinispan/pull/2369, https://github.com/infinispan/infinispan/pull/2370 (was: https://github.com/infinispan/infinispan/pull/2369) > 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, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3845) CACHE_MODE_LOCAL flag only works in primary owner for non-tx caches

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-3845?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-3845: ------------------------------ Git Pull Request: https://github.com/infinispan/infinispan/pull/2299, https://github.com/infinispan/infinispan/pull/2370 (was: https://github.com/infinispan/infinispan/pull/2299) > CACHE_MODE_LOCAL flag only works in primary owner for non-tx caches > ------------------------------------------------------------------- > > Key: ISPN-3845 > URL: https://issues.jboss.org/browse/ISPN-3845 > Project: Infinispan > Issue Type: Bug > Affects Versions: 6.0.0.Final > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Labels: testsuite_stability > Fix For: 7.0.0.Alpha1 > > > the flag is not forcing the EntryWrappingInterceptor to wrap the entry. the result is the entry will not be stored in the cache. > It's causing the random failures in: > {noformat} > HotRodReplicationTest.testReplicatedPutWithTopologyChanges > HotRod11ReplicationTest.testReplicatedPutWithTopologyChanges > HotRod12ReplicationTest.testReplicatedPutWithTopologyChanges > {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, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3961) Search across multiple caches

by Adrian Nistor (JIRA)

Adrian Nistor created ISPN-3961: ----------------------------------- Summary: Search across multiple caches Key: ISPN-3961 URL: https://issues.jboss.org/browse/ISPN-3961 Project: Infinispan Issue Type: Feature Request Components: Embedded Querying, Remote Querying Reporter: Adrian Nistor Assignee: Sanne Grinovero Fix For: 7.0.0.Final This would conceptually mean moving the SearchManager from Cache scope to CacheManager scope, which would allow us to share HS search factory. Would also need to add indexing configuration at cache manager level. Having a SearchManager at cache scope would still be desired for cases where the user needs to configure particular indexing settings for certain caches. Regarding indexes, we could have one index per class or one index per class + cache name; remains to be decided. See discussion here: http://markmail.org/message/oe4jeq4k73f44rts -- 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, 11 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.... ] Pedro Ruivo updated ISPN-3942: ------------------------------ Status: Pull Request Sent (was: Coding In Progress) Git Pull Request: https://github.com/infinispan/infinispan/pull/2369 > 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, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3845) CACHE_MODE_LOCAL flag only works in primary owner for non-tx caches

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3845?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated ISPN-3845: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1060311 > CACHE_MODE_LOCAL flag only works in primary owner for non-tx caches > ------------------------------------------------------------------- > > Key: ISPN-3845 > URL: https://issues.jboss.org/browse/ISPN-3845 > Project: Infinispan > Issue Type: Bug > Affects Versions: 6.0.0.Final > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Labels: testsuite_stability > Fix For: 7.0.0.Alpha1 > > > the flag is not forcing the EntryWrappingInterceptor to wrap the entry. the result is the entry will not be stored in the cache. > It's causing the random failures in: > {noformat} > HotRodReplicationTest.testReplicatedPutWithTopologyChanges > HotRod11ReplicationTest.testReplicatedPutWithTopologyChanges > HotRod12ReplicationTest.testReplicatedPutWithTopologyChanges > {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, 11 months

1
0
0 / 0

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

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/ISPN-3959?page=com.atlassian.jira.plugin.... ] Radim Vansa updated ISPN-3959: ------------------------------ Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/2368 > 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, 11 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