July 2013 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-3279) Delete ConfigurationOverrides and GlobalConfigurationOverrides in Spring module

by Navin Surtani (JIRA)

[ https://issues.jboss.org/browse/ISPN-3279?page=com.atlassian.jira.plugin.... ] Navin Surtani updated ISPN-3279: -------------------------------- Git Pull Request: https://github.com/infinispan/infinispan/pull/1978 (was: https://github.com/infinispan/infinispan/pull/1953, https://github.com/infinispan/infinispan/pull/1978) > Delete ConfigurationOverrides and GlobalConfigurationOverrides in Spring module > ------------------------------------------------------------------------------- > > Key: ISPN-3279 > URL: https://issues.jboss.org/browse/ISPN-3279 > Project: Infinispan > Issue Type: Enhancement > Components: Spring integration, Test Suite > Affects Versions: 6.0.0.Alpha1 > Reporter: Navin Surtani > Assignee: Navin Surtani > > Delete the ConfigurationOverrides and GlobalConfigurationOverrides classes. Methods that otherwise make use of this code should provide an API to take in ConfigurationBuilder or GlobalConfigurationBuilder objects. This is to make the code-base easier to maintain. -- 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

12 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3279) Delete ConfigurationOverrides and GlobalConfigurationOverrides in Spring module

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-3279?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-3279: ----------------------------------- Git Pull Request: https://github.com/infinispan/infinispan/pull/1953, https://github.com/infinispan/infinispan/pull/1978 (was: https://github.com/infinispan/infinispan/pull/1953) > Delete ConfigurationOverrides and GlobalConfigurationOverrides in Spring module > ------------------------------------------------------------------------------- > > Key: ISPN-3279 > URL: https://issues.jboss.org/browse/ISPN-3279 > Project: Infinispan > Issue Type: Enhancement > Components: Spring integration, Test Suite > Affects Versions: 6.0.0.Alpha1 > Reporter: Navin Surtani > Assignee: Navin Surtani > > Delete the ConfigurationOverrides and GlobalConfigurationOverrides classes. Methods that otherwise make use of this code should provide an API to take in ConfigurationBuilder or GlobalConfigurationBuilder objects. This is to make the code-base easier to maintain. -- 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

12 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3279) Delete ConfigurationOverrides and GlobalConfigurationOverrides in Spring module

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-3279?page=com.atlassian.jira.plugin.... ] Galder Zamarreño commented on ISPN-3279: ---------------------------------------- Having Spring redefine all configuration options just does not scale up. Whenever we change the core configuration you have to go and modify these classes which we forget and we end up lagging behind. What should be happening instead is that there should be a way to define a ConfigurationBuilder or GlobalConfigurationBuilder bean and inject that (separate jira). > Delete ConfigurationOverrides and GlobalConfigurationOverrides in Spring module > ------------------------------------------------------------------------------- > > Key: ISPN-3279 > URL: https://issues.jboss.org/browse/ISPN-3279 > Project: Infinispan > Issue Type: Enhancement > Components: Spring integration, Test Suite > Affects Versions: 6.0.0.Alpha1 > Reporter: Navin Surtani > Assignee: Navin Surtani > > Delete the ConfigurationOverrides and GlobalConfigurationOverrides classes. Methods that otherwise make use of this code should provide an API to take in ConfigurationBuilder or GlobalConfigurationBuilder objects. This is to make the code-base easier to maintain. -- 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

12 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3328) Provide cache view history

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3328?page=com.atlassian.jira.plugin.... ] Mircea Markus commented on ISPN-3328: ------------------------------------- [~rachmato] thanks Rich, I think it is indeed a useful feature. > Provide cache view history > -------------------------- > > Key: ISPN-3328 > URL: https://issues.jboss.org/browse/ISPN-3328 > Project: Infinispan > Issue Type: Feature Request > Components: Core API > Affects Versions: 5.3.0.Final > Reporter: Richard Achmatowicz > Assignee: Mircea Markus > Priority: Minor > > In a clustered context, having information on the sequence of views which an application participated in and the membership of those views can be useful for post-mortem debugging as well as monitoring. > At present, JGroups provides such information (e.g. see GMS.printPreviousViews) for group membership at the channel level in the form of a bounded sequence of previous views, as well as a bounded sequence of previous members. This makes it easy to confirm that expected sequences of membership changes have actually occurred. > Having a similar history for Infinispan caches would provide the same benefit at the cache level. > Motivation: I would like to expose such information as part of the cluster subsystem if possible (see WFLY-1430). -- 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

