April 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JGRP-2437) Log local_addr and name in JChannel

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-2437?page=com.atlassian.jira.plugin... ] Bela Ban updated JGRP-2437: --------------------------- Fix Version/s: 5.0.0.Alpha6 > Log local_addr and name in JChannel > ----------------------------------- > > Key: JGRP-2437 > URL: https://issues.redhat.com/browse/JGRP-2437 > Project: JGroups > Issue Type: Enhancement > Reporter: Diego Lovison > Assignee: Diego Lovison > Priority: Minor > Fix For: 5.0.0.Alpha6 > > > As a developer I would like to know what is the local_address ( the value printed in the log ) and what will be the address sent over the network ( the value that will be captured by TShark ) > When running a benchmark in the perf lab we start running tshark after the initial load. In this case, in the tshark dump we won't have the PING request. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4949) Expose the original task in RequestController.QueuedTask

by Cheng Fang (Jira)

[ https://issues.redhat.com/browse/WFCORE-4949?page=com.atlassian.jira.plug... ] Cheng Fang updated WFCORE-4949: ------------------------------- Description: org.wildfly.extension.requestcontroller.RequestController.QueuedTask runRequest() method wraps the original task as a new Runnable, and pass it back to the caller's {{Executor}} for execution. In some cases, the original task has more state and behavior than a pure Runnable. When the new temporary Runnable is passed back to the caller's {{Executor}}, these additional features are no longer available. So we need a way to expose/unwrap the original task to the caller so that the caller's {{Executor}} can work properly. See https://github.com/wildfly/wildfly-core/blob/master/request-controller/sr... was: org.wildfly.extension.requestcontroller.RequestController.QueuedTask runRequest() method wraps the original task as a new Runnable, and pass it back to the caller's {{Executor}} for execution. In some cases, the original task has more state and behavior than a pure Runnable. When the new temporary Runnable is passed back to the caller's {{Executor}}, these additional features are no longer available. See https://github.com/wildfly/wildfly-core/blob/master/request-controller/sr... > Expose the original task in RequestController.QueuedTask > -------------------------------------------------------- > > Key: WFCORE-4949 > URL: https://issues.redhat.com/browse/WFCORE-4949 > Project: WildFly Core > Issue Type: Enhancement > Components: Server > Affects Versions: 12.0.0.Beta1 > Reporter: Cheng Fang > Assignee: Cheng Fang > Priority: Major > > org.wildfly.extension.requestcontroller.RequestController.QueuedTask runRequest() method wraps the original task as a new Runnable, and pass it back to the caller's {{Executor}} for execution. > In some cases, the original task has more state and behavior than a pure Runnable. When the new temporary Runnable is passed back to the caller's {{Executor}}, these additional features are no longer available. So we need a way to expose/unwrap the original task to the caller so that the caller's {{Executor}} can work properly. > See https://github.com/wildfly/wildfly-core/blob/master/request-controller/sr... -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4949) Expose the original task in RequestController.QueuedTask

by Cheng Fang (Jira)

[ https://issues.redhat.com/browse/WFCORE-4949?page=com.atlassian.jira.plug... ] Cheng Fang updated WFCORE-4949: ------------------------------- Description: org.wildfly.extension.requestcontroller.RequestController.QueuedTask runRequest() method wraps the original task as a new Runnable, and pass it back to the caller's {{Executor}} for execution. In some cases, the original task has more state and behavior than a pure Runnable. When the new temporary Runnable is passed back to the caller's {{Executor}}, these additional features are no longer available. See https://github.com/wildfly/wildfly-core/blob/master/request-controller/sr... > Expose the original task in RequestController.QueuedTask > -------------------------------------------------------- > > Key: WFCORE-4949 > URL: https://issues.redhat.com/browse/WFCORE-4949 > Project: WildFly Core > Issue Type: Enhancement > Components: Server > Affects Versions: 12.0.0.Beta1 > Reporter: Cheng Fang > Assignee: Cheng Fang > Priority: Major > > org.wildfly.extension.requestcontroller.RequestController.QueuedTask runRequest() method wraps the original task as a new Runnable, and pass it back to the caller's {{Executor}} for execution. > In some cases, the original task has more state and behavior than a pure Runnable. When the new temporary Runnable is passed back to the caller's {{Executor}}, these additional features are no longer available. > See https://github.com/wildfly/wildfly-core/blob/master/request-controller/sr... -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4949) Expose the original task in RequestController.QueuedTask

by Cheng Fang (Jira)

[ https://issues.redhat.com/browse/WFCORE-4949?page=com.atlassian.jira.plug... ] Cheng Fang reassigned WFCORE-4949: ---------------------------------- Assignee: Cheng Fang (was: Jeff Mesnil) > Expose the original task in RequestController.QueuedTask > -------------------------------------------------------- > > Key: WFCORE-4949 > URL: https://issues.redhat.com/browse/WFCORE-4949 > Project: WildFly Core > Issue Type: Enhancement > Components: Server > Affects Versions: 12.0.0.Beta1 > Reporter: Cheng Fang > Assignee: Cheng Fang > Priority: Major > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4949) Expose the original task in RequestController.QueuedTask

by Cheng Fang (Jira)

Cheng Fang created WFCORE-4949: ---------------------------------- Summary: Expose the original task in RequestController.QueuedTask Key: WFCORE-4949 URL: https://issues.redhat.com/browse/WFCORE-4949 Project: WildFly Core Issue Type: Enhancement Components: Server Affects Versions: 12.0.0.Beta1 Reporter: Cheng Fang Assignee: Jeff Mesnil -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13405) Update CommonDeploymentService in release.

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFLY-13405?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFLY-13405: ----------------------------------------- [~algolua7] [~jamezp] I fixed the specific issue here but I'm leaving this open as the presence of Slf4jLocationAwareLogger in the stack is not expected. James if you'd rather use a different issue for that please resolve this against 19.1.0.Final and 20.0.0.Beta1. > Update CommonDeploymentService in release. > ------------------------------------------ > > Key: WFLY-13405 > URL: https://issues.redhat.com/browse/WFLY-13405 > Project: WildFly > Issue Type: Bug > Components: JCA, Logging > Affects Versions: 19.0.0.Final > Reporter: Alexander Golovko > Assignee: James Perkins > Priority: Major > Attachments: debug.log > > > Current calls of ROOT_LOGGER.debugf("Started/Stopped CommonDeployment %s", new Object[0]); are errors. They raise MissingFormatArgumentException exception since new Object[0] is an empty array and is not compatible with %s in format argument. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13405) Update CommonDeploymentService in release.

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFLY-13405?page=com.atlassian.jira.plugi... ] Brian Stansberry reassigned WFLY-13405: --------------------------------------- Component/s: Logging Assignee: James Perkins (was: Brian Stansberry) > Update CommonDeploymentService in release. > ------------------------------------------ > > Key: WFLY-13405 > URL: https://issues.redhat.com/browse/WFLY-13405 > Project: WildFly > Issue Type: Bug > Components: JCA, Logging > Affects Versions: 19.0.0.Final > Reporter: Alexander Golovko > Assignee: James Perkins > Priority: Major > Attachments: debug.log > > > Current calls of ROOT_LOGGER.debugf("Started/Stopped CommonDeployment %s", new Object[0]); are errors. They raise MissingFormatArgumentException exception since new Object[0] is an empty array and is not compatible with %s in format argument. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4888) spring boot and drools integration occur path error and cannot load rule

by Xu Wang (Jira)

[ https://issues.redhat.com/browse/DROOLS-4888?page=com.atlassian.jira.plug... ] Xu Wang edited comment on DROOLS-4888 at 4/28/20 8:36 PM: ---------------------------------------------------------- In version 7.36.1.Final, I am facing the same issue after packaging the spring boot application. java -jar ... "o.d.c.kie.builder.impl.KieProject : No files found for KieBase" Could anyone let me know which version does not have the issue? Thanks! was (Author: wx8543372-1): In version 7.36.1.Final, I am facing the same issue after packaging the spring boot application. "o.d.c.kie.builder.impl.KieProject : No files found for KieBase" Could anyone let me know which version does not have the issue? Thanks! > spring boot and drools integration occur path error and cannot load rule > ------------------------------------------------------------------------ > > Key: DROOLS-4888 > URL: https://issues.redhat.com/browse/DROOLS-4888 > Project: Drools > Issue Type: Bug > Components: docs, integration > Affects Versions: 7.30.0.Final > Reporter: 韩济蓬 > Assignee: Mario Fusco > Priority: Major > Attachments: screenshot-1.png, springdrools.zip > > > I'm trying to run drools 7.30.0.Final with Spring Boot 2.2.2.RELEASE.I configured drools as the documentation says. My drools-config.xml configuration file is where I keep the drools beans and looks like this: > {code:xml} > <?xml version="1.0" encoding="UTF-8"?> > <beans xmlns="http://www.springframework.org/schema/beans" > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > xmlns:kie="http://drools.org/schema/kie-spring" > xsi:schemaLocation="http://www.springframework.org/schema/beans https://www.springframework.org/schema/beans/spring-beans.xsd http://drools.org/schema/kie-spring http://drools.org/schema/kie-spring.xsd"> > <kie:kmodule id="sample_module"> > <kie:kbase name="testRules" packages="rules" declarativeAgenda="true"> > <kie:ksession name="ksession1" type="stateless"/> > <kie:ksession name="ksession2" scope="prototype"> > <kie:ruleRuntimeEventListener ref="mockRuleRuntimeEventListener" /> > <kie:consoleLogger /> > </kie:ksession> > </kie:kbase> > </kie:kmodule> >  >  > <bean class="org.kie.spring.annotations.KModuleAnnotationPostProcessor"/> > </beans> > {code} > occur a warn looks: > 2019-12-19 14:44:25.231 WARN 9916 --- [ main] o.d.c.kie.builder.impl.KieProject : No files found for KieBase testRules > when i try debug org.kie.spring.KModuleBeanFactoryPostProcessor. Trace to ZipKieModule at line 133. cannot uncompress,get variable urlPath value is "/BOOT-INF/classes" jarFile values is "\Users\user\Desktop\springdrools\target\spring-drools-1.0.jar!\BOOT-INF\classes". lead to cannot load resource. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4888) spring boot and drools integration occur path error and cannot load rule

by Xu Wang (Jira)

[ https://issues.redhat.com/browse/DROOLS-4888?page=com.atlassian.jira.plug... ] Xu Wang commented on DROOLS-4888: --------------------------------- In version 7.36.1.Final, I am facing the same issue after packaging the spring boot application. "o.d.c.kie.builder.impl.KieProject : No files found for KieBase" Could anyone let me know which version does not have the issue? Thanks! > spring boot and drools integration occur path error and cannot load rule > ------------------------------------------------------------------------ > > Key: DROOLS-4888 > URL: https://issues.redhat.com/browse/DROOLS-4888 > Project: Drools > Issue Type: Bug > Components: docs, integration > Affects Versions: 7.30.0.Final > Reporter: 韩济蓬 > Assignee: Mario Fusco > Priority: Major > Attachments: screenshot-1.png, springdrools.zip > > > I'm trying to run drools 7.30.0.Final with Spring Boot 2.2.2.RELEASE.I configured drools as the documentation says. My drools-config.xml configuration file is where I keep the drools beans and looks like this: > {code:xml} > <?xml version="1.0" encoding="UTF-8"?> > <beans xmlns="http://www.springframework.org/schema/beans" > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > xmlns:kie="http://drools.org/schema/kie-spring" > xsi:schemaLocation="http://www.springframework.org/schema/beans https://www.springframework.org/schema/beans/spring-beans.xsd http://drools.org/schema/kie-spring http://drools.org/schema/kie-spring.xsd"> > <kie:kmodule id="sample_module"> > <kie:kbase name="testRules" packages="rules" declarativeAgenda="true"> > <kie:ksession name="ksession1" type="stateless"/> > <kie:ksession name="ksession2" scope="prototype"> > <kie:ruleRuntimeEventListener ref="mockRuleRuntimeEventListener" /> > <kie:consoleLogger /> > </kie:ksession> > </kie:kbase> > </kie:kmodule> >  >  > <bean class="org.kie.spring.annotations.KModuleAnnotationPostProcessor"/> > </beans> > {code} > occur a warn looks: > 2019-12-19 14:44:25.231 WARN 9916 --- [ main] o.d.c.kie.builder.impl.KieProject : No files found for KieBase testRules > when i try debug org.kie.spring.KModuleBeanFactoryPostProcessor. Trace to ZipKieModule at line 133. cannot uncompress,get variable urlPath value is "/BOOT-INF/classes" jarFile values is "\Users\user\Desktop\springdrools\target\spring-drools-1.0.jar!\BOOT-INF\classes". lead to cannot load resource. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13357) (Regression) Execution of concurrent batch jobs containg partitioned steps causes deadlock

by Cheng Fang (Jira)

[ https://issues.redhat.com/browse/WFLY-13357?page=com.atlassian.jira.plugi... ] Cheng Fang updated WFLY-13357: ------------------------------ Fix Version/s: 20.0.0.Beta1 > (Regression) Execution of concurrent batch jobs containg partitioned steps causes deadlock > ------------------------------------------------------------------------------------------ > > Key: WFLY-13357 > URL: https://issues.redhat.com/browse/WFLY-13357 > Project: WildFly > Issue Type: Bug > Components: Batch > Affects Versions: 19.0.0.Final > Reporter: Felix König > Assignee: Cheng Fang > Priority: Major > Fix For: 20.0.0.Beta1 > > > Hello, > the issue described in JBERET-180 seems to have reappeared. I am running Wildfly 16 with jberet-1.3.3. Given that there is a default batch-thread count of 10 I was able to produce a deadlock by starting 10 instances of a partitioned job simultaneously. None of the job runs fast enough to finish before all 10 jobs have been started. All 10 Batch-threads are stuck here: > {code} > "Batch Thread - 1@33537" prio=5 tid=0x109 nid=NA waiting > java.lang.Thread.State: WAITING > at jdk.internal.misc.Unsafe.park(Unknown Source:-1) > at java.util.concurrent.locks.LockSupport.park(Unknown Source:-1) > at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(Unknown Source:-1) > at java.util.concurrent.ArrayBlockingQueue.take(Unknown Source:-1) > at org.jberet.runtime.runner.StepExecutionRunner.beginPartition(StepExecutionRunner.java:350) > at org.jberet.runtime.runner.StepExecutionRunner.runBatchletOrChunk(StepExecutionRunner.java:222) > at org.jberet.runtime.runner.StepExecutionRunner.run(StepExecutionRunner.java:144) > at org.jberet.runtime.runner.CompositeExecutionRunner.runStep(CompositeExecutionRunner.java:164) > at org.jberet.runtime.runner.CompositeExecutionRunner.runFromHeadOrRestartPoint(CompositeExecutionRunner.java:88) > at org.jberet.runtime.runner.JobExecutionRunner.run(JobExecutionRunner.java:60) > at org.wildfly.extension.batch.jberet.deployment.BatchEnvironmentService$WildFlyBatchEnvironment$1.run(BatchEnvironmentService.java:180) > at org.wildfly.extension.requestcontroller.RequestController$QueuedTask$1.run(RequestController.java:494) > at org.jberet.spi.JobExecutor$2.run(JobExecutor.java:149) > at org.jberet.spi.JobExecutor$1.run(JobExecutor.java:99) > at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source:-1) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source:-1) > at java.lang.Thread.run(Unknown Source:-1) > at org.jboss.threads.JBossThread.run(JBossThread.java:485) > {code} > which is this line of code: > {code:java} > completedPartitionThreads.take(); > {code} > Rarely some threads also get stuck at line 364 instead, which is > {code:java} > final Serializable data = collectorDataQueue.take(); > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira April 2020