[JBoss JIRA] (ISPN-4445) RHQ or CLI server -- cli.interpreter.ParseException in newly started cache for getting stats
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-4445?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-4445:
-----------------------------------
Fix Version/s: 7.1.0.Beta1
7.1.0.Final
Affects Version/s: 7.0.2.Final
(was: 7.0.0.Alpha4)
> RHQ or CLI server -- cli.interpreter.ParseException in newly started cache for getting stats
> --------------------------------------------------------------------------------------------
>
> Key: ISPN-4445
> URL: https://issues.jboss.org/browse/ISPN-4445
> Project: Infinispan
> Issue Type: Bug
> Components: CLI, JMX, reporting and management
> Affects Versions: 7.0.2.Final
> Reporter: Tomas Sykora
> Assignee: William Burns
> Fix For: 7.1.0.Beta1, 7.1.0.Final
>
>
> We found this issue during RHQ testing.
> When we create a new Cache child resource under cache-manager, it should create a cache, change server configuration file and (after server restart) monitor a new cache without problem.
> However, we spotted and issue in CLI. Even a connecting through jboss-cli.sh is showing the same problem with parsing.
> Relevant server console output:
> 07:44:28,195 INFO [org.jboss.as.clustering.infinispan] (MSC service thread 1-1) JBAS010281: Started new-local-cache-9990 cache from local container
> 07:44:28,369 INFO [org.jboss.as.remoting] (MSC service thread 1-1) JBAS017100: Listening on 0.0.0.0:9999
> 07:44:28,371 INFO [org.jboss.as.remoting] (MSC service thread 1-1) JBAS017100: Listening on 0.0.0.0:4447
> 07:44:28,550 INFO [org.jboss.as] (Controller Boot Thread) JBAS015961: Http management interface listening on http://0.0.0.0:9990/management
> 07:44:28,551 INFO [org.jboss.as] (Controller Boot Thread) JBAS015951: Admin console listening on http://0.0.0.0:9990
> 07:44:28,551 INFO [org.jboss.as] (Controller Boot Thread) JBAS015874: JBoss Data Grid 6.3.0 (AS 7.3.3.Final-redhat-3) started in 8928ms - Started 96 of 137 services (41 services are passive or on-demand)
> 07:46:16,328 INFO [org.jboss.as.clustering.infinispan] (management-handler-thread - 3) JBAS010281: Started ___defaultcache cache from local container
> 07:46:26,593 ERROR [stderr] (management-handler-thread - 2) line 1:10 mismatched character 'l' expecting '-'
> 07:46:26,607 ERROR [stderr] (management-handler-thread - 2) line 1:16 mismatched character 'c' expecting '-'
> 07:46:26,608 ERROR [stderr] (management-handler-thread - 2) line 1:22 mismatched character '9' expecting '-'
> 07:46:26,609 ERROR [org.infinispan.cli.interpreter.Interpreter] (management-handler-thread - 2) ISPN019003: Interpreter error: org.infinispan.cli.interpreter.ParseException: line 1:11 mismatched input 'ocal' expecting set null
> at org.infinispan.cli.interpreter.Interpreter.execute(Interpreter.java:144) [infinispan-cli-server-6.1.0.Final-redhat-1.jar:6.1.0.Final-redhat-1]
> at org.infinispan.server.infinispan.SecurityActions$6.run(SecurityActions.java:237) [infinispan-server-infinispan-6.1.0.Final-redhat-1.jar:6.1.0.Final-redhat-1]
> at org.infinispan.server.infinispan.SecurityActions$6.run(SecurityActions.java:234) [infinispan-server-infinispan-6.1.0.Final-redhat-1.jar:6.1.0.Final-redhat-1]
> at org.infinispan.security.Security.doPrivileged(Security.java:89) [infinispan-core-6.1.0.Final-redhat-1.jar:6.1.0.Final-redhat-1]
> at org.infinispan.server.infinispan.SecurityActions.doPrivileged(SecurityActions.java:55) [infinispan-server-infinispan-6.1.0.Final-redhat-1.jar:6.1.0.Final-redhat-1]
> at org.infinispan.server.infinispan.SecurityActions.executeInterpreter(SecurityActions.java:240) [infinispan-server-infinispan-6.1.0.Final-redhat-1.jar:6.1.0.Final-redhat-1]
> at org.jboss.as.clustering.infinispan.subsystem.CliInterpreterHandler.execute(CliInterpreterHandler.java:49) [infinispan-server-infinispan-6.1.0.Final-redhat-1.jar:6.1.0.Final-redhat-1]
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:601) [jboss-as-controller-7.3.3.Final-redhat-3.jar:7.3.3.Final-redhat-3]
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:479) [jboss-as-controller-7.3.3.Final-redhat-3.jar:7.3.3.Final-redhat-3]
> at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:283) [jboss-as-controller-7.3.3.Final-redhat-3.jar:7.3.3.Final-redhat-3]
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:278) [jboss-as-controller-7.3.3.Final-redhat-3.jar:7.3.3.Final-redhat-3]
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:231) [jboss-as-controller-7.3.3.Final-redhat-3.jar:7.3.3.Final-redhat-3]
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:137) [jboss-as-controller-7.3.3.Final-redhat-3.jar:7.3.3.Final-redhat-3]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:173) [jboss-as-controller-7.3.3.Final-redhat-3.jar:7.3.3.Final-redhat-3]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:105) [jboss-as-controller-7.3.3.Final-redhat-3.jar:7.3.3.Final-redhat-3]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:125) [jboss-as-controller-7.3.3.Final-redhat-3.jar:7.3.3.Final-redhat-3]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:121) [jboss-as-controller-7.3.3.Final-redhat-3.jar:7.3.3.Final-redhat-3]
> at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_09-icedtea]
> at javax.security.auth.Subject.doAs(Subject.java:415) [rt.jar:1.7.0_09-icedtea]
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:94) [jboss-as-controller-7.3.3.Final-redhat-3.jar:7.3.3.Final-redhat-3]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:121) [jboss-as-controller-7.3.3.Final-redhat-3.jar:7.3.3.Final-redhat-3]
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:283)
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:504)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [rt.jar:1.7.0_09-icedtea]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [rt.jar:1.7.0_09-icedtea]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_09-icedtea]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final-redhat-1.jar:2.1.1.Final-redhat-1]
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (ISPN-5078) RHQ Server Rebalancing value doesn't display properly
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-5078?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-5078:
-----------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 7.1.0.Final
Resolution: Done
> RHQ Server Rebalancing value doesn't display properly
> -----------------------------------------------------
>
> Key: ISPN-5078
> URL: https://issues.jboss.org/browse/ISPN-5078
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 7.0.2.Final
> Reporter: William Burns
> Assignee: William Burns
> Fix For: 7.1.0.Beta1, 7.1.0.Final
>
>
> The rebalancing for a distributed/replicated cache is always displayed as undefined in RHQ even if the server has a value. This appears to be because the :read-resource operation always returns it as undefined. Using the ls command in jboss-cli.sh properly shows the value though.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (ISPN-5021) Nodes that finish the rebalance later can see outdated values
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-5021?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo commented on ISPN-5021:
-----------------------------------
[~dan.berindei], I don't think we need to remove the old entries and ignore the writes in the 2nd topology update. I think the data will be kept consistency and we avoid some checking in which state we are.
> Nodes that finish the rebalance later can see outdated values
> -------------------------------------------------------------
>
> Key: ISPN-5021
> URL: https://issues.jboss.org/browse/ISPN-5021
> Project: Infinispan
> Issue Type: Bug
> Components: Core, State Transfer
> Affects Versions: 7.0.2.Final
> Reporter: Dan Berindei
> Assignee: Pedro Ruivo
> Priority: Critical
> Fix For: 7.1.0.Beta1
>
>
> Copied from [ISPN-4444|https://issues.jboss.org/browse/ISPN-4444?focusedCommentId=1302...]
> If the CH_UPDATE command is delayed on the old owner, the new owners might update the key without the old owner knowing, and a locality check on the old owner won't help.
> I remember one thing that struck me when reading the Raft algorithm was that they install configuration changes symmetrically, in 3 phases. We might need to do the same for our rebalance: start a rebalance with read_ch=old, write_ch=old+new, when the new owners have all the data install read_ch=new, write_ch=old+new, and finally read_ch=new, write_ch=new. Old cache entries are removed during the 2nd topology update, and further writes should be ignored, in order for this to work.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (ISPN-5021) Nodes that finish the rebalance later can see outdated values
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-5021?page=com.atlassian.jira.plugin.... ]
Work on ISPN-5021 started by Pedro Ruivo.
-----------------------------------------
> Nodes that finish the rebalance later can see outdated values
> -------------------------------------------------------------
>
> Key: ISPN-5021
> URL: https://issues.jboss.org/browse/ISPN-5021
> Project: Infinispan
> Issue Type: Bug
> Components: Core, State Transfer
> Affects Versions: 7.0.2.Final
> Reporter: Dan Berindei
> Assignee: Pedro Ruivo
> Priority: Critical
> Fix For: 7.1.0.Beta1
>
>
> Copied from [ISPN-4444|https://issues.jboss.org/browse/ISPN-4444?focusedCommentId=1302...]
> If the CH_UPDATE command is delayed on the old owner, the new owners might update the key without the old owner knowing, and a locality check on the old owner won't help.
> I remember one thing that struck me when reading the Raft algorithm was that they install configuration changes symmetrically, in 3 phases. We might need to do the same for our rebalance: start a rebalance with read_ch=old, write_ch=old+new, when the new owners have all the data install read_ch=new, write_ch=old+new, and finally read_ch=new, write_ch=new. Old cache entries are removed during the 2nd topology update, and further writes should be ignored, in order for this to work.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (ISPN-4445) RHQ or CLI server -- cli.interpreter.ParseException in newly started cache for getting stats
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-4445?page=com.atlassian.jira.plugin.... ]
William Burns updated ISPN-4445:
--------------------------------
Git Pull Request: https://github.com/infinispan/infinispan/pull/3167 (was: https://github.com/infinispan/infinispan/pull/3164)
> RHQ or CLI server -- cli.interpreter.ParseException in newly started cache for getting stats
> --------------------------------------------------------------------------------------------
>
> Key: ISPN-4445
> URL: https://issues.jboss.org/browse/ISPN-4445
> Project: Infinispan
> Issue Type: Bug
> Components: CLI, JMX, reporting and management
> Affects Versions: 7.0.0.Alpha4
> Reporter: Tomas Sykora
> Assignee: William Burns
>
> We found this issue during RHQ testing.
> When we create a new Cache child resource under cache-manager, it should create a cache, change server configuration file and (after server restart) monitor a new cache without problem.
> However, we spotted and issue in CLI. Even a connecting through jboss-cli.sh is showing the same problem with parsing.
> Relevant server console output:
> 07:44:28,195 INFO [org.jboss.as.clustering.infinispan] (MSC service thread 1-1) JBAS010281: Started new-local-cache-9990 cache from local container
> 07:44:28,369 INFO [org.jboss.as.remoting] (MSC service thread 1-1) JBAS017100: Listening on 0.0.0.0:9999
> 07:44:28,371 INFO [org.jboss.as.remoting] (MSC service thread 1-1) JBAS017100: Listening on 0.0.0.0:4447
> 07:44:28,550 INFO [org.jboss.as] (Controller Boot Thread) JBAS015961: Http management interface listening on http://0.0.0.0:9990/management
> 07:44:28,551 INFO [org.jboss.as] (Controller Boot Thread) JBAS015951: Admin console listening on http://0.0.0.0:9990
> 07:44:28,551 INFO [org.jboss.as] (Controller Boot Thread) JBAS015874: JBoss Data Grid 6.3.0 (AS 7.3.3.Final-redhat-3) started in 8928ms - Started 96 of 137 services (41 services are passive or on-demand)
> 07:46:16,328 INFO [org.jboss.as.clustering.infinispan] (management-handler-thread - 3) JBAS010281: Started ___defaultcache cache from local container
> 07:46:26,593 ERROR [stderr] (management-handler-thread - 2) line 1:10 mismatched character 'l' expecting '-'
> 07:46:26,607 ERROR [stderr] (management-handler-thread - 2) line 1:16 mismatched character 'c' expecting '-'
> 07:46:26,608 ERROR [stderr] (management-handler-thread - 2) line 1:22 mismatched character '9' expecting '-'
> 07:46:26,609 ERROR [org.infinispan.cli.interpreter.Interpreter] (management-handler-thread - 2) ISPN019003: Interpreter error: org.infinispan.cli.interpreter.ParseException: line 1:11 mismatched input 'ocal' expecting set null
> at org.infinispan.cli.interpreter.Interpreter.execute(Interpreter.java:144) [infinispan-cli-server-6.1.0.Final-redhat-1.jar:6.1.0.Final-redhat-1]
> at org.infinispan.server.infinispan.SecurityActions$6.run(SecurityActions.java:237) [infinispan-server-infinispan-6.1.0.Final-redhat-1.jar:6.1.0.Final-redhat-1]
> at org.infinispan.server.infinispan.SecurityActions$6.run(SecurityActions.java:234) [infinispan-server-infinispan-6.1.0.Final-redhat-1.jar:6.1.0.Final-redhat-1]
> at org.infinispan.security.Security.doPrivileged(Security.java:89) [infinispan-core-6.1.0.Final-redhat-1.jar:6.1.0.Final-redhat-1]
> at org.infinispan.server.infinispan.SecurityActions.doPrivileged(SecurityActions.java:55) [infinispan-server-infinispan-6.1.0.Final-redhat-1.jar:6.1.0.Final-redhat-1]
> at org.infinispan.server.infinispan.SecurityActions.executeInterpreter(SecurityActions.java:240) [infinispan-server-infinispan-6.1.0.Final-redhat-1.jar:6.1.0.Final-redhat-1]
> at org.jboss.as.clustering.infinispan.subsystem.CliInterpreterHandler.execute(CliInterpreterHandler.java:49) [infinispan-server-infinispan-6.1.0.Final-redhat-1.jar:6.1.0.Final-redhat-1]
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:601) [jboss-as-controller-7.3.3.Final-redhat-3.jar:7.3.3.Final-redhat-3]
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:479) [jboss-as-controller-7.3.3.Final-redhat-3.jar:7.3.3.Final-redhat-3]
> at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:283) [jboss-as-controller-7.3.3.Final-redhat-3.jar:7.3.3.Final-redhat-3]
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:278) [jboss-as-controller-7.3.3.Final-redhat-3.jar:7.3.3.Final-redhat-3]
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:231) [jboss-as-controller-7.3.3.Final-redhat-3.jar:7.3.3.Final-redhat-3]
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:137) [jboss-as-controller-7.3.3.Final-redhat-3.jar:7.3.3.Final-redhat-3]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:173) [jboss-as-controller-7.3.3.Final-redhat-3.jar:7.3.3.Final-redhat-3]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:105) [jboss-as-controller-7.3.3.Final-redhat-3.jar:7.3.3.Final-redhat-3]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:125) [jboss-as-controller-7.3.3.Final-redhat-3.jar:7.3.3.Final-redhat-3]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:121) [jboss-as-controller-7.3.3.Final-redhat-3.jar:7.3.3.Final-redhat-3]
> at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_09-icedtea]
> at javax.security.auth.Subject.doAs(Subject.java:415) [rt.jar:1.7.0_09-icedtea]
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:94) [jboss-as-controller-7.3.3.Final-redhat-3.jar:7.3.3.Final-redhat-3]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:121) [jboss-as-controller-7.3.3.Final-redhat-3.jar:7.3.3.Final-redhat-3]
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:283)
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:504)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [rt.jar:1.7.0_09-icedtea]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [rt.jar:1.7.0_09-icedtea]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_09-icedtea]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final-redhat-1.jar:2.1.1.Final-redhat-1]
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (ISPN-4491) Cluster Listener Event Batching
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-4491?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-4491:
-----------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 7.1.0.Final
Resolution: Done
> Cluster Listener Event Batching
> -------------------------------
>
> Key: ISPN-4491
> URL: https://issues.jboss.org/browse/ISPN-4491
> Project: Infinispan
> Issue Type: Enhancement
> Components: Listeners
> Affects Versions: 7.0.2.Final
> Reporter: William Burns
> Assignee: William Burns
> Fix For: 7.1.0.Beta1, 7.1.0.Final
>
>
> Currently when a local listener which was installed for a cluster listener finds an event to send back to the parent it does this 1 message per listener. It might be more beneficial if we had batching so that it wouldn't send 1 message per.
> There are 2 cases I can think of which this would benefit.
> # When the underlying transport is UDP. In this case we can send just 1 message to all the nodes for the event instead of N Unicasts
> # When a node has more than 1 cluster listener installed we could send a single message to notifiy more than 1 listener.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (ISPN-4491) Cluster Listener Event Batching
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-4491?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-4491:
-----------------------------------
Affects Version/s: 7.0.2.Final
(was: 7.0.0.Alpha4)
> Cluster Listener Event Batching
> -------------------------------
>
> Key: ISPN-4491
> URL: https://issues.jboss.org/browse/ISPN-4491
> Project: Infinispan
> Issue Type: Enhancement
> Components: Listeners
> Affects Versions: 7.0.2.Final
> Reporter: William Burns
> Assignee: William Burns
> Fix For: 7.1.0.Beta1, 7.1.0.Final
>
>
> Currently when a local listener which was installed for a cluster listener finds an event to send back to the parent it does this 1 message per listener. It might be more beneficial if we had batching so that it wouldn't send 1 message per.
> There are 2 cases I can think of which this would benefit.
> # When the underlying transport is UDP. In this case we can send just 1 message to all the nodes for the event instead of N Unicasts
> # When a node has more than 1 cluster listener installed we could send a single message to notifiy more than 1 listener.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 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:
----------------------------------------
Hi, I'm wondering if anyone has been able to make any progress on this issue?
> 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.11#6341)
11 years, 3 months
[JBoss JIRA] (ISPN-4433) Can not run INFINISPAN testsuite with JDK8
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-4433?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-4433:
-----------------------------------------------
Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1084904|https://bugzilla.redhat.com/show_bug.cgi?id=1084904] from ASSIGNED to POST
> Can not run INFINISPAN testsuite with JDK8
> -------------------------------------------
>
> Key: ISPN-4433
> URL: https://issues.jboss.org/browse/ISPN-4433
> Project: Infinispan
> Issue Type: Bug
> Components: Build process
> Affects Versions: 7.0.0.Alpha4
> Reporter: Vitalii Chepeliuk
> Assignee: Mircea Markus
> Fix For: 7.0.0.Alpha5
>
>
> {noformat}
> [ERROR] Failed to execute goal org.codehaus.mojo:animal-sniffer-maven-plugin:1.9:check (default) on project infinispan-cachestore-jdbc: Execution default of goal org.codehaus.mojo:animal-sniffer-maven-plugin:1.9:check failed. IllegalArgumentException -> [Help 1]
> [ERROR] Failed to execute goal org.codehaus.mojo:animal-sniffer-maven-plugin:1.9:check (default) on project infinispan-lucene-v3: Execution default of goal org.codehaus.mojo:animal-sniffer-maven-plugin:1.9:check failed. IllegalArgumentException -> [Help 1]
> [ERROR] Failed to execute goal org.apache.maven.plugins:maven-dependency-plugin:2.8:unpack (unpack) on project infinispan-lucene-directory: Artifact has not been packaged yet. When used on reactor artifact, unpack should be executed after packaging: see MDEP-98. -> [Help 2]
> [ERROR] Failed to execute goal org.codehaus.mojo:animal-sniffer-maven-plugin:1.9:check (default) on project infinispan-query: Execution default of goal org.codehaus.mojo:animal-sniffer-maven-plugin:1.9:check failed. IllegalArgumentException -> [Help 1]
> [ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.1:compile (default-compile) on project infinispan-tools: Compilation failure: Compilation failure:
> [ERROR] /mnt/hudson_workspace/workspace/edg-60-ispn-testsuite-rhel/89fa96e5/infinispan/tools/src/main/java/org/infinispan/tools/doclet/jmx/JmxDoclet.java:[67,32] cannot find symbol
> [ERROR] symbol: method getInstance()
> [ERROR] location: class com.sun.tools.doclets.formats.html.ConfigurationImpl
> [ERROR] /mnt/hudson_workspace/workspace/edg-60-ispn-testsuite-rhel/89fa96e5/infinispan/tools/src/main/java/org/infinispan/tools/doclet/jmx/JmxDoclet.java:[80,32] cannot find symbol
> [ERROR] symbol: method getInstance()
> [ERROR] location: class com.sun.tools.doclets.formats.html.ConfigurationImpl
> [ERROR] -> [Help 3]
> {noformat}
> Look on last Jenkins run with JDK8
> * RHEL5
> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JDG/view/FUNC/job/e...
> * RHEL6
> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JDG/view/FUNC/job/e...
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months