12 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3334) Default jgroups-tcp.xml configuration could result in JGroups lock

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3334?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3334: -------------------------------- Fix Version/s: 6.0.0.Final > Default jgroups-tcp.xml configuration could result in JGroups lock > ------------------------------------------------------------------ > > Key: ISPN-3334 > URL: https://issues.jboss.org/browse/ISPN-3334 > Project: Infinispan > Issue Type: Bug > Affects Versions: 5.3.0.Final > Reporter: Ray Tsang > Assignee: Mircea Markus > Fix For: 6.0.0.Alpha2, 6.0.0.Final > > > In default jgroups-tcp.xml [1]: > <MFC max_credits="200k" min_threshold="0.20"/> > <FRAG2 frag_size="60000"/> > According to JGRP-1659 [2]: > * Either set FRAG2.frag_size to be less than MFC.min_threshold * MFC.max_credits (=40k), e.g. to 20k, or > * Increase max_credits or min_threshold, such that their product is greater than FRAG2.frag_size > Recommend updating default jgroups-tcp.xml accordingly. > [1] https://github.com/infinispan/infinispan/blob/master/core/src/main/resour... > [2] https://issues.jboss.org/browse/JGRP-1659 -- 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

12 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3330) Hotrod clients getWithMetadata doesn't work with dist/repl cache

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3330?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3330: -------------------------------- Assignee: Galder Zamarreño (was: Mircea Markus) > Hotrod clients getWithMetadata doesn't work with dist/repl cache > ---------------------------------------------------------------- > > Key: ISPN-3330 > URL: https://issues.jboss.org/browse/ISPN-3330 > Project: Infinispan > Issue Type: Bug > Reporter: Jakub Markos > Assignee: Galder Zamarreño > > I have a cluster of 2 infinispan servers with this configuration: > {code:xml}<subsystem xmlns="urn:infinispan:server:core:5.3"> > <cache-container name="default" default-cache="default" listener-executor="infinispan-listener"> > <transport stack="udp" executor="infinispan-transport" lock-timeout="240000"/> > <distributed-cache name="default" start="EAGER" mode="SYNC" segments="1" owners="2" batching="false" l1-lifespan="0" remote-timeout="60000"> > <locking isolation="REPEATABLE_READ"/> > </distributed-cache> > </cache-container> > </subsystem>{code} > Running this code: > {code}remoteCache.put("k1", "v1", 10000000, TimeUnit.MICROSECONDS); // setting only lifespan > MetadataValue<String> k1 = remoteCache.getWithMetadata("k1"); > assertTrue(k1.getValue().equals("v1")); > // microseconds converted to seconds > assertTrue(k1.getLifespan() == 10); > assertTrue(k1.getMaxIdle() == -1);{code} > fails with: > {code}org.infinispan.client.hotrod.exceptions.HotRodClientException:Request for message id[5] returned server error (status=0x85): java.lang.ClassCastException: org.infinispan.container.entries.RepeatableReadEntry can > not be cast to org.infinispan.container.entries.InternalCacheEntry > at org.infinispan.client.hotrod.impl.protocol.Codec10.checkForErrorsInResponseStatus(Codec10.java:143) > at org.infinispan.client.hotrod.impl.protocol.Codec10.readHeader(Codec10.java:99) > at org.infinispan.client.hotrod.impl.operations.HotRodOperation.readHeaderAndValidate(HotRodOperation.java:56) > at org.infinispan.client.hotrod.impl.operations.AbstractKeyOperation.sendKeyOperation(AbstractKeyOperation.java:52) > at org.infinispan.client.hotrod.impl.operations.GetWithMetadataOperation.executeOperation(GetWithMetadataOperation.java:35) > at org.infinispan.client.hotrod.impl.operations.GetWithMetadataOperation.executeOperation(GetWithMetadataOperation.java:23) > at org.infinispan.client.hotrod.impl.operations.RetryOnFailureOperation.execute(RetryOnFailureOperation.java:46) > at org.infinispan.client.hotrod.impl.RemoteCacheImpl.getWithMetadata(RemoteCacheImpl.java:145){code} > Works with isolation="READ_COMMITED"/"NONE" or with no <locking> at all. -- 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

