[JBoss JIRA] (ISPN-5601) Merge ExtendedModuleCommandFactory into ModuleCommandFactory
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-5601?page=com.atlassian.jira.plugin.... ]
William Burns reopened ISPN-5601:
---------------------------------
Have to revert part of this to keep binary backwards compatibility with ISPN 7.
> Merge ExtendedModuleCommandFactory into ModuleCommandFactory
> ------------------------------------------------------------
>
> Key: ISPN-5601
> URL: https://issues.jboss.org/browse/ISPN-5601
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 8.0.0.Alpha2
> Reporter: Radim Vansa
> Assignee: Ryan Emerson
> Fix For: 8.0.0.Beta3
>
>
> These are the docs for ExtendedModuleCommandFactory:
> {quote}
> Temporary workaround to avoid modifying ModuleCommandFactory interface. This interface should be merged with ModuleCommandFactory in 6.0.
> {quote}
> Seems that was forgotten in 6.0, 8.0 can fix that.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 2 months
[JBoss JIRA] (ISPN-5605) Implement getAffectedKeys() in InvalidateCommand
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-5605?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-5605:
------------------------------
Status: Resolved (was: Pull Request Sent)
Assignee: Radim Vansa
Fix Version/s: 8.0.0.Beta3
8.0.0.Final
Resolution: Done
> Implement getAffectedKeys() in InvalidateCommand
> ------------------------------------------------
>
> Key: ISPN-5605
> URL: https://issues.jboss.org/browse/ISPN-5605
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 8.0.0.Alpha2
> Reporter: Radim Vansa
> Assignee: Radim Vansa
> Priority: Minor
> Fix For: 8.0.0.Beta3, 8.0.0.Final
>
>
> InvalidateCommand overloads {{getKey()}} throwing {{UnsupportedOperationException}}, but {{getAffectedKeys()}} returns collection with {{null}} or one of the invalidated keys.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 2 months
[JBoss JIRA] (ISPN-5379) Persistence with stringKeyedJdbcStore throwing ConcurrentModificationException while adding data to cache
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-5379?page=com.atlassian.jira.plugin.... ]
William Burns commented on ISPN-5379:
-------------------------------------
[~dan.berindei] posted https://github.com/infinispan/infinispan/pull/3625#issuecomment-128294561 In that case we might as well just close this and wait for another bug report :)
> Persistence with stringKeyedJdbcStore throwing ConcurrentModificationException while adding data to cache
> ----------------------------------------------------------------------------------------------------------
>
> Key: ISPN-5379
> URL: https://issues.jboss.org/browse/ISPN-5379
> Project: Infinispan
> Issue Type: Bug
> Components: Core, Loaders and Stores
> Affects Versions: 6.0.2.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Fix For: 8.0.0.Beta3
>
>
> From Dennis Reed:
> A ConcurrentModificationException in the CacheWriter interceptor during a commit.
> java.util.ConcurrentModificationException
> at java.util.LinkedList$ListItr.checkForComodification(LinkedList.java:953)
> at java.util.LinkedList$ListItr.next(LinkedList.java:886)
> at org.infinispan.interceptors.CacheWriterInterceptor.store(CacheWriterInterceptor.java:210)
> at org.infinispan.interceptors.CacheWriterInterceptor.commitCommand(CacheWriterInterceptor.java:115)
> The code is looping through the modifications associated with the transaction:
> List<WriteCommand> modifications = ctx.getCacheTransaction().getAllModifications();
> ...
> 210: for (WriteCommand cacheCommand : modifications) {
> The transaction's modification list is stored as a synchronized list with a comment "we need to synchronize this collection to be able to get a valid snapshot from another thread during state transfer".
> But this thread is not doing state transfer, and I'd assume "get a valid snapshot" wouldn't include modification?
> Is it valid for this list to be modified from another thread (in which case all iterations should be synchronized), or is something modifying it incorrectly?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 2 months
[JBoss JIRA] (ISPN-5379) Persistence with stringKeyedJdbcStore throwing ConcurrentModificationException while adding data to cache
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-5379?page=com.atlassian.jira.plugin.... ]
William Burns resolved ISPN-5379.
---------------------------------
Fix Version/s: 8.0.0.Beta3
(was: 8.0.0.Final)
Resolution: Done
> Persistence with stringKeyedJdbcStore throwing ConcurrentModificationException while adding data to cache
> ----------------------------------------------------------------------------------------------------------
>
> Key: ISPN-5379
> URL: https://issues.jboss.org/browse/ISPN-5379
> Project: Infinispan
> Issue Type: Bug
> Components: Core, Loaders and Stores
> Affects Versions: 6.0.2.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Fix For: 8.0.0.Beta3
>
>
> From Dennis Reed:
> A ConcurrentModificationException in the CacheWriter interceptor during a commit.
> java.util.ConcurrentModificationException
> at java.util.LinkedList$ListItr.checkForComodification(LinkedList.java:953)
> at java.util.LinkedList$ListItr.next(LinkedList.java:886)
> at org.infinispan.interceptors.CacheWriterInterceptor.store(CacheWriterInterceptor.java:210)
> at org.infinispan.interceptors.CacheWriterInterceptor.commitCommand(CacheWriterInterceptor.java:115)
> The code is looping through the modifications associated with the transaction:
> List<WriteCommand> modifications = ctx.getCacheTransaction().getAllModifications();
> ...
> 210: for (WriteCommand cacheCommand : modifications) {
> The transaction's modification list is stored as a synchronized list with a comment "we need to synchronize this collection to be able to get a valid snapshot from another thread during state transfer".
> But this thread is not doing state transfer, and I'd assume "get a valid snapshot" wouldn't include modification?
> Is it valid for this list to be modified from another thread (in which case all iterations should be synchronized), or is something modifying it incorrectly?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 2 months