December 2013 - infinispan-issues

[JBoss JIRA] (ISPN-3841) L1NonTxInterceptor - Invalid format of log.tracef message

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-3841?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-3841: ------------------------------- Fix Version/s: 7.0.0.Alpha1 > L1NonTxInterceptor - Invalid format of log.tracef message > --------------------------------------------------------- > > Key: ISPN-3841 > URL: https://issues.jboss.org/browse/ISPN-3841 > Project: Infinispan > Issue Type: Bug > Affects Versions: 6.0.0.Final > Reporter: Mikolaj Gierulski > Assignee: Sanne Grinovero > Priority: Minor > Labels: 620 > Fix For: 6.0.1.Final, 7.0.0.Alpha1 > > > org.infinispan.interceptors.distribution.L1NonTxInterceptor.invalidateL1(InvocationContext, DataWriteCommand, boolean) invokes log.tracef with invalid message format - it contains '%', but should be '%s': > log.tracef("Not invalidating key '%' as local node(%s) is not owner", command.getKey(), rpcManager.getAddress()); -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3755) Add more detailed description of the filtering operators supported by the new query DSL

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-3755?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-3755: ------------------------------- Fix Version/s: 7.0.0.Alpha1 > Add more detailed description of the filtering operators supported by the new query DSL > --------------------------------------------------------------------------------------- > > Key: ISPN-3755 > URL: https://issues.jboss.org/browse/ISPN-3755 > Project: Infinispan > Issue Type: Enhancement > Components: Documentation > Affects Versions: 6.0.0.Final > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Labels: 620 > Fix For: 6.0.1.Final, 7.0.0.Alpha1 > > > The documentation exists (http://infinispan.org/docs/6.0.x/user_guide/user_guide.html#_filtering_op...), but is a bit scarce. -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3772) Reduce marshalling payload sizes

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-3772?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-3772: ------------------------------- Fix Version/s: 7.0.0.Final 7.0.0.Alpha1 > Reduce marshalling payload sizes > -------------------------------- > > Key: ISPN-3772 > URL: https://issues.jboss.org/browse/ISPN-3772 > Project: Infinispan > Issue Type: Enhancement > Components: Marshalling > Affects Versions: 6.0.0.Final > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 6.0.1.Final, 7.0.0.Final, 7.0.0.Alpha1 > > > Apply some marshalling improvements: > 1. Marshall instances of java.util.Arrays$ArrayList with ArrayListExternalizer so that it occupies less space. > 2. RegularEnumSet and JumboEnumSet should be detected and they should be written using SetExternalizer. For an enum set with a single value, this means going from writing 41 bytes to 10 bytes. > 3. Avoid sending OPERATION_X flags when compatibility mode is disabled. > 4. Current array support in JBoss Marshalling ends up writing class information even for know types. Try to figure out a way to detect the most commonly written arrays in Infinispan and find an efficient way to marshall them. -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3839) Compatibility Mode tests didn't shutdown all the cache managers

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-3839?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-3839: ------------------------------- Fix Version/s: 7.0.0.Alpha1 > Compatibility Mode tests didn't shutdown all the cache managers > --------------------------------------------------------------- > > Key: ISPN-3839 > URL: https://issues.jboss.org/browse/ISPN-3839 > Project: Infinispan > Issue Type: Bug > Components: Test Suite > Affects Versions: 6.0.0.Final > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Labels: testsuite_stability > Fix For: 6.0.1.Final, 7.0.0.Alpha1 > > > some tests are always failing with: > {noformat} > [17:20:39][org.infinispan:infinispan-compatibility-mode-it] !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > [17:20:39][org.infinispan:infinispan-compatibility-mode-it] !!!!!! (testng-CustomMemcachedHotRodTest) Exiting because CustomMemcachedHotRodTest has NOT shut down all the cache managers it has started !!!!!!! > [17:20:39][org.infinispan:infinispan-compatibility-mode-it] !!!!!! (testng-CustomMemcachedHotRodTest) See allocation stacktrace to find out where still-running cacheManager (org.infinispan.manager.DefaultCacheManager@743bce70@Address:null) was created: !!!!!!! > [17:20:39][org.infinispan:infinispan-compatibility-mode-it] !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > {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

12 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3799) Port back latest CHMv8 fixes

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-3799?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-3799: ------------------------------- Fix Version/s: 7.0.0.Alpha1 > Port back latest CHMv8 fixes > ---------------------------- > > Key: ISPN-3799 > URL: https://issues.jboss.org/browse/ISPN-3799 > Project: Infinispan > Issue Type: Task > Affects Versions: 6.0.0.Final > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 6.0.1.Final, 7.0.0.Alpha1 > > > As indicated in [mailing list thread|http://cs.oswego.edu/pipermail/concurrency-interest/2013-December/...], verify whether Infinispan's port of CHM contains that bug (try to port the test), and if the bug is present, port back latest changes that are supposed to fix it. -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3852) Add a section describing the configuration for the java hotrod client

by Mircea Markus (JIRA)