12 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3330) Hotrod clients getWithMetadata doesn't work with dist/repl cache

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3330?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3330: -------------------------------- Affects Version/s: 5.3.0.Final > Hotrod clients getWithMetadata doesn't work with dist/repl cache > ---------------------------------------------------------------- > > Key: ISPN-3330 > URL: https://issues.jboss.org/browse/ISPN-3330 > Project: Infinispan > Issue Type: Bug > Affects Versions: 5.3.0.Final > Reporter: Jakub Markos > Assignee: Galder Zamarreño > > I have a cluster of 2 infinispan servers with this configuration: > {code:xml}<subsystem xmlns="urn:infinispan:server:core:5.3"> > <cache-container name="default" default-cache="default" listener-executor="infinispan-listener"> > <transport stack="udp" executor="infinispan-transport" lock-timeout="240000"/> > <distributed-cache name="default" start="EAGER" mode="SYNC" segments="1" owners="2" batching="false" l1-lifespan="0" remote-timeout="60000"> > <locking isolation="REPEATABLE_READ"/> > </distributed-cache> > </cache-container> > </subsystem>{code} > Running this code: > {code}remoteCache.put("k1", "v1", 10000000, TimeUnit.MICROSECONDS); // setting only lifespan > MetadataValue<String> k1 = remoteCache.getWithMetadata("k1"); > assertTrue(k1.getValue().equals("v1")); > // microseconds converted to seconds > assertTrue(k1.getLifespan() == 10); > assertTrue(k1.getMaxIdle() == -1);{code} > fails with: > {code}org.infinispan.client.hotrod.exceptions.HotRodClientException:Request for message id[5] returned server error (status=0x85): java.lang.ClassCastException: org.infinispan.container.entries.RepeatableReadEntry can > not be cast to org.infinispan.container.entries.InternalCacheEntry > at org.infinispan.client.hotrod.impl.protocol.Codec10.checkForErrorsInResponseStatus(Codec10.java:143) > at org.infinispan.client.hotrod.impl.protocol.Codec10.readHeader(Codec10.java:99) > at org.infinispan.client.hotrod.impl.operations.HotRodOperation.readHeaderAndValidate(HotRodOperation.java:56) > at org.infinispan.client.hotrod.impl.operations.AbstractKeyOperation.sendKeyOperation(AbstractKeyOperation.java:52) > at org.infinispan.client.hotrod.impl.operations.GetWithMetadataOperation.executeOperation(GetWithMetadataOperation.java:35) > at org.infinispan.client.hotrod.impl.operations.GetWithMetadataOperation.executeOperation(GetWithMetadataOperation.java:23) > at org.infinispan.client.hotrod.impl.operations.RetryOnFailureOperation.execute(RetryOnFailureOperation.java:46) > at org.infinispan.client.hotrod.impl.RemoteCacheImpl.getWithMetadata(RemoteCacheImpl.java:145){code} > Works with isolation="READ_COMMITED"/"NONE" or with no <locking> at all. -- 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

