[JBoss JIRA] (DROOLS-501) jBPM Ruleflow groups ignore no-loops when nodes are shared
by Davide Sottara (JIRA)
Davide Sottara created DROOLS-501:
-------------------------------------
Summary: jBPM Ruleflow groups ignore no-loops when nodes are shared
Key: DROOLS-501
URL: https://issues.jboss.org/browse/DROOLS-501
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 6.1.0.Beta4
Reporter: Davide Sottara
Assignee: Mark Proctor
Priority: Critical
Fix For: 6.1.0.CR1
The following rules
{code}
package org.drools.compiler.loop
rule "Rule 1"
ruleflow-group "Start"
no-loop
when
$thing1 : String()
$thing2 : Integer()
then
System.out.println( 'At 1' );
update( $thing2 );
end
rule "Rule 2"
ruleflow-group "End"
no-loop
when
$thing1 : String()
$thing2 : Integer()
then
System.out.println( 'At 2' );
update( $thing2 );
end
{code}
cause an endless loop even if controlled by a jBPM process with two rule tasks
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 7 months
[JBoss JIRA] (WFLY-3396) NPE in TimerResourceDefinition
by Serge Mürset (JIRA)
[ https://issues.jboss.org/browse/WFLY-3396?page=com.atlassian.jira.plugin.... ]
Serge Mürset updated WFLY-3396:
-------------------------------
Description:
I am experiencing race conditions when running test remotely from Arquillian to Wildfly 8.1.0.CR2. In 2 of 3 Cases i get a NPE in Wildfly in relation to one of my own scheduled EJB.
Stacktrace:
{code}
10:08:56,169 INFO [org.jboss.as.server] (management-handler-thread - 1) JBAS018559: Deployed "core-dist-0.6.ear" (runtime-name : "core-dist-0.6.ear")
10:08:58,102 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 2) JBAS014612: Operation ("read-attribute") failed - address: ([
("deployment" => "core-dist-0.6.ear"),
("subdeployment" => "core.jar"),
("subsystem" => "ejb3"),
("singleton-bean" => "FileDeploymentScanner"),
("service" => "timer-service"),
("timer" => "53ca8249-b0a1-42ab-810b-abad39cb3d19")
]): java.lang.NullPointerException
at org.jboss.as.ejb3.subsystem.deployment.TimerResourceDefinition$10.readAttribute(TimerResourceDefinition.java:268)
at org.jboss.as.ejb3.subsystem.deployment.TimerResourceDefinition$AbstractReadAttributeHandler.executeRuntime(TimerResourceDefinition.java:364)
at org.jboss.as.ejb3.subsystem.deployment.TimerResourceDefinition$AbstractTimerHandler$1.execute(TimerResourceDefinition.java:330)
at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:606) [wildfly-controller-8.1.0.CR2.jar:8.1.0.CR2]
at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:484) [wildfly-controller-8.1.0.CR2.jar:8.1.0.CR2]
at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:281) [wildfly-controller-8.1.0.CR2.jar:8.1.0.CR2]
at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:276) [wildfly-controller-8.1.0.CR2.jar:8.1.0.CR2]
at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:271) [wildfly-controller-8.1.0.CR2.jar:8.1.0.CR2]
at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:145) [wildfly-controller-8.1.0.CR2.jar:8.1.0.CR2]
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:199) [wildfly-controller-8.1.0.CR2.jar:8.1.0.CR2]
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:130) [wildfly-controller-8.1.0.CR2.jar:8.1.0.CR2]
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:150) [wildfly-controller-8.1.0.CR2.jar:8.1.0.CR2]
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:146) [wildfly-controller-8.1.0.CR2.jar:8.1.0.CR2]
at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_55]
at javax.security.auth.Subject.doAs(Subject.java:415) [rt.jar:1.7.0_55]
at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:94) [wildfly-controller-8.1.0.CR2.jar:8.1.0.CR2]
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:146) [wildfly-controller-8.1.0.CR2.jar:8.1.0.CR2]
at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:283) [wildfly-protocol-8.1.0.CR2.jar:8.1.0.CR2]
at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:504) [wildfly-protocol-8.1.0.CR2.jar:8.1.0.CR2]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_55]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_55]
at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_55]
at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
{code}
The arquillian test prints:
{code}
com.ieffects.core.integration.ImportTest STANDARD_ERROR
May 23, 2014 10:08:49 AM org.xnio.Xnio <clinit>
INFO: XNIO version 3.2.2.Final
May 23, 2014 10:08:49 AM org.xnio.nio.NioXnio <clinit>
INFO: XNIO NIO Implementation Version 3.2.2.Final
May 23, 2014 10:08:49 AM org.jboss.remoting3.EndpointImpl <clinit>
INFO: JBoss Remoting version 4.0.3.Final
May 23, 2014 10:08:58 AM org.jboss.as.arquillian.container.ManagementClient checkSuccessful
ERROR: Operation {
"operation" => "read-resource",
"recursive" => "true",
"address" => undefined
} did not succeed. Result was {
"outcome" => "failed",
"result" => {
"management-major-version" => 2,
"management-micro-version" => 0,
"management-minor-version" => 1,
"name" => "cust",
"namespaces" => [],
"product-name" => undefined,
"product-version" => undefined,
"profile-name" => undefined,
"release-codename" => "Kenny",
"release-version" => "8.1.0.CR2",
"schema-locations" => [],
"core-service" => {
"management" => {
"access" => {
"authorization" => {
... the complete wildfly configuration...
},
"rolled-back" => true
}
{code}
My scheduled Service FileDeploymentScanner is somewhat special, it schedules the times itself (No Schedule annotation. Simplified it looks like this:
{code}
@ConcurrencyManagement(ConcurrencyManagementType.BEAN)
@Singleton
@Startup
@TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED)
public class FileDeploymentScanner {
@Resource
private TimerService _timerService;
/**
* Scans and deploys files according to configuration.
*/
@Timeout
public void handleClick() {
System.out.println("handle click");
}
/**
* Initializes the service.
*/
@PostConstruct
public void startup() {
System.out.println("Starting timer service");
_timerService.createSingleActionTimer(10000, new TimerConfig("FileDeploymentScanner", false));
try {
Thread.sleep(10000);
} catch (InterruptedException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
System.out.println("Started timer service");
}
}
{code}
What is happening, is, the arquillian client apparently tries to read complete wildfly configuration (dont know why), and during this step it fails to do so. I failed to write reproducer ear/app. I can't release my closed source though which produces this error. But hopefully, this NPE is easy to fix.
was:
I am experiencing race conditions when running test remotely from Arquillian to Wildfly 8.1.0.CR2. In 2 of 3 Cases i get a NPE in Wildfly in relation to some TimerService EJB.
Stacktrace:
{code}
10:08:56,169 INFO [org.jboss.as.server] (management-handler-thread - 1) JBAS018559: Deployed "core-dist-0.6.ear" (runtime-name : "core-dist-0.6.ear")
10:08:58,102 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 2) JBAS014612: Operation ("read-attribute") failed - address: ([
("deployment" => "core-dist-0.6.ear"),
("subdeployment" => "core.jar"),
("subsystem" => "ejb3"),
("singleton-bean" => "FileDeploymentScanner"),
("service" => "timer-service"),
("timer" => "53ca8249-b0a1-42ab-810b-abad39cb3d19")
]): java.lang.NullPointerException
at org.jboss.as.ejb3.subsystem.deployment.TimerResourceDefinition$10.readAttribute(TimerResourceDefinition.java:268)
at org.jboss.as.ejb3.subsystem.deployment.TimerResourceDefinition$AbstractReadAttributeHandler.executeRuntime(TimerResourceDefinition.java:364)
at org.jboss.as.ejb3.subsystem.deployment.TimerResourceDefinition$AbstractTimerHandler$1.execute(TimerResourceDefinition.java:330)
at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:606) [wildfly-controller-8.1.0.CR2.jar:8.1.0.CR2]
at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:484) [wildfly-controller-8.1.0.CR2.jar:8.1.0.CR2]
at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:281) [wildfly-controller-8.1.0.CR2.jar:8.1.0.CR2]
at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:276) [wildfly-controller-8.1.0.CR2.jar:8.1.0.CR2]
at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:271) [wildfly-controller-8.1.0.CR2.jar:8.1.0.CR2]
at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:145) [wildfly-controller-8.1.0.CR2.jar:8.1.0.CR2]
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:199) [wildfly-controller-8.1.0.CR2.jar:8.1.0.CR2]
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:130) [wildfly-controller-8.1.0.CR2.jar:8.1.0.CR2]
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:150) [wildfly-controller-8.1.0.CR2.jar:8.1.0.CR2]
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:146) [wildfly-controller-8.1.0.CR2.jar:8.1.0.CR2]
at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_55]
at javax.security.auth.Subject.doAs(Subject.java:415) [rt.jar:1.7.0_55]
at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:94) [wildfly-controller-8.1.0.CR2.jar:8.1.0.CR2]
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:146) [wildfly-controller-8.1.0.CR2.jar:8.1.0.CR2]
at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:283) [wildfly-protocol-8.1.0.CR2.jar:8.1.0.CR2]
at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:504) [wildfly-protocol-8.1.0.CR2.jar:8.1.0.CR2]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_55]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_55]
at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_55]
at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
{code}
The arquillian test prints:
{code}
com.ieffects.core.integration.ImportTest STANDARD_ERROR
May 23, 2014 10:08:49 AM org.xnio.Xnio <clinit>
INFO: XNIO version 3.2.2.Final
May 23, 2014 10:08:49 AM org.xnio.nio.NioXnio <clinit>
INFO: XNIO NIO Implementation Version 3.2.2.Final
May 23, 2014 10:08:49 AM org.jboss.remoting3.EndpointImpl <clinit>
INFO: JBoss Remoting version 4.0.3.Final
May 23, 2014 10:08:58 AM org.jboss.as.arquillian.container.ManagementClient checkSuccessful
ERROR: Operation {
"operation" => "read-resource",
"recursive" => "true",
"address" => undefined
} did not succeed. Result was {
"outcome" => "failed",
"result" => {
"management-major-version" => 2,
"management-micro-version" => 0,
"management-minor-version" => 1,
"name" => "cust",
"namespaces" => [],
"product-name" => undefined,
"product-version" => undefined,
"profile-name" => undefined,
"release-codename" => "Kenny",
"release-version" => "8.1.0.CR2",
"schema-locations" => [],
"core-service" => {
"management" => {
"access" => {
"authorization" => {
... the complete wildfly configuration...
},
"rolled-back" => true
}
{code}
The TimerService is somewhat special, it schedules the times itself (No Schedule annotation. Simplified it looks like this:
{code}
@ConcurrencyManagement(ConcurrencyManagementType.BEAN)
@Singleton
@Startup
@TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED)
public class MyTimerService {
@Resource
private TimerService _timerService;
/**
* Scans and deploys files according to configuration.
*/
@Timeout
public void handleClick() {
System.out.println("handle click");
}
/**
* Initializes the service.
*/
@PostConstruct
public void startup() {
System.out.println("Starting timer service");
_timerService.createSingleActionTimer(10000, new TimerConfig("FileDeploymentScanner", false));
try {
Thread.sleep(10000);
} catch (InterruptedException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
System.out.println("Started timer service");
}
}
{code}
What is happening, is, the arquillian client apparently tries to read complete wildfly configuration (dont know why), and during this step it fails to do so. I failed to write reproducer ear/app. I can't release my closed source though which produces this error. But hopefully, this NPE is easy to fix.
> NPE in TimerResourceDefinition
> ------------------------------
>
> Key: WFLY-3396
> URL: https://issues.jboss.org/browse/WFLY-3396
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: EJB
> Affects Versions: 8.1.0.CR2
> Environment: JDK 1.7.0_55
> MacOSX
> PostgreSQL 9.1
> Wildfly 8.1.0.CR2
> Arquillian 1.1.2.Final-wildfly-1
> arquillian-protocol-servlet 1.1.2.Final-wildfly-1
> wildfly-arquillian-container-remote 8.1.0.CR2
> Reporter: Serge Mürset
> Assignee: Stuart Douglas
> Labels: race-condition, wildfly
>
> I am experiencing race conditions when running test remotely from Arquillian to Wildfly 8.1.0.CR2. In 2 of 3 Cases i get a NPE in Wildfly in relation to one of my own scheduled EJB.
> Stacktrace:
> {code}
> 10:08:56,169 INFO [org.jboss.as.server] (management-handler-thread - 1) JBAS018559: Deployed "core-dist-0.6.ear" (runtime-name : "core-dist-0.6.ear")
> 10:08:58,102 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 2) JBAS014612: Operation ("read-attribute") failed - address: ([
> ("deployment" => "core-dist-0.6.ear"),
> ("subdeployment" => "core.jar"),
> ("subsystem" => "ejb3"),
> ("singleton-bean" => "FileDeploymentScanner"),
> ("service" => "timer-service"),
> ("timer" => "53ca8249-b0a1-42ab-810b-abad39cb3d19")
> ]): java.lang.NullPointerException
> at org.jboss.as.ejb3.subsystem.deployment.TimerResourceDefinition$10.readAttribute(TimerResourceDefinition.java:268)
> at org.jboss.as.ejb3.subsystem.deployment.TimerResourceDefinition$AbstractReadAttributeHandler.executeRuntime(TimerResourceDefinition.java:364)
> at org.jboss.as.ejb3.subsystem.deployment.TimerResourceDefinition$AbstractTimerHandler$1.execute(TimerResourceDefinition.java:330)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:606) [wildfly-controller-8.1.0.CR2.jar:8.1.0.CR2]
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:484) [wildfly-controller-8.1.0.CR2.jar:8.1.0.CR2]
> at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:281) [wildfly-controller-8.1.0.CR2.jar:8.1.0.CR2]
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:276) [wildfly-controller-8.1.0.CR2.jar:8.1.0.CR2]
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:271) [wildfly-controller-8.1.0.CR2.jar:8.1.0.CR2]
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:145) [wildfly-controller-8.1.0.CR2.jar:8.1.0.CR2]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:199) [wildfly-controller-8.1.0.CR2.jar:8.1.0.CR2]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:130) [wildfly-controller-8.1.0.CR2.jar:8.1.0.CR2]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:150) [wildfly-controller-8.1.0.CR2.jar:8.1.0.CR2]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:146) [wildfly-controller-8.1.0.CR2.jar:8.1.0.CR2]
> at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_55]
> at javax.security.auth.Subject.doAs(Subject.java:415) [rt.jar:1.7.0_55]
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:94) [wildfly-controller-8.1.0.CR2.jar:8.1.0.CR2]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:146) [wildfly-controller-8.1.0.CR2.jar:8.1.0.CR2]
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:283) [wildfly-protocol-8.1.0.CR2.jar:8.1.0.CR2]
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:504) [wildfly-protocol-8.1.0.CR2.jar:8.1.0.CR2]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_55]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_55]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_55]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> {code}
> The arquillian test prints:
> {code}
> com.ieffects.core.integration.ImportTest STANDARD_ERROR
> May 23, 2014 10:08:49 AM org.xnio.Xnio <clinit>
> INFO: XNIO version 3.2.2.Final
> May 23, 2014 10:08:49 AM org.xnio.nio.NioXnio <clinit>
> INFO: XNIO NIO Implementation Version 3.2.2.Final
> May 23, 2014 10:08:49 AM org.jboss.remoting3.EndpointImpl <clinit>
> INFO: JBoss Remoting version 4.0.3.Final
> May 23, 2014 10:08:58 AM org.jboss.as.arquillian.container.ManagementClient checkSuccessful
> ERROR: Operation {
> "operation" => "read-resource",
> "recursive" => "true",
> "address" => undefined
> } did not succeed. Result was {
> "outcome" => "failed",
> "result" => {
> "management-major-version" => 2,
> "management-micro-version" => 0,
> "management-minor-version" => 1,
> "name" => "cust",
> "namespaces" => [],
> "product-name" => undefined,
> "product-version" => undefined,
> "profile-name" => undefined,
> "release-codename" => "Kenny",
> "release-version" => "8.1.0.CR2",
> "schema-locations" => [],
> "core-service" => {
> "management" => {
> "access" => {
> "authorization" => {
> ... the complete wildfly configuration...
> },
> "rolled-back" => true
> }
> {code}
> My scheduled Service FileDeploymentScanner is somewhat special, it schedules the times itself (No Schedule annotation. Simplified it looks like this:
> {code}
> @ConcurrencyManagement(ConcurrencyManagementType.BEAN)
> @Singleton
> @Startup
> @TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED)
> public class FileDeploymentScanner {
> @Resource
> private TimerService _timerService;
> /**
> * Scans and deploys files according to configuration.
> */
> @Timeout
> public void handleClick() {
> System.out.println("handle click");
> }
> /**
> * Initializes the service.
> */
> @PostConstruct
> public void startup() {
> System.out.println("Starting timer service");
> _timerService.createSingleActionTimer(10000, new TimerConfig("FileDeploymentScanner", false));
> try {
> Thread.sleep(10000);
> } catch (InterruptedException e) {
> // TODO Auto-generated catch block
> e.printStackTrace();
> }
> System.out.println("Started timer service");
> }
> }
> {code}
> What is happening, is, the arquillian client apparently tries to read complete wildfly configuration (dont know why), and during this step it fails to do so. I failed to write reproducer ear/app. I can't release my closed source though which produces this error. But hopefully, this NPE is easy to fix.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 7 months
[JBoss JIRA] (JGRP-1843) Look harder for SASL factories
by Tristan Tarrant (JIRA)
Tristan Tarrant created JGRP-1843:
-------------------------------------
Summary: Look harder for SASL factories
Key: JGRP-1843
URL: https://issues.jboss.org/browse/JGRP-1843
Project: JGroups
Issue Type: Enhancement
Reporter: Tristan Tarrant
Assignee: Tristan Tarrant
If jboss-sasl is in the classpath we want to also discover and expose its factories
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 7 months
[JBoss JIRA] (JGRP-1832) Update McastSenderTest/McastReceiverTest to bind the multicast sockets the same as JGroups
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1832?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1832:
---------------------------
Priority: Optional (was: Major)
> Update McastSenderTest/McastReceiverTest to bind the multicast sockets the same as JGroups
> ------------------------------------------------------------------------------------------
>
> Key: JGRP-1832
> URL: https://issues.jboss.org/browse/JGRP-1832
> Project: JGroups
> Issue Type: Feature Request
> Affects Versions: 3.4.3
> Reporter: Dennis Reed
> Assignee: Dennis Reed
> Priority: Optional
> Fix For: 3.4.5, 3.5
>
>
> JGroups binds multicast sockets using specific MulticastSocket constructors depending on the operating system (to avoid crosstalk issues).
> McastSenderTest and McastReceiverTest always bind the socket using the basic MulticastSocket(port) constructor.
> In order to more closely test the way JGroups will be sending and receiving the packets, these tests will be updated to bind the sockets the same way.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 7 months
[JBoss JIRA] (JGRP-1842) ForkChannel.getFORK(...) is not thread-safe
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1842?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-1842.
----------------------------
Resolution: Done
Synchronized fetching and creation of FORK. Ditto for the protocol stack
> ForkChannel.getFORK(...) is not thread-safe
> -------------------------------------------
>
> Key: JGRP-1842
> URL: https://issues.jboss.org/browse/JGRP-1842
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.4.4
> Reporter: Paul Ferraro
> Assignee: Bela Ban
> Fix For: 3.4.5, 3.5
>
>
> If multiple concurrent threads attempt to create a ForkChannel using the same fork stack, and the flag is enabled that attempts to create the FORK protocol if missing - the FORK protocol can inadvertently insert multiple times. There needs to be some thread synchronization between the findProtocol(FORK.class) and protocol creation/insertion.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 7 months
[JBoss JIRA] (WFLY-3369) Performance issue of jaxws-client on JDK 1.7.0_55
by Zhang Boya (JIRA)
[ https://issues.jboss.org/browse/WFLY-3369?page=com.atlassian.jira.plugin.... ]
Zhang Boya commented on WFLY-3369:
----------------------------------
Q1: The performance of JAX-WS invocation declined obviously on Solaris.
Q2:
- Deploy one JAX-WS on web application server, this WS needs authorization. Please don't care about the the type of operation system and the type of web application server. It can be Linux/Solaris and Tomcat/Weblogic/JBoss. The issue occurred on JAX-WS client side.
- The WSDL of this JAX-WS can be access by browser or SOAP UI. Make sure this service can be access by SOAP UI. Then to generate the WS client codes through WSDL.
- Write one simple class using Java, this class only provides main method, you can refer the codes what I have described on steps to reproduce. This main method consist of two parts. Firstly, to initialize the web service client and web service endpoint, then write a for loop of 100 times, to invoke the remote JAX-WS 100 times, and calculate average response time.
- Run this class using JDK_1.7.0_25_Solaris_64 and JDK_1.7.0_55_Solaris_64, to compare the response time.
Q3: Of course. Warm up is mandatory and necessary for our performance test.
> Performance issue of jaxws-client on JDK 1.7.0_55
> -------------------------------------------------
>
> Key: WFLY-3369
> URL: https://issues.jboss.org/browse/WFLY-3369
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web Services
> Affects Versions: JBoss AS7 7.1.1.Final
> Environment: Red Hat Enterprise 6.4, Solaris 10, JBoss AS 7.1.3
> Reporter: Zhang Boya
> Assignee: Jim Ma
>
> Assume that a JAX-WS deploys on somewhere else, developer generates the JAX-WS client side classes by using wsdl2java tools. These classes have been exported as 'exmaple-ws-client.jar'. When developer needs to access this JAX-WS in their web application, this JAR file would be published with WAR file together. By default, the JBoss AS would supply an instance of CXF's implementation for the JAX-WS client when web application be deployed to JBoss AS. The class name of this JAX-WS client would be 'org.apache.cxf.jaxws.JaxWsClientProxy'. The JAX-WS invocations of client side got a very bad performance since I upgraded JDK from 1.7.0_25 to 1.7.0_55, especially on Solaris.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 7 months
[JBoss JIRA] (WFLY-3393) JSP 2 different tags called with same tag instance
by roy mizrachi (JIRA)
[ https://issues.jboss.org/browse/WFLY-3393?page=com.atlassian.jira.plugin.... ]
roy mizrachi commented on WFLY-3393:
------------------------------------
Hi Again,
I can see that the void release(); of javax.servlet.jsp.tagext.Tag is not called.
This is causing the problem of sharing the same data in 2 different tags.
The release should be called to clear the data.
Thanks,
Roi Mizrachi
> JSP 2 different tags called with same tag instance
> --------------------------------------------------
>
> Key: WFLY-3393
> URL: https://issues.jboss.org/browse/WFLY-3393
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Affects Versions: 8.1.0.CR2
> Reporter: roy mizrachi
> Assignee: Stuart Douglas
>
> When working with JSP tags on struts i can see that sometimes 2 diffrent tags with same type is called with the same instance.
> Example:
> JSP
> <jcv:text id="email" maxlength="255" property="valueObject.Email"/>
> <br>
> <jcv:text id="phone" maxlength="255" property="valueObject.Phone"/>
> TLD
> <tag>
> <name>text</name>
> <tagclass>tti.jcore.views.form.tag.JViewsTextTag</tagclass>
> ...
> </tag>
> I can see that the public int doStartTag() called for both with the same instance.
>
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 7 months
[JBoss JIRA] (WFLY-3401) EJB StatefulTimeoutTestCase fails occasionally in CI environment
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-3401?page=com.atlassian.jira.plugin.... ]
Paul Ferraro updated WFLY-3401:
-------------------------------
Summary: EJB StatefulTimeoutTestCase fails occasionally in CI environment (was: StatefulTimeoutTestCase fails occasionally in CI environment)
> EJB StatefulTimeoutTestCase fails occasionally in CI environment
> ----------------------------------------------------------------
>
> Key: WFLY-3401
> URL: https://issues.jboss.org/browse/WFLY-3401
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Clustering
> Affects Versions: 8.1.0.CR2
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
>
> Probably a timing issue in the test.
> http://brontes.lab.eng.brq.redhat.com/viewLog.html?buildId=15982&buildTyp...
> {noformat}
> java.lang.AssertionError: expected:<0> but was:<2>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:743)
> at org.junit.Assert.assertEquals(Assert.java:118)
> at org.junit.Assert.assertEquals(Assert.java:555)
> at org.junit.Assert.assertEquals(Assert.java:542)
> at org.jboss.as.test.clustering.cluster.ejb.stateful.StatefulTimeoutTestCase.timeout(StatefulTimeoutTestCase.java:119)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 7 months
[JBoss JIRA] (WFLY-3401) StatefulTimeoutTestCase fails occasionally in CI environment
by Paul Ferraro (JIRA)
Paul Ferraro created WFLY-3401:
----------------------------------
Summary: StatefulTimeoutTestCase fails occasionally in CI environment
Key: WFLY-3401
URL: https://issues.jboss.org/browse/WFLY-3401
Project: WildFly
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Clustering
Affects Versions: 8.1.0.CR2
Reporter: Paul Ferraro
Assignee: Paul Ferraro
Probably a timing issue in the test.
http://brontes.lab.eng.brq.redhat.com/viewLog.html?buildId=15982&buildTyp...
{noformat}
java.lang.AssertionError: expected:<0> but was:<2>
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:743)
at org.junit.Assert.assertEquals(Assert.java:118)
at org.junit.Assert.assertEquals(Assert.java:555)
at org.junit.Assert.assertEquals(Assert.java:542)
at org.jboss.as.test.clustering.cluster.ejb.stateful.StatefulTimeoutTestCase.timeout(StatefulTimeoutTestCase.java:119)
{noformat}
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 7 months