Mircea Markus created ISPN-3852: ----------------------------------- Summary: Add a section describing the configuration for the java hotrod client Key: ISPN-3852 URL: https://issues.jboss.org/browse/ISPN-3852 Project: Infinispan Issue Type: Feature Request Components: Documentation Reporter: Mircea Markus Assignee: Mircea Markus -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3048) Eviction needs to be transactional

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-3048?page=com.atlassian.jira.plugin.... ] Dan Berindei commented on ISPN-3048: ------------------------------------ [~pruivo] I'm not sure it it's still relevant, but from the bug description I understood that Paul is using manual eviction to work around data loss that used to happen with size-based eviction. > Eviction needs to be transactional > ---------------------------------- > > Key: ISPN-3048 > URL: https://issues.jboss.org/browse/ISPN-3048 > Project: Infinispan > Issue Type: Bug > Components: Eviction > Affects Versions: 5.3.0.Alpha1 > Reporter: Paul Ferraro > Assignee: Pedro Ruivo > Priority: Critical > Labels: 620 > Fix For: 6.0.1.Final > > > Currently, Infinispan eviction is non-transactional. This makes Infinispan's eviction manager virtually unusable, since non-transactional eviction can cause phantom reads and data loss because it violates the isolation of concurrent transactions. This is especially problematic when using a passivation-enabled cache store. In this case, a cache eviction/passivation can cause a concurrently executed cache retrieval to return null - even though the act of passivation does not change the data - it only changes where it is stored. > We work around this in the AS by performing eviction manually, using pessimistic locking in combination with eager lock acquisition prior to eviction. This is unfortunate, since it prevents me from leveraging Infinispan's build-in eviction strategies. -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3048) Eviction needs to be transactional

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-3048?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-3048: ------------------------------- Fix Version/s: 7.0.0.Final 7.0.0.Alpha1 > Eviction needs to be transactional > ---------------------------------- > > Key: ISPN-3048 > URL: https://issues.jboss.org/browse/ISPN-3048 > Project: Infinispan > Issue Type: Bug > Components: Eviction > Affects Versions: 5.3.0.Alpha1 > Reporter: Paul Ferraro > Assignee: Pedro Ruivo > Priority: Critical > Labels: 620 > Fix For: 6.0.1.Final, 7.0.0.Final, 7.0.0.Alpha1 > > > Currently, Infinispan eviction is non-transactional. This makes Infinispan's eviction manager virtually unusable, since non-transactional eviction can cause phantom reads and data loss because it violates the isolation of concurrent transactions. This is especially problematic when using a passivation-enabled cache store. In this case, a cache eviction/passivation can cause a concurrently executed cache retrieval to return null - even though the act of passivation does not change the data - it only changes where it is stored. > We work around this in the AS by performing eviction manually, using pessimistic locking in combination with eager lock acquisition prior to eviction. This is unfortunate, since it prevents me from leveraging Infinispan's build-in eviction strategies. -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3659) Cache stop should clear thread-local ExtendedRiverMarshaller or their instance caches

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-3659?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-3659: ------------------------------- Fix Version/s: 7.0.0.Final 7.0.0.Alpha1 > Cache stop should clear thread-local ExtendedRiverMarshaller or their instance caches > ------------------------------------------------------------------------------------- > > Key: ISPN-3659 > URL: https://issues.jboss.org/browse/ISPN-3659 > Project: Infinispan > Issue Type: Bug > Components: Marshalling > Affects Versions: 5.3.0.Final, 6.0.0.CR1 > Reporter: Dan Berindei > Assignee: Pedro Ruivo > Priority: Critical > Labels: 620 > Fix For: 6.0.1.Final, 7.0.0.Final, 7.0.0.Alpha1 > > > The fix for ISPN-2372 was incomplete. We now clear the references from the thread-local marshallers to the cache itself, so it can be garbage-collected, but we don't clear the marshallers or their instance caches. If the cache values' object graph is very large, the cached marshallers will use up a lot of memory that could be garbage-collected (assuming the cache was indeed restarted and only one cache instance is running now). -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3608) HotRod client cannot be configured to connect to servers running on IPv6 through hotrod-client.properties

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-3608?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-3608: ------------------------------- Fix Version/s: 7.0.0.Final 7.0.0.Alpha1 > HotRod client cannot be configured to connect to servers running on IPv6 through hotrod-client.properties > --------------------------------------------------------------------------------------------------------- > > Key: ISPN-3608 > URL: https://issues.jboss.org/browse/ISPN-3608 > Project: Infinispan > Issue Type: Bug > Affects Versions: 6.0.0.CR1 > Reporter: Martin Gencur > Assignee: Galder Zamarreño > Priority: Critical > Labels: 620 > Fix For: 6.0.1.Final, 7.0.0.Final, 7.0.0.Alpha1 > > > HotRod client's RemoteCacheManager still has a constructor that internally reads hotrod-client.properties (public RemoteCacheManager(boolean start)) and this constructor is not deprecated. > This call leads to parsing "server_list" property by ConfigurationBuilder.addServers(String servers)). > However, IPv6 addresses usually contain colons and so this parsing fails (enable to differentiate the host and port as these are separated by colon too) -- 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, 3 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 December 2013