[JBoss JIRA] (WFLY-8517) ActiveMQ JGroups-based discovery is broken
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-8517?page=com.atlassian.jira.plugin.... ]
Paul Ferraro moved JBEAP-10162 to WFLY-8517:
--------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-8517 (was: JBEAP-10162)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Clustering
JMS
(was: Clustering)
(was: JMS)
Affects Version/s: 11.0.0.Alpha1
(was: 7.1.0.DR15)
> ActiveMQ JGroups-based discovery is broken
> ------------------------------------------
>
> Key: WFLY-8517
> URL: https://issues.jboss.org/browse/WFLY-8517
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, JMS
> Affects Versions: 11.0.0.Alpha1
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
>
> JGroups-based discovery was broken by this commit:
> https://github.com/wildfly/wildfly/commit/b0244166a3a72aa891aa37ec7b0b866...
> {noformat}
> 2017-04-04 13:56:47,301 WARN [org.apache.activemq.artemis.core.client] (Thread-1 (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$3@66462207-730663955)) AMQ212025: did not conne
> ct the cluster connection to other nodes: ActiveMQConnectionTimedOutException[errorType=CONNECTION_TIMEDOUT message=AMQ119013: Timed out waiting to receive cluster topology. Group:org.apache.activemq.artemis.co
> re.cluster.DiscoveryGroup@391e867]
> at org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.createSessionFactory(ServerLocatorImpl.java:803)
> at org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.connect(ServerLocatorImpl.java:627)
> at org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.connect(ServerLocatorImpl.java:609)
> at org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl$5.run(ServerLocatorImpl.java:1533)
> at org.apache.activemq.artemis.utils.OrderedExecutorFactory$OrderedExecutor$ExecutorTask.run(OrderedExecutorFactory.java:101)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFLY-8516) Documentation in the XSD for the queue-length is incorrect based on the model description
by James Perkins (JIRA)
James Perkins created WFLY-8516:
-----------------------------------
Summary: Documentation in the XSD for the queue-length is incorrect based on the model description
Key: WFLY-8516
URL: https://issues.jboss.org/browse/WFLY-8516
Project: WildFly
Issue Type: Bug
Components: EE
Reporter: James Perkins
Assignee: James Perkins
The documentation for in the XSD for the {{queue-length}} on the {{managed-executor-service}} states:
{quote}
A managed executor service (implementing javax.enterprise.concurrent.ManagedExecutorService).
If the "thread-factory" attribute is not defined a managed thread factory with no context service and normal thread priority will be created and used by the executor.
The task queue is based on the values of "core-threads" and "queue-length":
* If "queue-length" is 0, or "queue-length" is Integer.MAX_VALUE (2147483647) and "core-threads" is 0, direct handoff queuing strategy will be used and a SynchronousQueue will be created.
* If "queue-length" is Integer.MAX_VALUE but "core-threads" is not 0, an unbounded queue will be used.
* For any other valid value for "queue-length", a bounded queue wil be created.
{quote}
The model description states:
{quote}
The executors task queue capacity. A length of 0 means direct hand-off and possible rejection will occur. An undefined length (the default), or Integer.MAX_VALUE, indicates that an unbounded queue should be used. All other values specify an exact queue size. If an unbounded queue or direct hand-off is used, a core-threads value greater than zero is required.
{quote}
The two descriptions should match. The model validation should also be checked as one of the messages doesn't seem to be correct:
{code:java}
// Validate an unbounded queue
if (!queueLength.isDefined() || queueLength.asInt() == Integer.MAX_VALUE) {
if (coreThreads.isDefined() && coreThreads.asInt() <= 0) {
throw EeLogger.ROOT_LOGGER.invalidCoreThreadsSize(coreThreads.asString());
}
}
{code}
That message doesn't really describe the real problem and will always be
{quote}
WFLYEE0112: The core-threads value must be greater than 0 when the queue-length is 0
{quote}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFCORE-1536) NPE thrown during application redeployment, slaves taken offline
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1536?page=com.atlassian.jira.plugi... ]
RH Bugzilla Integration commented on WFCORE-1536:
-------------------------------------------------
Radovan Netuka <rnetuka(a)redhat.com> changed the Status of [bug 1406562|https://bugzilla.redhat.com/show_bug.cgi?id=1406562] from POST to MODIFIED
> NPE thrown during application redeployment, slaves taken offline
> ----------------------------------------------------------------
>
> Key: WFCORE-1536
> URL: https://issues.jboss.org/browse/WFCORE-1536
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Matthew Casperson
> Assignee: ehsavoie Hugonnet
> Fix For: 3.0.0.Alpha2
>
>
> We have some development Wildfly 10.0.0 servers running as slaves in a domain that frequently have WAR files redeployed. We have noticed that these slaves will often go offline after a redeployment of WAR files with the following stack trace:
> {code}
> 2016-05-06 05:05:51,306 ERROR [org.jboss.as.controller.management-operation] (Host Controller Service Threads - 1012) WFLYCTL0190: Step handler org.jboss.as.domain.controller.operations.deployment.DeploymentFullReplaceHandler@3f68226b for operation {"operation" => "full-replace-deployment","name" => "whatever.war","enabled" => true,"content" => [{"hash" => bytes { 0x5d, 0x12, 0x18, 0x2b, 0x1c, 0x86, 0x71, 0x27, 0x08, 0x3d, 0xf1, 0x75, 0x08, 0x29, 0xa6, 0x49, 0x1f, 0x16, 0xe8, 0x22 }}],"operation-headers" => {"access-mechanism" => "NATIVE","domain-uuid" => "802ab616-dd2c-4081-a79c-c4d54e14c384","push-to-servers" => undefined},"address" => [],"runtime-name" => undefined} at address [] failed handling operation rollback -- java.lang.NullPointerException: java.lang.NullPointerException
> at org.jboss.as.repository.LocalDeploymentFileRepository.deleteDeployment(LocalDeploymentFileRepository.java:59)
> at org.jboss.as.host.controller.RemoteDomainConnectionService$RemoteFileRepository.deleteDeployment(RemoteDomainConnectionService.java:756)
> at org.jboss.as.domain.controller.operations.deployment.DeploymentFullReplaceHandler$1.handleResult(DeploymentFullReplaceHandler.java:181)
> at org.jboss.as.controller.AbstractOperationContext$Step.invokeResultHandler(AbstractOperationContext.java:1384)
> at org.jboss.as.controller.AbstractOperationContext$Step.handleResult(AbstractOperationContext.java:1366)
> at org.jboss.as.controller.AbstractOperationContext$Step.finalizeInternal(AbstractOperationContext.java:1328)
> at org.jboss.as.controller.AbstractOperationContext$Step.finalizeStep(AbstractOperationContext.java:1311)
> at org.jboss.as.controller.AbstractOperationContext$Step.access$300(AbstractOperationContext.java:1185)
> at org.jboss.as.controller.AbstractOperationContext.executeResultHandlerPhase(AbstractOperationContext.java:767)
> at org.jboss.as.controller.AbstractOperationContext.executeDoneStage(AbstractOperationContext.java:753)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:680)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1344)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:392)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:217)
> at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler.internalExecute(TransactionalProtocolOperationHandler.java:247)
> at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler.doExecute(TransactionalProtocolOperationHandler.java:185)
> at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$1.run(TransactionalProtocolOperationHandler.java:138)
> at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$1.run(TransactionalProtocolOperationHandler.java:134)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:360)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:81)
> at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2$1.run(TransactionalProtocolOperationHandler.java:157)
> at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2$1.run(TransactionalProtocolOperationHandler.java:153)
> at java.security.AccessController.doPrivileged(Native Method)
> at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2.execute(TransactionalProtocolOperationHandler.java:153)
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$ManagementRequestContextImpl$1.doExecute(AbstractMessageHandler.java:363)
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:472)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {code}
> This error will usually only happen for 2 out of the 4 identically configured slaves, and seems to happen randomly, although frequently enough.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (DROOLS-1130) Using fireAllRules, Timed rules does not cascade rule execution after modifying a fact, event when Session conf is set to TimedRuleExectionOption.YES
by Pedro Almeida (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1130?page=com.atlassian.jira.plugi... ]
Pedro Almeida commented on DROOLS-1130:
---------------------------------------
[~mfusco], I've been trying to update my version from Drools 5.3.2 to the latest Drools version (6.5.0.Final) and I'm having the same problem as exposed in this issue. On Drools 5, the second rule would trigger, on Drools 6 it does not. If it's not a bug, is it a documented change ?
Cannot find nothing on this particular subject. Is there a way of triggering the fireAllRules at the end of each timer ?
Thanks.
> Using fireAllRules, Timed rules does not cascade rule execution after modifying a fact, event when Session conf is set to TimedRuleExectionOption.YES
> -----------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-1130
> URL: https://issues.jboss.org/browse/DROOLS-1130
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.3.0.Final
> Reporter: Juan Carlos Garcia
> Assignee: Mario Fusco
> Attachments: timer-rule-bug.zip
>
>
> I have a DRL file with 2 rules and the first rule has a timer of 3s, after this rule gets fired and a fact is modified, i expect a second rule to get activate and trigger but is not happening. Even though the documentation explicitly said in the 2.9.2 section of:
> http://docs.jboss.org/drools/release/6.3.0.Final/drools-docs/html/ch02.ht...
> _When the rule engine runs in passive mode (i.e.: using fireAllRules) by default it doesn't fire consequences of timed rules unless fireAllRules isn't invoked again. Now it is possible to change this default behavior by configuring the KieSession with a *TimedRuleExectionOption*_
> Please advise if i have misunderstood the expected behavior, attached is a demo project enclosing the mentioned rules and a testcase.
> *DRL:*
> {code}
> import java.util.logging.Logger
> import bug.timedrules.Table
> rule "table with 1 player"
> timer( int: 3s)
> no-loop true
> when
> $table : Table( getCounter() == 1)
> then
> Logger.getLogger("timer.drl").info("triggered - counter is 1");
> modify($table){
> setCounter(2)
> }
> end
> rule "Table upgrade to 2 player"
> no-loop true
> when
> $table : Table( getCounter() == 2)
> then
> Logger.getLogger("timer.drl").info("triggered - counter is 2");
> modify($table){
> setCounter(3)
> }
> end
> {code}
> *java code:*
> {code}
> @Test
> public void executeNewRuleAfterTimedRuleExecution() throws Exception {
> KieBaseConfiguration config = KnowledgeBaseFactory.newKnowledgeBaseConfiguration();
> KieSessionConfiguration ksconf = KieServices.Factory.get().newKieSessionConfiguration();
> ksconf.setOption(TimedRuleExectionOption.YES);
> config.setOption(EventProcessingOption.STREAM);
> KnowledgeBase kbase = KnowledgeBaseFactory.newKnowledgeBase(config);
> final KnowledgeBuilder kbuilder = KnowledgeBuilderFactory.newKnowledgeBuilder();
> kbuilder.add(ResourceFactory.newClassPathResource("bug/timer/timer.drl", BugTest.class), ResourceType.DRL);
> if (kbuilder.hasErrors()) {
> throw new IllegalStateException(kbuilder.getErrors().toString());
> }
> kbase = KnowledgeBaseFactory.newKnowledgeBase(config);
> kbase.addKnowledgePackages(kbuilder.getKnowledgePackages());
> final StatefulKnowledgeSession statefulKnowledgeSession = kbase.newStatefulKnowledgeSession(ksconf, null);
> Table table = new Table(1234, 1);
> statefulKnowledgeSession.insert(table);
> statefulKnowledgeSession.fireAllRules();
> Thread.sleep(TimeUnit.SECONDS.toMillis(5));
> statefulKnowledgeSession.dispose();
> Assert.assertThat(table.getCounter(), CoreMatchers.is(3));
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (ELY-1059) When I set iteration value as STRING or NEGATIVE integer then I get different error messages.
by Ilia Vassilev (JIRA)
[ https://issues.jboss.org/browse/ELY-1059?page=com.atlassian.jira.plugin.s... ]
Ilia Vassilev reassigned ELY-1059:
----------------------------------
Assignee: Ilia Vassilev (was: Darran Lofthouse)
> When I set iteration value as STRING or NEGATIVE integer then I get different error messages.
> ---------------------------------------------------------------------------------------------
>
> Key: ELY-1059
> URL: https://issues.jboss.org/browse/ELY-1059
> Project: WildFly Elytron
> Issue Type: Bug
> Reporter: Hynek Švábek
> Assignee: Ilia Vassilev
>
> When I set iteration value as STRING or NEGATIVE integer then I get different error messages rather the same one.
> {code}
> [hsvabek@localhost bin]$ java -jar wildfly-elytron-tool.jar mask -x secret_password -s 12345678 --iteration="-123"
> ELY03025: Iteration count not specified for password based encryption
> [hsvabek@localhost bin]$ java -jar wildfly-elytron-tool.jar mask -x secret_password -s 12345678 --iteration="ab123"
> java.lang.NumberFormatException: For input string: "ab123"
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (ELY-1058) When we set wrong ITERATION value (too big number or string) then we get NumberFormatException.
by Ilia Vassilev (JIRA)
[ https://issues.jboss.org/browse/ELY-1058?page=com.atlassian.jira.plugin.s... ]
Ilia Vassilev reassigned ELY-1058:
----------------------------------
Assignee: Ilia Vassilev (was: Darran Lofthouse)
> When we set wrong ITERATION value (too big number or string) then we get NumberFormatException.
> -----------------------------------------------------------------------------------------------
>
> Key: ELY-1058
> URL: https://issues.jboss.org/browse/ELY-1058
> Project: WildFly Elytron
> Issue Type: Bug
> Reporter: Hynek Švábek
> Assignee: Ilia Vassilev
>
> When we set wrong ITERATION value (too big number or string) then we get NumberFormatException.
> I expect here some meaningful message about what we expected -> e.g. integer value and its maximum value.
> {code}
> java -jar wildfly-elytron-tool.jar mask -x secret_password -i 2301145145644 -s 12用戶
> java.lang.NumberFormatException: For input string: "2301145145644"
> {code}
> {code}
> java -jar wildfly-elytron-tool.jar mask -x secret_password -i 230sd644 -s 12用戶
> java.lang.NumberFormatException: For input string: "230sd644"
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFLY-8514) Default profiles reference deprecated infinispan/jgroups/mod_cluster module extension names
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-8514?page=com.atlassian.jira.plugin.... ]
Radoslav Husar edited comment on WFLY-8514 at 4/5/17 12:17 PM:
---------------------------------------------------------------
[~brian.stansberry] I realize by now this is not possible as we don't have a mechanism to translate extension names the legacy slaves. :-(
was (Author: rhusar):
[~brian.stansberry] I realize by now this is not possible as we don't have a mechanism to support the legacy slaves. :-(
> Default profiles reference deprecated infinispan/jgroups/mod_cluster module extension names
> -------------------------------------------------------------------------------------------
>
> Key: WFLY-8514
> URL: https://issues.jboss.org/browse/WFLY-8514
> Project: WildFly
> Issue Type: Bug
> Components: mod_cluster
> Affects Versions: 11.0.0.Alpha1
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Priority: Minor
>
> The correct module to reference is {{org.wildfly.extension.mod_cluster}}.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months