[JBoss JIRA] (DROOLS-266) KIE resolving dependend artifacts issue
by Kurt Stam (JIRA)
[ https://issues.jboss.org/browse/DROOLS-266?page=com.atlassian.jira.plugin... ]
Kurt Stam updated DROOLS-266:
-----------------------------
Attachment: kie-load-from-maven-issue.tgz
fixed the test
run
mvn clean install -DskipTests=true
mvn package
> KIE resolving dependend artifacts issue
> ---------------------------------------
>
> Key: DROOLS-266
> URL: https://issues.jboss.org/browse/DROOLS-266
> Project: Drools
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Affects Versions: 6.0.0.CR3
> Reporter: Kurt Stam
> Assignee: Mario Fusco
> Attachments: kie-load-from-maven-issue.tgz, kie-load-from-maven-issue.tgz
>
>
> This happens when for a dependency the scope is
> - set to 'provided' and
> - a parameter (in the case ${jbpm.version}) is used in the version field.
> So the relevant entry in the pom is:
> <dependency>
> <groupId>org.drools</groupId>
> <artifactId>drools-core</artifactId>
> <version>${drools.version}</version>
> <scope>provided</scope>
> </dependency>
> which leads to
> 11:15:02,584 WARN Dependency artifact not found for: org.jbpm:jbpm-bpmn2:${jbpm.version}
> and then the NPE. I'm guessing the parameter is not being resolved.
> 1. it probably should resolve parameters
> 2. if a dependency is scoped as 'provided' I think it is supposed to locate it on the classpath and NOT from maven. However I'm not sure this is the way that works in testing anyway.
> 3. if the dependency cannot be found it should probably stop and not even proceed rather then warn?
> 4. it should be interesting to see why it gets the NPE.
> If you change the dependency from 'provided' to 'test' things work fine.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years
[JBoss JIRA] (JGRP-1710) Messages get too large due to big headers (in large clusters)
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1710?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1710:
--------------------------------
As discussed on JGRP-1507: FRAG\{2\} cannot be moved over the transport as retransmission of large messages with 1 fragment missing would cause retransmission of the entire message (all fragments).
Therefore, the current strategy is to move large data from the header into the message's buffer and - if needed - add a second FRAG\{2\} directly over the transport. This second fragmentation protocol would typically not have to do any work, as fragmentation is done by the first fragmentation protocol. The only case where work would need to be done is when large data are added by a protocol, e.g. view and digest by {{INSTALL_MERGE_VIEW in GMS}}.
The advantage of moving large data into the body of a message is that FRAG2.down() can do a cheap {{Message.getLength()}}, compared to a more costly {{Message.size()}} by {{FRAG.down(){{.
> Messages get too large due to big headers (in large clusters)
> -------------------------------------------------------------
>
> Key: JGRP-1710
> URL: https://issues.jboss.org/browse/JGRP-1710
> Project: JGroups
> Issue Type: Bug
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.4
>
>
> In some cases, messages get bigger than the max bundling size because of large headers:
> {panel}
> ERROR 17:33:08,096 | Timer-5,c0,172.29.189.9-svc9-ZM26S32728-59135 | [TP.java:1335] | (org) | 172.29.189.9-svc9-ZM26S32728-59135: failed sending message to 172.29.190.181-svc2-00832091-31665 (70850 bytes): java.lang.Exception: message size (70850) is greater than max bundling size (64000). Set the fragmentation/bundle size in FRAG and TP correctly, headers: GMS: GmsHeader[INSTALL_MERGE_VIEW]: view=MergeView::[172.29.190.174-svc6-00832251-874|27] (1479) ...
> {panel}
> In the case of INSTALL_MERGE_VIEW, we send the full view (*not* the DeltaView) and the digest in the header. With 1479 members (as shown the the example above), this increases the message size beyond the max bundling size.
> Possible SOLUTION
> * Place the header fields in the message's buffer instead
> * Move FRAG2 *under* GMS
> ** Investigate impact on flow control etc
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years
[JBoss JIRA] (WFLY-1569) Not possible to reload server when JTS transactions are activated
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-1569?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-1569:
-----------------------------------------------
tom.jenkinson(a)redhat.com changed the Status of [bug 1011379|https://bugzilla.redhat.com/show_bug.cgi?id=1011379] from NEW to POST
> Not possible to reload server when JTS transactions are activated
> -----------------------------------------------------------------
>
> Key: WFLY-1569
> URL: https://issues.jboss.org/browse/WFLY-1569
> Project: WildFly
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 8.0.0.Alpha1
> Reporter: Ondřej Chaloupka
> Assignee: Stefano Maestri
>
> When transactions are set for JTS being used
> - <jts/> tag under transactions subsystem
> - transactions="on" under jacorb subsystem
> then it is not possible to reload the server.
> The reload causes the following exception being shown.
> {code}
> 14:30:56,388 WARN [com.arjuna.ats.jts] (MSC service thread 1-5) ARJUNA022083: JacOrbRCServiceInit - Failed to start RC service: org.omg.CORBA.OBJECT_NOT_EXIST: POA destroyed
> at org.jacorb.poa.POA.checkDestructionApparent(POA.java:1409)
> at org.jacorb.poa.POA.set_servant(POA.java:1979)
> at com.arjuna.ats.internal.jts.orbspecific.jacorb.recoverycoordinators.JacOrbRCServiceInit.startRCservice(JacOrbRCServiceInit.java:197) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
> at com.arjuna.ats.internal.jts.orbspecific.recovery.RecoveryEnablement.startRCservice(RecoveryEnablement.java:137) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
> at com.arjuna.ats.internal.arjuna.recovery.RecActivatorLoader.startRecoveryActivators(RecActivatorLoader.java:66) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
> at com.arjuna.ats.internal.arjuna.recovery.RecoveryManagerImple.<init>(RecoveryManagerImple.java:104) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
> at com.arjuna.ats.arjuna.recovery.RecoveryManager.initialize(RecoveryManager.java:224) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
> at com.arjuna.ats.jbossatx.jta.RecoveryManagerService.start(RecoveryManagerService.java:65) [narayana-jts-integration-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
> at org.jboss.as.txn.service.ArjunaRecoveryManagerService.start(ArjunaRecoveryManagerService.java:139) [wildfly-transactions-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1942) [jboss-msc-1.2.0.Beta1.jar:1.2.0.Beta1]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1875) [jboss-msc-1.2.0.Beta1.jar:1.2.0.Beta1]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_17]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_17]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17]
> 14:30:56,396 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC000001: Failed to start service jboss.txn.ArjunaRecoveryManager: org.jboss.msc.service.StartException in service jboss.txn.ArjunaRecoveryManager: JBAS010101: Recovery manager create failed
> at org.jboss.as.txn.service.ArjunaRecoveryManagerService.start(ArjunaRecoveryManagerService.java:142)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1942) [jboss-msc-1.2.0.Beta1.jar:1.2.0.Beta1]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1875) [jboss-msc-1.2.0.Beta1.jar:1.2.0.Beta1]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_17]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_17]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17]
> Caused by: java.lang.RuntimeException: ARJUNA012364: RecoveryActivator init failed for com.arjuna.ats.internal.jts.orbspecific.recovery.RecoveryEnablement
> at com.arjuna.ats.internal.arjuna.recovery.RecActivatorLoader.startRecoveryActivators(RecActivatorLoader.java:67)
> at com.arjuna.ats.internal.arjuna.recovery.RecoveryManagerImple.<init>(RecoveryManagerImple.java:104)
> at com.arjuna.ats.arjuna.recovery.RecoveryManager.initialize(RecoveryManager.java:224)
> at com.arjuna.ats.jbossatx.jta.RecoveryManagerService.start(RecoveryManagerService.java:65)
> at org.jboss.as.txn.service.ArjunaRecoveryManagerService.start(ArjunaRecoveryManagerService.java:139)
> ... 5 more
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years
[JBoss JIRA] (WFLY-1569) Not possible to reload server when JTS transactions are activated
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-1569?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-1569:
-----------------------------------------------
tom.jenkinson(a)redhat.com made a comment on [bug 1011379|https://bugzilla.redhat.com/show_bug.cgi?id=1011379]
https://github.com/jbossas/jboss-eap/pull/478
> Not possible to reload server when JTS transactions are activated
> -----------------------------------------------------------------
>
> Key: WFLY-1569
> URL: https://issues.jboss.org/browse/WFLY-1569
> Project: WildFly
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 8.0.0.Alpha1
> Reporter: Ondřej Chaloupka
> Assignee: Stefano Maestri
>
> When transactions are set for JTS being used
> - <jts/> tag under transactions subsystem
> - transactions="on" under jacorb subsystem
> then it is not possible to reload the server.
> The reload causes the following exception being shown.
> {code}
> 14:30:56,388 WARN [com.arjuna.ats.jts] (MSC service thread 1-5) ARJUNA022083: JacOrbRCServiceInit - Failed to start RC service: org.omg.CORBA.OBJECT_NOT_EXIST: POA destroyed
> at org.jacorb.poa.POA.checkDestructionApparent(POA.java:1409)
> at org.jacorb.poa.POA.set_servant(POA.java:1979)
> at com.arjuna.ats.internal.jts.orbspecific.jacorb.recoverycoordinators.JacOrbRCServiceInit.startRCservice(JacOrbRCServiceInit.java:197) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
> at com.arjuna.ats.internal.jts.orbspecific.recovery.RecoveryEnablement.startRCservice(RecoveryEnablement.java:137) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
> at com.arjuna.ats.internal.arjuna.recovery.RecActivatorLoader.startRecoveryActivators(RecActivatorLoader.java:66) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
> at com.arjuna.ats.internal.arjuna.recovery.RecoveryManagerImple.<init>(RecoveryManagerImple.java:104) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
> at com.arjuna.ats.arjuna.recovery.RecoveryManager.initialize(RecoveryManager.java:224) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
> at com.arjuna.ats.jbossatx.jta.RecoveryManagerService.start(RecoveryManagerService.java:65) [narayana-jts-integration-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
> at org.jboss.as.txn.service.ArjunaRecoveryManagerService.start(ArjunaRecoveryManagerService.java:139) [wildfly-transactions-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1942) [jboss-msc-1.2.0.Beta1.jar:1.2.0.Beta1]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1875) [jboss-msc-1.2.0.Beta1.jar:1.2.0.Beta1]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_17]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_17]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17]
> 14:30:56,396 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC000001: Failed to start service jboss.txn.ArjunaRecoveryManager: org.jboss.msc.service.StartException in service jboss.txn.ArjunaRecoveryManager: JBAS010101: Recovery manager create failed
> at org.jboss.as.txn.service.ArjunaRecoveryManagerService.start(ArjunaRecoveryManagerService.java:142)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1942) [jboss-msc-1.2.0.Beta1.jar:1.2.0.Beta1]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1875) [jboss-msc-1.2.0.Beta1.jar:1.2.0.Beta1]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_17]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_17]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17]
> Caused by: java.lang.RuntimeException: ARJUNA012364: RecoveryActivator init failed for com.arjuna.ats.internal.jts.orbspecific.recovery.RecoveryEnablement
> at com.arjuna.ats.internal.arjuna.recovery.RecActivatorLoader.startRecoveryActivators(RecActivatorLoader.java:67)
> at com.arjuna.ats.internal.arjuna.recovery.RecoveryManagerImple.<init>(RecoveryManagerImple.java:104)
> at com.arjuna.ats.arjuna.recovery.RecoveryManager.initialize(RecoveryManager.java:224)
> at com.arjuna.ats.jbossatx.jta.RecoveryManagerService.start(RecoveryManagerService.java:65)
> at org.jboss.as.txn.service.ArjunaRecoveryManagerService.start(ArjunaRecoveryManagerService.java:139)
> ... 5 more
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years