[JBoss JIRA] (ISPN-4445) RHQ or CLI server -- cli.interpreter.ParseException in newly started cache for getting stats
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-4445?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-4445:
-----------------------------------------------
Tomas Sykora <tsykora(a)redhat.com> changed the Status of [bug 1113552|https://bugzilla.redhat.com/show_bug.cgi?id=1113552] from ON_QA to VERIFIED
> 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)
9 years, 3 months
- 1
- 0
[JBoss JIRA] (ISPN-4499) Prevent shadowing user-defined jgroups configuration file
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-4499?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-4499:
-----------------------------------------------
Martin Gencur <mgencur(a)redhat.com> changed the Status of [bug 1115555|https://bugzilla.redhat.com/show_bug.cgi?id=1115555] from ON_QA to VERIFIED
> Prevent shadowing user-defined jgroups configuration file
> ---------------------------------------------------------
>
> Key: ISPN-4499
> URL: https://issues.jboss.org/browse/ISPN-4499
> Project: Infinispan
> Issue Type: Enhancement
> Components: Configuration
> Affects Versions: 7.0.0.Alpha4
> Reporter: Martin Gencur
> Assignee: Martin Gencur
> Fix For: 7.0.0.Alpha5
>
>
> When users create their own JGroups configuration file and name it the same way as default configuration files (jgroups-udp.xml / jgroups-tcp-xml / jgroups-ec2.xml), they might not be visible to the user application as they're shadowed by the default configuration files.
> Proposed solution:
> * place current jgroups configuration files into META-INF/configs folder (this folder doesn't have to have an obscure name such as "_internal" because of the following two points which complement the solution)
> * define order in which the config files are read by class loader (i.e. first scan user application, then path under META-INF/configs)
> * when Infinispan is started, log the path to the configuration file used, e.g.:
> {code}
> 2014-06-12 06:45:02,871 [thread-name] INFO [package-name] Using JGroups configuration file 'jar:META-INF/example_configurations/jgroups/udp.xml'
> 2014-06-12 06:45:02,871 [thread-name] INFO [package-name] Using JGroups configuration file 'file:/app_home/config/jgroups-udp.xml'
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 3 months
- 1
- 0
[JBoss JIRA] (ISPN-5062) Cross site state transfer - incorrect status of push operation
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-5062?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-5062:
-----------------------------------------------
Matej Čimbora <mcimbora(a)redhat.com> changed the Status of [bug 1172034|https://bugzilla.redhat.com/show_bug.cgi?id=1172034] from ON_QA to VERIFIED
> Cross site state transfer - incorrect status of push operation
> ---------------------------------------------------------------
>
> Key: ISPN-5062
> URL: https://issues.jboss.org/browse/ISPN-5062
> Project: Infinispan
> Issue Type: Bug
> Components: State Transfer
> Affects Versions: 7.1.0.Alpha1
> Reporter: Matej Čimbora
> Assignee: Pedro Ruivo
> Fix For: 7.1.0.Beta1, 7.1.0.Final
>
>
> Status of push operation remains at value "CANCELLED" after the push operation was cancelled and reinvoked (even if state transfer is currently in progress) - "SENDING" value is expected. Otherwise works as expected (after the state transfer completes, status is switched to "OK").
> - Sites LON (lonCache) - main, BRN (brnCache) - backup
> Consider the following scenario:
> [standalone@localhost:9999 distributed-cache=lonCache] site --push BRN
> ok
> [standalone@localhost:9999 distributed-cache=lonCache] site --cancelpush BRN
> ok
> [standalone@localhost:9999 distributed-cache=lonCache] site --pushstatus
> BRN=CANCELED
> [standalone@localhost:9999 distributed-cache=lonCache] site --push BRN
> ok
> [standalone@localhost:9999 distributed-cache=lonCache] site --pushstatus
> BRN=CANCELED
> [standalone@localhost:9999 distributed-cache=lonCache] site --pushstatus
> BRN=OK
> Expected behavior:
> [standalone@localhost:9999 distributed-cache=lonCache] site --push BRN
> ok
> [standalone@localhost:9999 distributed-cache=lonCache] site --cancelpush BRN
> ok
> [standalone@localhost:9999 distributed-cache=lonCache] site --pushstatus
> BRN=CANCELED
> [standalone@localhost:9999 distributed-cache=lonCache] site --push BRN
> ok
> [standalone@localhost:9999 distributed-cache=lonCache] site --pushstatus
> BRN=SENDING
> [standalone@localhost:9999 distributed-cache=lonCache] site --pushstatus
> BRN=OK
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 3 months
- 1
- 0