January 2014 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-2575) KeyTransformer registration is required on all nodes of the cluster, in case of custom keys

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2575?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2575: -------------------------------- Assignee: Adrian Nistor (was: Sanne Grinovero) > KeyTransformer registration is required on all nodes of the cluster, in case of custom keys > ------------------------------------------------------------------------------------------- > > Key: ISPN-2575 > URL: https://issues.jboss.org/browse/ISPN-2575 > Project: Infinispan > Issue Type: Enhancement > Components: Querying > Affects Versions: 5.2.0.Beta5 > Reporter: Anna Manukyan > Assignee: Adrian Nistor > Attachments: ClusteredCacheTest.java > > > The case is the following: > I have a clustered cache on which I want to perform a search. I'm doing the following: > I'm initializing SearchManager on node1, I'm registering a custom key transformer for my key using the created searchmanager, but then when I'm trying to put data into the cache on node1 (which is in REPL_SYNC mode with cache on node2), I'm getting the exception: > java.lang.IllegalArgumentException: Indexing only works with entries keyed on Strings, primitives and classes that have the @Transformable annotation - you passed in a class org.infinispan.query.test.CustomKey3. Alternatively, see org.infinispan.query.SearchManager#registerKeyTransformer > When I'm initializing the SearchManager using node2 cache and register the keyTransformer on it as well, then everything works perfectly, even though I am not using the second created SearchManager. > The test which reproduces the issue is attached to the jira. Please see the test case: testSearchKeyTransformer() -- 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

4 days, 7 hours

2
1
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: ------------------------------ 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

11 years, 8 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

11 years, 8 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

11 years, 8 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

11 years, 8 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

11 years, 8 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

11 years, 8 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

11 years, 8 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

11 years, 8 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

11 years, 8 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues January 2014