[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
11 years
[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
11 years
[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
11 years
[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
11 years
[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
11 years
[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
11 years
[JBoss JIRA] (ISPN-3724) REST RollUps -- Unsupported protocol version 60 throws annoying ERROR and WARN
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-3724?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-3724:
-------------------------------
Fix Version/s: 7.0.0.Alpha1
> REST RollUps -- Unsupported protocol version 60 throws annoying ERROR and WARN
> ------------------------------------------------------------------------------
>
> Key: ISPN-3724
> URL: https://issues.jboss.org/browse/ISPN-3724
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 6.0.0.CR1
> Reporter: Tomas Sykora
> Assignee: Mircea Markus
> Labels: 620
> Fix For: 6.0.1.Final, 7.0.0.Alpha1
>
> Attachments: restRollups6dot0to6dot0tryingToGetHRkey, RestRollUpsUnsupportedProtocol60
>
>
> Trying to process REST rolling upgrades using latest infinispan server 6.0.0 snapshot as a TARGET node and the same server as a source node.
> Run Infinispan-server testsuite test for REST Rolling Upgrades.
> mvn clean verify -P suite.examples -Dtest=ExampleConfigsTest#testRestRollingUpgrades -DfailIfNoTests=false
> See new attached file with current stacktrace. REST rolling upgrades from 5.2.x to 6.0 will probably _not_ be supported.
--
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