12 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3330) Hotrod clients getWithMetadata doesn't work with dist/repl cache

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3330?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3330: -------------------------------- Fix Version/s: 6.0.0.Alpha2 6.0.0.Final > Hotrod clients getWithMetadata doesn't work with dist/repl cache > ---------------------------------------------------------------- > > Key: ISPN-3330 > URL: https://issues.jboss.org/browse/ISPN-3330 > Project: Infinispan > Issue Type: Bug > Affects Versions: 5.3.0.Final > Reporter: Jakub Markos > Assignee: Galder Zamarreño > Fix For: 6.0.0.Alpha2, 6.0.0.Final > > > I have a cluster of 2 infinispan servers with this configuration: > {code:xml}<subsystem xmlns="urn:infinispan:server:core:5.3"> > <cache-container name="default" default-cache="default" listener-executor="infinispan-listener"> > <transport stack="udp" executor="infinispan-transport" lock-timeout="240000"/> > <distributed-cache name="default" start="EAGER" mode="SYNC" segments="1" owners="2" batching="false" l1-lifespan="0" remote-timeout="60000"> > <locking isolation="REPEATABLE_READ"/> > </distributed-cache> > </cache-container> > </subsystem>{code} > Running this code: > {code}remoteCache.put("k1", "v1", 10000000, TimeUnit.MICROSECONDS); // setting only lifespan > MetadataValue<String> k1 = remoteCache.getWithMetadata("k1"); > assertTrue(k1.getValue().equals("v1")); > // microseconds converted to seconds > assertTrue(k1.getLifespan() == 10); > assertTrue(k1.getMaxIdle() == -1);{code} > fails with: > {code}org.infinispan.client.hotrod.exceptions.HotRodClientException:Request for message id[5] returned server error (status=0x85): java.lang.ClassCastException: org.infinispan.container.entries.RepeatableReadEntry can > not be cast to org.infinispan.container.entries.InternalCacheEntry > at org.infinispan.client.hotrod.impl.protocol.Codec10.checkForErrorsInResponseStatus(Codec10.java:143) > at org.infinispan.client.hotrod.impl.protocol.Codec10.readHeader(Codec10.java:99) > at org.infinispan.client.hotrod.impl.operations.HotRodOperation.readHeaderAndValidate(HotRodOperation.java:56) > at org.infinispan.client.hotrod.impl.operations.AbstractKeyOperation.sendKeyOperation(AbstractKeyOperation.java:52) > at org.infinispan.client.hotrod.impl.operations.GetWithMetadataOperation.executeOperation(GetWithMetadataOperation.java:35) > at org.infinispan.client.hotrod.impl.operations.GetWithMetadataOperation.executeOperation(GetWithMetadataOperation.java:23) > at org.infinispan.client.hotrod.impl.operations.RetryOnFailureOperation.execute(RetryOnFailureOperation.java:46) > at org.infinispan.client.hotrod.impl.RemoteCacheImpl.getWithMetadata(RemoteCacheImpl.java:145){code} > Works with isolation="READ_COMMITED"/"NONE" or with no <locking> at all. -- 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

12 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3334) Default jgroups-tcp.xml configuration could result in JGroups lock

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3334?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3334: -------------------------------- Fix Version/s: 6.0.0.Alpha2 > Default jgroups-tcp.xml configuration could result in JGroups lock > ------------------------------------------------------------------ > > Key: ISPN-3334 > URL: https://issues.jboss.org/browse/ISPN-3334 > Project: Infinispan > Issue Type: Bug > Affects Versions: 5.3.0.Final > Reporter: Ray Tsang > Assignee: Mircea Markus > Fix For: 6.0.0.Alpha2 > > > In default jgroups-tcp.xml [1]: > <MFC max_credits="200k" min_threshold="0.20"/> > <FRAG2 frag_size="60000"/> > According to JGRP-1659 [2]: > * Either set FRAG2.frag_size to be less than MFC.min_threshold * MFC.max_credits (=40k), e.g. to 20k, or > * Increase max_credits or min_threshold, such that their product is greater than FRAG2.frag_size > Recommend updating default jgroups-tcp.xml accordingly. > [1] https://github.com/infinispan/infinispan/blob/master/core/src/main/resour... > [2] https://issues.jboss.org/browse/JGRP-1659 -- 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

12 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3296) Total Order check list

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-3296?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-3296: ------------------------------ Fix Version/s: 6.0.0.Alpha3 > Total Order check list > ---------------------- > > Key: ISPN-3296 > URL: https://issues.jboss.org/browse/ISPN-3296 > Project: Infinispan > Issue Type: Task > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Priority: Critical > Fix For: 6.0.0.Alpha3 > > > Issues found in Cloud-TM. Check if they happen here and create a JIRA for each of them > * IgnoreExtraResponseFilter is not needed anymore. > * missing argument log message > * TimeoutException, when happens, it is ignored and the transaction is processed normally > * TimeoutException can block the total order chain (all system is blocked!) > * port the testTimeoutCleanup from cloudtm to master -- 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

12 years, 8 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues July 2013