[JBoss JIRA] (ISPN-4850) Allow for filter and conversion to be done in one step for cache listeners
by William Burns (JIRA)
William Burns created ISPN-4850:
-----------------------------------
Summary: Allow for filter and conversion to be done in one step for cache listeners
Key: ISPN-4850
URL: https://issues.jboss.org/browse/ISPN-4850
Project: Infinispan
Issue Type: Enhancement
Components: Listeners
Affects Versions: 7.0.0.CR1
Reporter: William Burns
Assignee: William Burns
Currently the cache listeners can install a CacheEventFilter and CacheEventConverter to be used. However each one requires separate invocations. It would be desireable to have this done as a single invocation akin to what we did for ISPN-4640.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 5 months
[JBoss JIRA] (ISPN-4751) Hibernate search, infinispan and Amazon S3 - IllegalArgumentException: bucketId: A96137216.bz2 (expected: integer)
by George Christman (JIRA)
[ https://issues.jboss.org/browse/ISPN-4751?page=com.atlassian.jira.plugin.... ]
George Christman commented on ISPN-4751:
----------------------------------------
I'm also in need of this repair and noticed it's still an issue in 6.0.2 as well as 7.0. Does anybody know when this might be repaired?
Also you guys pointed out that cloud cache store no longer will work with later versions of infinispan, how would I go about getting this library updated? AWS is one of the largest cloud hosting services on the planet, so I'm rather surprised to see there hasn't been much of a demand for this fix.
> Hibernate search, infinispan and Amazon S3 - IllegalArgumentException: bucketId: A96137216.bz2 (expected: integer)
> ------------------------------------------------------------------------------------------------------------------
>
> Key: ISPN-4751
> URL: https://issues.jboss.org/browse/ISPN-4751
> Project: Infinispan
> Issue Type: Bug
> Components: Loaders and Stores
> Reporter: Lance Ess
> Assignee: William Burns
>
> I'm trying to use hibernate-search to host a Lucene index on Amazon S3 but I'm getting the following exception:
> {code}
> Exception in thread "LuceneIndexesData-CloudCacheStore-0" java.lang.IllegalArgumentException: bucketId: A96137216.bz2 (expected: integer)
> at org.infinispan.loaders.bucket.Bucket.setBucketId(Bucket.java:84)
> at org.infinispan.loaders.cloud.CloudCacheStore.readFromBlob(CloudCacheStore.java:450)
> at org.infinispan.loaders.cloud.CloudCacheStore.scanBlobForExpiredEntries(CloudCacheStore.java:292)
> at org.infinispan.loaders.cloud.CloudCacheStore.purge(CloudCacheStore.java:284)
> at org.infinispan.loaders.cloud.CloudCacheStore.purgeInternal(CloudCacheStore.java:336)
> at org.infinispan.loaders.AbstractCacheStore$2.run(AbstractCacheStore.java:111)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> at java.lang.Thread.run(Unknown Source)
> {code}
> The documentation for persisting Lucene indexes on Amazon-S3 is a little sparse but I think I'm on the right track. I'm trying to start infinispan embedded within my application so I've specified a path to the infinispan XML as follows in my hibernate.cfg.xml
> {code:xml}
> <property name="hibernate.search.default.directory_provider">infinispan</property>
> <property name="hibernate.search.infinispan.configuration_resourcename">infinispan-amazons3.xml</property>
> <property name="hibernate.search.infinispan.chunk_size">300000000</property>
> {code}
> And my infinispan-amazons3.xml is:
> {code:xml}
> <infinispan>
> <default>
> <loaders>
> <cloudStore xmlns="urn:infinispan:config:cloud:5.3"
> cloudService="aws-s3"
> identity="user"
> password="password"
> bucketPrefix="bucket">
> </cloudStore>
> </loaders>
> </default>
> </infinispan>
> {code}
> I'm using the following versions (maven pom.xml)
> {code}
> <dependency>
> <groupId>org.hibernate</groupId>
> <artifactId>hibernate-search</artifactId>
> <version>4.4.4.Final</version>
> </dependency>
> <dependency>
> <groupId>org.hibernate</groupId>
> <artifactId>hibernate-search-infinispan</artifactId>
> <version>4.4.4.Final</version>
> </dependency>
> <dependency>
> <groupId>org.infinispan</groupId>
> <artifactId>infinispan-cachestore-cloud</artifactId>
> <version>5.3.0.Final</version>
> </dependency>
> <dependency>
> <groupId>org.jclouds.provider</groupId>
> <artifactId>aws-s3</artifactId>
> <version>1.4.1</version>
> </dependency>
> {code}
> I initially thought this was related to ISPN-1909 but my version is after the fix for that issue (5.1.3.CR1, 5.1.3.FINAL)
> FYI here's my maven dependency tree (grepped for infinispan)
> {code}
> $ mvn dependency:tree | grep infinispan
> [INFO] +- org.hibernate:hibernate-search-infinispan:jar:4.4.4.Final:compile
> [INFO] | \- org.infinispan:infinispan-lucene-directory:jar:5.3.0.Final:compile
> [INFO] +- org.infinispan:infinispan-cachestore-cloud:jar:5.3.0.Final:compile
> [INFO] | \- org.infinispan:infinispan-core:jar:5.3.0.Final:compile
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 5 months
[JBoss JIRA] (ISPN-3830) Conditional Operation can fail erroneously during ST
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-3830?page=com.atlassian.jira.plugin.... ]
William Burns updated ISPN-3830:
--------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 7.0.0.CR2
Resolution: Done
> Conditional Operation can fail erroneously during ST
> ----------------------------------------------------
>
> Key: ISPN-3830
> URL: https://issues.jboss.org/browse/ISPN-3830
> Project: Infinispan
> Issue Type: Bug
> Components: State Transfer
> Reporter: William Burns
> Assignee: Dan Berindei
> Fix For: 7.0.0.CR2
>
>
> Currently the retry logic for commands is to only throw a OutdatedTopologyException when a command is successful.
> This however can have the following issue.
> k1 owned by N1, N2
> # N3 updates k1 sending conditional command to N1
> # N1 receives command and starts running it (passes topology block)
> # ST occurs causing N1 to no longer be an owner and removes k1 from it's data container.
> # N1 runs optional command and it fails and thus doesn't throw OutdatedTopologyException
> # N3 gets response that command failed, but it could have worked had it gone to a real owner.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 5 months
[JBoss JIRA] (ISPN-2465) Rollback sent twice in certain situations
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-2465?page=com.atlassian.jira.plugin.... ]
William Burns reassigned ISPN-2465:
-----------------------------------
Assignee: (was: William Burns)
> Rollback sent twice in certain situations
> -----------------------------------------
>
> Key: ISPN-2465
> URL: https://issues.jboss.org/browse/ISPN-2465
> Project: Infinispan
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 5.1.8.Final, 5.2.0.Final
> Reporter: Mircea Markus
> Priority: Minor
>
> If a prepare files e.g. due to a lock timeout, the initiating node sends a RollbackCommand before giving control back to the TransactionManager. The transaction manager might decide to invoke a rollback as well on the Synchrnization or XAResouce object, causing the rollback to be multicasted twice. This is not critical as the second Rollback is practically ignored, but unnecessary.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 5 months
[JBoss JIRA] (ISPN-3273) Dist L1 owners that aren't primary don't respect assumeOriginKeptEntryInL1
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-3273?page=com.atlassian.jira.plugin.... ]
William Burns commented on ISPN-3273:
-------------------------------------
This would require sending the origin information along in the request.
Actually thinking about this more this may also affect listeners in that the origin context is not used if the node isn't the primary owner.
Example:
N1, N2 k1 owned by N1, N2
N2 runs update k1 -> v1
N2 sends request to primary owner N1
N1 sends update back to N2 (in different context to update)
N1 updates k1 and notifies listener and says origin is not local
I would have to test the latter case but I think I have heard of issues with it before. Note it only also affects nontx caches since tx caches send the requests to all nodes (have to confirm).
> Dist L1 owners that aren't primary don't respect assumeOriginKeptEntryInL1
> --------------------------------------------------------------------------
>
> Key: ISPN-3273
> URL: https://issues.jboss.org/browse/ISPN-3273
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Reporter: William Burns
> Assignee: William Burns
> Fix For: 7.0.0.CR2
>
> Attachments: DistSyncFuncTest.java
>
>
> When a write operation occurs causing a L1 invalidation, there is a boolean to say assumeOriginKeptEntryInL1 which means the owner won't send an invalidation to the originating node that caused this update. This works fine for the primary owner, however any additional backups think the origin is the primary owner and such send invalidations to possibly the real origin.
> -This affects both tx and non tx caches. Tx caches that are sync don't see the problem since locking prevents the invalidation, however it causes an unneeded network roundtrip which can cause delay.-
> Actually this only affects non-tx caches, as tx caches send the prepare/commit directly to the owner(s) instead of having it relayed.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 5 months
[JBoss JIRA] (ISPN-3884) MarshalledValueContextTest fails on IBM6
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-3884?page=com.atlassian.jira.plugin.... ]
Work on ISPN-3884 stopped by William Burns.
-------------------------------------------
> MarshalledValueContextTest fails on IBM6
> ----------------------------------------
>
> Key: ISPN-3884
> URL: https://issues.jboss.org/browse/ISPN-3884
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite - Core
> Affects Versions: 7.0.0.Alpha1, 7.0.0.Alpha2, 7.0.0.Alpha3, 7.0.0.Alpha4
> Environment: RHEL6, IBM 6
> Reporter: Vojtech Juranek
> Assignee: William Burns
> Labels: testsuite_stability
>
> {noformat}
> java.lang.ArrayStoreException
> at java.util.ArrayList.set(ArrayList.java:635)
> at org.infinispan.commands.control.LockControlCommand.replaceKey(LockControlCommand.java:84)
> at org.infinispan.interceptors.MarshalledValueInterceptor.visitLockControlCommand(MarshalledValueInterceptor.java:91)
> at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.TxInterceptor.invokeNextInterceptorAndVerifyTransaction(TxInterceptor.java:114)
> at org.infinispan.interceptors.TxInterceptor.visitLockControlCommand(TxInterceptor.java:181)
> at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112)
> at org.infinispan.commands.AbstractVisitor.visitLockControlCommand(AbstractVisitor.java:147)
> at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.context.MarshalledValueContextTest$ContextExtractingInterceptor.handleDefault(MarshalledValueContextTest.java:79)
> at org.infinispan.commands.AbstractVisitor.visitLockControlCommand(AbstractVisitor.java:147)
> at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:110)
> at org.infinispan.interceptors.InvocationContextInterceptor.visitLockControlCommand(InvocationContextInterceptor.java:78)
> at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:110)
> at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:333)
> at org.infinispan.CacheImpl.lock(CacheImpl.java:656)
> at org.infinispan.CacheImpl.lock(CacheImpl.java:639)
> at org.infinispan.context.MarshalledValueContextTest.testContentsOfContext(MarshalledValueContextTest.java:52)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
> at java.lang.reflect.Method.invoke(Method.java:611)
> at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:80)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:715)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:907)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1237)
> at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127)
> at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111)
> at org.testng.TestRunner.privateRun(TestRunner.java:767)
> at org.testng.TestRunner.run(TestRunner.java:617)
> at org.testng.SuiteRunner.runTest(SuiteRunner.java:334)
> at org.testng.SuiteRunner.access$000(SuiteRunner.java:37)
> at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:368)
> at org.testng.internal.thread.ThreadUtil$2.call(ThreadUtil.java:64)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:314)
> at java.util.concurrent.FutureTask.run(FutureTask.java:149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:906)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:929)
> at java.lang.Thread.run(Thread.java:761)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 5 months
[JBoss JIRA] (ISPN-4837) @CacheEntryActivated events received for keys not matching KeyFilter
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-4837?page=com.atlassian.jira.plugin.... ]
William Burns updated ISPN-4837:
--------------------------------
Fix Version/s: 7.0.0.CR2
> @CacheEntryActivated events received for keys not matching KeyFilter
> --------------------------------------------------------------------
>
> Key: ISPN-4837
> URL: https://issues.jboss.org/browse/ISPN-4837
> Project: Infinispan
> Issue Type: Bug
> Components: Listeners
> Affects Versions: 7.0.0.CR1
> Reporter: Paul Ferraro
> Assignee: William Burns
> Priority: Critical
> Fix For: 7.0.0.CR2
>
>
> I have a local-mode Cache<Object, ?>, for which I register a cache listener using the following KeyFilter:
> {noformat}
> class MyFIlter implements KeyFilter<Object> {
> @Override
> public boolean accept(Object key) {
> return key instanceof String;
> }
> }
> {noformat}
> However, my listener method still receives events for keys that does not match the filter with which my listener was registered.
> e.g.
> {noformat}
> @CacheEntryActivated
> public void activated(CacheEntryActivatedEvent<String, ?> event) {
> String id = event.getKey(); // Throws a ClassCastException
> // ...
> }
> {noformat}
> I have not validated which other event types might exhibit the same issue.
> Since this is a behavior regression, I'm filing this as critical.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 5 months
[JBoss JIRA] (ISPN-4837) @CacheEntryActivated events received for keys not matching KeyFilter
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-4837?page=com.atlassian.jira.plugin.... ]
William Burns updated ISPN-4837:
--------------------------------
Status: Pull Request Sent (was: Coding In Progress)
Git Pull Request: https://github.com/infinispan/infinispan/pull/2958
> @CacheEntryActivated events received for keys not matching KeyFilter
> --------------------------------------------------------------------
>
> Key: ISPN-4837
> URL: https://issues.jboss.org/browse/ISPN-4837
> Project: Infinispan
> Issue Type: Bug
> Components: Listeners
> Affects Versions: 7.0.0.CR1
> Reporter: Paul Ferraro
> Assignee: William Burns
> Priority: Critical
>
> I have a local-mode Cache<Object, ?>, for which I register a cache listener using the following KeyFilter:
> {noformat}
> class MyFIlter implements KeyFilter<Object> {
> @Override
> public boolean accept(Object key) {
> return key instanceof String;
> }
> }
> {noformat}
> However, my listener method still receives events for keys that does not match the filter with which my listener was registered.
> e.g.
> {noformat}
> @CacheEntryActivated
> public void activated(CacheEntryActivatedEvent<String, ?> event) {
> String id = event.getKey(); // Throws a ClassCastException
> // ...
> }
> {noformat}
> I have not validated which other event types might exhibit the same issue.
> Since this is a behavior regression, I'm filing this as critical.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 5 months
[JBoss JIRA] (ISPN-4702) The ForkJoin thread pool should be started lazily
by Sanne Grinovero (JIRA)
[ https://issues.jboss.org/browse/ISPN-4702?page=com.atlassian.jira.plugin.... ]
Sanne Grinovero edited comment on ISPN-4702 at 10/15/14 8:48 AM:
-----------------------------------------------------------------
Ok I might be wrong then, I thought this would be started only in case of Map/Reduce jobs, which I wasn't doing so these threads which I was seeing in the stacktraces seemed they shouldn't have been there.
But I didn't know it was used by {{EquivalentConcurrentHashMapV8}}, that might explain it.. I'll need to check my test again, so I'll reassign this issue to myself to remember gathering a better description or eventually reject it.
Thanks!
was (Author: sannegrinovero):
Ok I might be wrong then, I thought this would be started only in case of Map/Reduce jobs, which I wasn't doing so these threads which I was seeing in the stacktraces seemed they shouldn't have been there.
But I didn't know it was used by {{EquivalentConcurrentHashMapV8}}, that might explain it.. I'll need to check my test again, so I'll take this issue for me to gather a better description or eventually reject it.
Thanks!
> The ForkJoin thread pool should be started lazily
> -------------------------------------------------
>
> Key: ISPN-4702
> URL: https://issues.jboss.org/browse/ISPN-4702
> Project: Infinispan
> Issue Type: Enhancement
> Components: Distributed Execution and Map/Reduce
> Affects Versions: 7.0.0.Beta1
> Reporter: Sanne Grinovero
> Assignee: Sanne Grinovero
> Priority: Minor
>
> I'm not using these features, yet a significant amount of threads are being started.
> We should at least start this pool only on-demand, and ideally shut it down after a grace period if it's no longer being used.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 5 months