[JBoss JIRA] (DROOLS-1046) Threads blocking during ReteWorkingMemory initialization of facts
by Akshay Gehi (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1046?page=com.atlassian.jira.plugi... ]
Akshay Gehi commented on DROOLS-1046:
-------------------------------------
Hi,
One of the test cases had failed but it may not be related to this change. Do you think it would be safe to check this change in our codebase locally?
> Threads blocking during ReteWorkingMemory initialization of facts
> -----------------------------------------------------------------
>
> Key: DROOLS-1046
> URL: https://issues.jboss.org/browse/DROOLS-1046
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.3.0.Final
> Reporter: Akshay Gehi
> Assignee: Mario Fusco
>
> While initializing facts for the first time the following method in ReteWorkingMemory is invoked:
> {code:java}
> private final Integer syncLock = 42;
> public void initInitialFact() {
> if ( initialFactHandle == null ) {
> synchronized ( syncLock ) {
> if ( initialFactHandle == null ) {
> // double check, inside of sync point incase some other thread beat us to it.
> initInitialFact(kBase, null);
> }
> }
> }
> }
> {code}
> Since the synchronized lock is taken on a Integer constant variable, the same object gets used across different threads. This causes the initialization of all the ReteMemoryObjects to wait in the initInitialFact() method across different threads.
> The lock should be taken on Object lock = new Object() instead
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFLY-5682) Can't define absolute path for object store location
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/WFLY-5682?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated WFLY-5682:
--------------------------------
Fix Version/s: 10.0.0.Final
> Can't define absolute path for object store location
> ----------------------------------------------------
>
> Key: WFLY-5682
> URL: https://issues.jboss.org/browse/WFLY-5682
> Project: WildFly
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 10.0.0.CR4
> Reporter: Ondřej Chaloupka
> Assignee: Amos Feng
> Fix For: 10.0.0.Final
>
>
> As trying to set absolute path for location of transaction log store I've got to suspicion that's not possible.
> If I try to set `object-store-relative-to` to some absolute path or set `object-store-relative-to` to empty string and then `object-store-path` to some absolute path the server starts with exceptions [1][2].
> [1]
> {code}
> ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC000001: Failed to start service jboss.txn.ArjunaObjectStoreEnvironment: org.jboss.msc.service.StartException in service jboss.txn.ArjunaObjectStoreEnvironment: Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) 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)Caused by: java.lang.IllegalArgumentException: WFLYCTL0256: Could not find a path called '/home/ochaloup/tmp/'
> at org.jboss.as.controller.services.path.PathManagerService.resolveRelativePathEntry(PathManagerService.java:87) at org.jboss.as.txn.service.ArjunaObjectStoreEnvironmentService.start(ArjunaObjectStoreEnvironmentService.java:76)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> ...
> ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([("subsystem" => "transactions")]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.txn.ArjunaObjectStoreEnvironment" => "org.jboss.msc.service.StartException in service jboss.txn.ArjunaObjectStoreEnvironment: Failed to start service
> Caused by: java.lang.IllegalArgumentException: WFLYCTL0256: Could not find a path called '/home/ochaloup/tmp/'"}}
> INFO [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0183: Service status reportWFLYCTL0186: Services which failed to start: service jboss.txn.ArjunaObjectStoreEnvironment: org.jboss.msc.service.StartException in service jboss.txn.ArjunaObjectStoreEnvironment: Failed to start service
> {code}
> [2]
> {code}
> ERROR [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0055: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: WFLYCTL0085: Failed to parse configuration
> at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:131)
> at org.jboss.as.server.ServerService.boot(ServerService.java:356) at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:299)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[348,13]
> Message: "WFLYCTL0113: '' is an invalid value for parameter relative-to. Values must have a minimum length of 1 characters"
> at org.jboss.as.controller.SimpleAttributeDefinition.parse(SimpleAttributeDefinition.java:161) at org.jboss.as.controller.SimpleAttributeDefinition.parseAndSetParameter(SimpleAttributeDefinition.java:186)
> at org.jboss.as.txn.subsystem.TransactionSubsystem14Parser.parseObjectStoreEnvironmentElementAndEnrichOperation(TransactionSubsystem14Parser.java:205)
> at org.jboss.as.txn.subsystem.TransactionSubsystem30Parser.readElement(TransactionSubsystem30Parser.java:67) at org.jboss.as.txn.subsystem.TransactionSubsystem14Parser.readElement(TransactionSubsystem14Parser.java:111)
> at org.jboss.as.txn.subsystem.TransactionSubsystem14Parser.readElement(TransactionSubsystem14Parser.java:54) at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110)
> at org.jboss.staxmapper.XMLExtendedStreamReaderImpl.handleAny(XMLExtendedStreamReaderImpl.java:69) at org.jboss.as.server.parsing.StandaloneXml_4.parseServerProfile(StandaloneXml_4.java:547)
> at org.jboss.as.server.parsing.StandaloneXml_4.readServerElement(StandaloneXml_4.java:244) at org.jboss.as.server.parsing.StandaloneXml_4.readElement(StandaloneXml_4.java:143)
> at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:69) at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:47) at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110)
> at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69) at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:123)
> ... 3 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (DROOLS-465) Cannot find KieModule with LATEST
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/DROOLS-465?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration updated DROOLS-465:
-------------------------------------------
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1303018
Bugzilla Update: Perform
> Cannot find KieModule with LATEST
> ---------------------------------
>
> Key: DROOLS-465
> URL: https://issues.jboss.org/browse/DROOLS-465
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.1.0.Beta1
> Reporter: Takami Hirata
> Assignee: Mark Proctor
> Attachments: reproducer.zip
>
>
> I install a kmodule into local repository with command {{mvn clean install}}.
> Loading this kmodule with 'LATEST' works on the day, but will fail on next day.
> Maven will find update on next day because of default updatePolicy 'daily', then maven check local repository ({{org.kie.scanner.Aether}} treats as a remote repository) but local artifact cache does not have 'maven-metadata.xml' which remote artifact should have, so finding update fails and {{org.sonatype.aether.connector.file.FileRepositoryWorker}} removes {{maven-metadata-local.xml}} for cleanup.
> {{org.kie.scanner.Aether}} adds local repository to remote repositories, but this may be incorrect usage.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFLY-5640) No EJB receiver available for handling
by Ivan Straka (JIRA)
[ https://issues.jboss.org/browse/WFLY-5640?page=com.atlassian.jira.plugin.... ]
Ivan Straka edited comment on WFLY-5640 at 1/29/16 5:14 AM:
------------------------------------------------------------
Still failing.
I did some investigation yesterday and I figured out what the problem is.
https://github.com/wildfly/wildfly/tree/master/testsuite/integration/clus...
This should be set to 8180. Node1 is listening on this port. If you look into the configuration, you will find out that node0 is listening on 8080. Thats why you weren't able to reproduce it locally (neither were I). Due to the same ip addresses of node0 and node1 8080 was valid (node 0 is listening on 8080), on the other hand, if ip addresses are not same, noone is listening on node1_ip : 8080
I am just about to do a PR to WF.
was (Author: istraka):
Still failing.
I did some investigation yesterday and I figured out what the problem is.
https://github.com/jbossas/jboss-eap7/blob/7.x/testsuite/integration/clus...
This should be set to 8180. Node1 is listening on this port. If you look into the configuration, you will find out that node0 is listening on 8080. Thats why you weren't able to reproduce it locally (neither were I). Due to the same ip addresses of node0 and node1 8080 was valid (node 0 is listening on 8080), on the other hand, if ip addresses are not same, noone is listening on node1_ip : 8080
I am just about to do a PR to EAP.
> No EJB receiver available for handling
> --------------------------------------
>
> Key: WFLY-5640
> URL: https://issues.jboss.org/browse/WFLY-5640
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, EJB, Test Suite
> Affects Versions: 10.0.0.CR4
> Environment: hp-ux 11v3 - hpjdk1.8
> solaris 10,11 - x86 and x86_64, rhel 6 - x86 and x86_64, rhel 7 x86_64 - openjdk1.8, ibmjdk1.8, oraclejdk1.8
> Reporter: Ivan Straka
> Assignee: Richard Achmatowicz
> Fix For: 10.0.0.CR5
>
> Attachments: logs
>
>
> There are two tests failing in exteded tests in clusteringejb2 package in AS TS.
> org.jboss.as.test.clustering.extended.ejb2.stateless.RemoteStatelessFailoverTestCase(SYNC-tcp-extended)#testLoadbalanceSpecifiedByDescriptor
> org.jboss.as.test.clustering.extended.ejb2.stateless.RemoteStatelessFailoverTestCase(SYNC-tcp-extended)#testLoadbalanceAnnotatedBean
> both with exception
> {code}
> Error Message
> EJBCLIENT000025: No EJB receiver available for handling [appName:, moduleName:stateless-ejb2-failover-test, distinctName:] combination for invocation context org.jboss.ejb.client.EJBClientInvocationContext@54acff7d
> Stacktrace
> java.lang.IllegalStateException: EJBCLIENT000025: No EJB receiver available for handling [appName:, moduleName:stateless-ejb2-failover-test, distinctName:] combination for invocation context org.jboss.ejb.client.EJBClientInvocationContext@54acff7d
> at org.jboss.ejb.client.EJBClientContext.requireEJBReceiver(EJBClientContext.java:798)
> at org.jboss.ejb.client.ReceiverInterceptor.handleInvocation(ReceiverInterceptor.java:112)
> at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:186)
> at org.jboss.ejb.client.EJBInvocationHandler.sendRequestWithPossibleRetries(EJBInvocationHandler.java:255)
> at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:200)
> at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:183)
> at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:146)
> at com.sun.proxy.$Proxy28.create(Unknown Source)
> at org.jboss.as.test.clustering.extended.ejb2.stateless.RemoteStatelessFailoverTestCase.loadbalance(RemoteStatelessFailoverTestCase.java:262)
> at org.jboss.as.test.clustering.extended.ejb2.stateless.RemoteStatelessFailoverTestCase.testLoadbalanceAnnotatedBean(RemoteStatelessFailoverTestCase.java:224)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFLY-5640) No EJB receiver available for handling
by Ivan Straka (JIRA)
[ https://issues.jboss.org/browse/WFLY-5640?page=com.atlassian.jira.plugin.... ]
Ivan Straka reopened WFLY-5640:
-------------------------------
Still failing.
I did some investigation yesterday and I figured out what the problem is.
https://github.com/jbossas/jboss-eap7/blob/7.x/testsuite/integration/clus...
This should be set to 8180. Node1 is listening on this port. If you look into the configuration, you will find out that node0 is listening on 8080. Thats why you weren't able to reproduce it locally (neither were I). Due to the same ip addresses of node0 and node1 8080 was valid (node 0 is listening on 8080), on the other hand, if ip addresses are not same, noone is listening on node1_ip : 8080
I am just about to do a PR to EAP.
> No EJB receiver available for handling
> --------------------------------------
>
> Key: WFLY-5640
> URL: https://issues.jboss.org/browse/WFLY-5640
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, EJB, Test Suite
> Affects Versions: 10.0.0.CR4
> Environment: hp-ux 11v3 - hpjdk1.8
> solaris 10,11 - x86 and x86_64, rhel 6 - x86 and x86_64, rhel 7 x86_64 - openjdk1.8, ibmjdk1.8, oraclejdk1.8
> Reporter: Ivan Straka
> Assignee: Richard Achmatowicz
> Fix For: 10.0.0.CR5
>
> Attachments: logs
>
>
> There are two tests failing in exteded tests in clusteringejb2 package in AS TS.
> org.jboss.as.test.clustering.extended.ejb2.stateless.RemoteStatelessFailoverTestCase(SYNC-tcp-extended)#testLoadbalanceSpecifiedByDescriptor
> org.jboss.as.test.clustering.extended.ejb2.stateless.RemoteStatelessFailoverTestCase(SYNC-tcp-extended)#testLoadbalanceAnnotatedBean
> both with exception
> {code}
> Error Message
> EJBCLIENT000025: No EJB receiver available for handling [appName:, moduleName:stateless-ejb2-failover-test, distinctName:] combination for invocation context org.jboss.ejb.client.EJBClientInvocationContext@54acff7d
> Stacktrace
> java.lang.IllegalStateException: EJBCLIENT000025: No EJB receiver available for handling [appName:, moduleName:stateless-ejb2-failover-test, distinctName:] combination for invocation context org.jboss.ejb.client.EJBClientInvocationContext@54acff7d
> at org.jboss.ejb.client.EJBClientContext.requireEJBReceiver(EJBClientContext.java:798)
> at org.jboss.ejb.client.ReceiverInterceptor.handleInvocation(ReceiverInterceptor.java:112)
> at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:186)
> at org.jboss.ejb.client.EJBInvocationHandler.sendRequestWithPossibleRetries(EJBInvocationHandler.java:255)
> at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:200)
> at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:183)
> at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:146)
> at com.sun.proxy.$Proxy28.create(Unknown Source)
> at org.jboss.as.test.clustering.extended.ejb2.stateless.RemoteStatelessFailoverTestCase.loadbalance(RemoteStatelessFailoverTestCase.java:262)
> at org.jboss.as.test.clustering.extended.ejb2.stateless.RemoteStatelessFailoverTestCase.testLoadbalanceAnnotatedBean(RemoteStatelessFailoverTestCase.java:224)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFCORE-1341) Expose IO worker runtime data / statistics
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1341?page=com.atlassian.jira.plugi... ]
Tomaz Cerar updated WFCORE-1341:
--------------------------------
Summary: Expose IO worker runtime data / statistics (was: Remoting worker threads runtime current size, queue size, etc are not visible)
> Expose IO worker runtime data / statistics
> ------------------------------------------
>
> Key: WFCORE-1341
> URL: https://issues.jboss.org/browse/WFCORE-1341
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Remoting
> Affects Versions: 2.0.7.Final
> Reporter: Brad Maxwell
> Assignee: Tomaz Cerar
>
> The remoting subsystem uses a worker-thread-pool which can be configured such as shown below.
> The runtime thread pool information is not exposed when doing read-resource:
> {code}
> /subsystem=remoting:read-resource(include-runtime=true, recursive=true)
> {code}
> {code}
> <subsystem xmlns="urn:jboss:domain:remoting:1.1">
> <worker-thread-pool
> read-threads="1"
> task-core-threads="4"
> task-keepalive="60"
> task-limit="16384"
> task-max-threads="16"
> write-threads="1"
> />
> <connector name="remoting-connector" socket-binding="remoting" security-realm="ApplicationRealm"/>
> </subsystem>
> {code}
> In tuning and runtime diagnosis, it would be useful to see the thread pool information such as the current size, queue-size, largest-thread-count, etc similar to the ejb3 subsystem thread pool:
> {code}
> /subsystem=ejb3/thread-pool=default:read-resource(include-runtime=true, recursive=true)
> "result" => {
> "active-count" => 0,
> "completed-task-count" => 0L,
> "current-thread-count" => 0,
> "keepalive-time" => {
> "time" => 100L,
> "unit" => "MILLISECONDS"
> },
> "largest-thread-count" => 0,
> "max-threads" => 10,
> "name" => "default",
> "queue-size" => 0,
> "rejected-count" => 0,
> "task-count" => 0L,
> "thread-factory" => undefined
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFCORE-1341) Remoting worker threads runtime current size, queue size, etc are not visible
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1341?page=com.atlassian.jira.plugi... ]
Tomaz Cerar commented on WFCORE-1341:
-------------------------------------
it should be under /subsystem=io/worker=default:read-resource(include-runtime=true)
but we don't currently expose any runtime data there either, that is why I didn't close issue as we should definitely improve that.
> Remoting worker threads runtime current size, queue size, etc are not visible
> -----------------------------------------------------------------------------
>
> Key: WFCORE-1341
> URL: https://issues.jboss.org/browse/WFCORE-1341
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Remoting
> Affects Versions: 2.0.7.Final
> Reporter: Brad Maxwell
> Assignee: Tomaz Cerar
>
> The remoting subsystem uses a worker-thread-pool which can be configured such as shown below.
> The runtime thread pool information is not exposed when doing read-resource:
> {code}
> /subsystem=remoting:read-resource(include-runtime=true, recursive=true)
> {code}
> {code}
> <subsystem xmlns="urn:jboss:domain:remoting:1.1">
> <worker-thread-pool
> read-threads="1"
> task-core-threads="4"
> task-keepalive="60"
> task-limit="16384"
> task-max-threads="16"
> write-threads="1"
> />
> <connector name="remoting-connector" socket-binding="remoting" security-realm="ApplicationRealm"/>
> </subsystem>
> {code}
> In tuning and runtime diagnosis, it would be useful to see the thread pool information such as the current size, queue-size, largest-thread-count, etc similar to the ejb3 subsystem thread pool:
> {code}
> /subsystem=ejb3/thread-pool=default:read-resource(include-runtime=true, recursive=true)
> "result" => {
> "active-count" => 0,
> "completed-task-count" => 0L,
> "current-thread-count" => 0,
> "keepalive-time" => {
> "time" => 100L,
> "unit" => "MILLISECONDS"
> },
> "largest-thread-count" => 0,
> "max-threads" => 10,
> "name" => "default",
> "queue-size" => 0,
> "rejected-count" => 0,
> "task-count" => 0L,
> "thread-factory" => undefined
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFLY-5522) split artemis journal in its own module
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/WFLY-5522?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated WFLY-5522:
--------------------------------
Fix Version/s: 11.0.0.Alpha1
> split artemis journal in its own module
> ---------------------------------------
>
> Key: WFLY-5522
> URL: https://issues.jboss.org/browse/WFLY-5522
> Project: WildFly
> Issue Type: Enhancement
> Components: JMS, Transactions
> Affects Versions: 10.0.0.CR2
> Reporter: Jeff Mesnil
> Assignee: Jeff Mesnil
> Priority: Minor
> Fix For: 11.0.0.Alpha1
>
>
> The org.jboss.jts is depending on the org.apache.activemq.artemis only for its journal functionality but get all the module dependencies (including messaging stuff) that is not used at all.
> The org.apache.activemq.artemis should be split with a separate module for its journal containing the journal jar + commons jar + native lib required for libAIO.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months