[JBoss JIRA] (WFLY-2595) Logging DUP leaking class loaders
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-2595?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-2595:
-----------------------------------------------
Nikoleta Ziakova <nziakova(a)redhat.com> changed the Status of [bug 1038305|https://bugzilla.redhat.com/show_bug.cgi?id=1038305] from ON_QA to VERIFIED
> Logging DUP leaking class loaders
> ---------------------------------
>
> Key: WFLY-2595
> URL: https://issues.jboss.org/browse/WFLY-2595
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Logging
> Reporter: James Perkins
> Assignee: James Perkins
> Priority: Critical
> Fix For: 8.0.0.CR1
>
>
> When a new {{LogContext}} is created for per-deployment logging the class loader is registered as the key. On undeploy the {{LogContext}} should be removed, but the wrong {{LogContext}}t is retrieved due to the caller class loader being used rather than the TCCL.
> The use of the caller class loader is for filtering out system dependencies from the deployment so the correct {{LogContext}} is retrieved from the selector.
--
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
12 years, 4 months
[JBoss JIRA] (JGRP-1794) OOBTest method testNonBlockingUnicastOOBMessage fails to correctly receive all OOB mssages
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1794?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1794:
--------------------------------
I also changed {{UNICAST.xmit_interval}} to 1 s (from 2), so dropped msgs are retransmitted faster.
Richard, I cannot reproduce the issue anymore. Can you try with the latest on the 3.2 branch again and close the issue if you can't reproduce it ?
> OOBTest method testNonBlockingUnicastOOBMessage fails to correctly receive all OOB mssages
> -------------------------------------------------------------------------------------------
>
> Key: JGRP-1794
> URL: https://issues.jboss.org/browse/JGRP-1794
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.2.13
> Environment: Solaris, RHEL, Windows, HPUX
> tcp stack only
> Reporter: Richard Achmatowicz
> Assignee: Bela Ban
> Fix For: 3.2.13, 3.5
>
>
> This test fails regularly on multiple platforms. It doesn't fail all the time, but perhaps on 5/10 platform executions.
> The test consists of a sender and a receiver. The receiver B will receive OOB messages but blocks on a latch for 25 seconds when it receives a non-OOB message. After 25 seconds, it unblocks and continues receiving
> The test does this:
> - send 1 regular message from A -> B
> - send 9 OOB meesages from A -> B
> - wait 20 seconds for messages to arrive
> - check that all 9 OOB messages have arrived
> - unblock the latch
> - check that all 10 message have arrived
> The test failures all involve the first 9 OOB messages not arriving completely. For example, sample lists of received messages before the first 20 second interval are:
> [3,2,6,8,9,10,4]
> [2,3,4,8,9,5]
> [2,3,4,8,7,9]
> [2,3,5,4,6]
> So, it appears that either the messages are slow to arrive or not arriving at all.
> A correct result looks like this:
> {noformat}
> list = [2, 4, 3, 7, 8, 9, 10, 5, 6]
> [main]: releasing latch
> list = [2, 4, 3, 7, 8, 9, 10, 5, 6, 1]
> {noformat}
>
--
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
12 years, 4 months
[JBoss JIRA] (WFLY-2266) Deployment Overlay feature is not able to replace the application libraries.
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-2266?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-2266:
-----------------------------------------------
Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 1016995|https://bugzilla.redhat.com/show_bug.cgi?id=1016995] from NEW to POST
> Deployment Overlay feature is not able to replace the application libraries.
> ----------------------------------------------------------------------------
>
> Key: WFLY-2266
> URL: https://issues.jboss.org/browse/WFLY-2266
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Affects Versions: 8.0.0.Beta1
> Environment: All Operating Systems
> Reporter: Jay Kumar SenSharma
> Assignee: Stuart Douglas
> Labels: deployment
> Fix For: 8.0.0.CR1
>
>
> -----------------------
> According to the documentation: [1] the deployment overlay feature is applicable for "swapping out deployment descriptors, modifying static web resources to change the branding of an application, or even replacing jar libraries with different versions."
> Here it talks about "replacing jar libraries" which is not working as expected and causes the following error.
> [1] https://docs.jboss.org/author/display/AS72/Deployment+Overlays
> Follow the below sequence of deployment and overlay:
> Steps to Reproduce:
> ------------------
> *Step-1).* Undeploy if any existing application is deployed and then freshly deploy the application.
> {quote}
> [standalone@localhost:9999 /] undeploy DeploymentOverlayDemo.war
> [standalone@localhost:9999 /] deploy /home/jaysensharma/TestApp/build/DeploymentOverlayDemo.war
> {quote}
> *Step-2).* Make some changes in java code _"Hello.java"_ . Create a new JAR Hello.jar which we want to replace at _(/WEB-INF/lib/Hello.jar)_ using deployment-overlay feature. In the attached ant based Demo just do _"ant compile"_ to create a new Jar _"${project.dir}/tmp/Hello.jar"_
> *Step-3).* Use the following command in order to replace the "/WEB-INF/lib/Hello.jar" with the newly created Hello.jar using deployment overlay feature as following:
> {quote}
> [standalone@localhost:9999 /] deployment-overlay add --name=myOverLay_1 --content=/WEB-INF/lib/Hello.jar=/home/jaysensharma/TestApp/tmp/Hello.jar --deployments=DeploymentOverlayDemo.war --redeploy-affected
> {quote}
>
> Above causes the following Exception:
> {quote}
> 12:09:59,736 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) JBAS018224: Unregister web context: /DeploymentOverlayDemo
> 12:09:59,760 WARN [org.wildfly.extension.undertow] (MSC service thread 1-2) JBAS017530: Could not delete servlet temp file /NotBackedUp/SVN_16_Jan/WildFly/build_Apps/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/tmp/DeploymentOverlayDemo.war/org/apache/jsp
> 12:09:59,761 WARN [org.wildfly.extension.undertow] (MSC service thread 1-2) JBAS017530: Could not delete servlet temp file /NotBackedUp/SVN_16_Jan/WildFly/build_Apps/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/tmp/DeploymentOverlayDemo.war/org/apache
> 12:09:59,761 WARN [org.wildfly.extension.undertow] (MSC service thread 1-2) JBAS017530: Could not delete servlet temp file /NotBackedUp/SVN_16_Jan/WildFly/build_Apps/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/tmp/DeploymentOverlayDemo.war/org
> 12:09:59,762 WARN [org.wildfly.extension.undertow] (MSC service thread 1-2) JBAS017530: Could not delete servlet temp file /NotBackedUp/SVN_16_Jan/WildFly/build_Apps/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/tmp/DeploymentOverlayDemo.war
> 12:09:59,787 INFO [org.jboss.as.server.deployment] (MSC service thread 1-5) JBAS015877: Stopped deployment DeploymentOverlayDemo.war (runtime-name: DeploymentOverlayDemo.war) in 56ms
> 12:09:59,789 INFO [org.jboss.as.server.deployment] (MSC service thread 1-8) JBAS015876: Starting deployment of "DeploymentOverlayDemo.war" (runtime-name: "DeploymentOverlayDemo.war")
> 12:09:59,799 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8) MSC000001: Failed to start service jboss.deployment.unit."DeploymentOverlayDemo.war".STRUCTURE: org.jboss.msc.service.StartException in service jboss.deployment.unit."DeploymentOverlayDemo.war".STRUCTURE: JBAS018733: Failed to process phase STRUCTURE of deployment "DeploymentOverlayDemo.war"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [wildfly-server-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1944) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1877) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS018776: Failed to get content for deployment overlay myOverLay_1 at /WEB-INF/lib/Hello.jar
> at org.jboss.as.server.deployment.ContentOverrideDeploymentUnitProcessor.deploy(ContentOverrideDeploymentUnitProcessor.java:70) [wildfly-server-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [wildfly-server-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> ... 5 more
> Caused by: java.io.IOException: VFS000017: Filesystem already mounted at mount point ""/content/DeploymentOverlayDemo.war/WEB-INF/lib/Hello.jar""
> at org.jboss.vfs.VFS.mount(VFS.java:127) [jboss-vfs-3.2.2.Final.jar:3.2.2.Final]
> at org.jboss.vfs.VFS.doMount(VFS.java:336) [jboss-vfs-3.2.2.Final.jar:3.2.2.Final]
> at org.jboss.vfs.VFS.mountReal(VFS.java:423) [jboss-vfs-3.2.2.Final.jar:3.2.2.Final]
> at org.jboss.as.server.deployment.ContentOverrideDeploymentUnitProcessor.deploy(ContentOverrideDeploymentUnitProcessor.java:67) [wildfly-server-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> ... 6 more
> 12:09:59,805 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 3) JBAS014613: Operation ("redeploy") failed - address: ([("deployment" => "DeploymentOverlayDemo.war")]) - failure description: {"JBAS014671: Failed services" => {"jboss.deployment.unit.\"DeploymentOverlayDemo.war\".STRUCTURE" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"DeploymentOverlayDemo.war\".STRUCTURE: JBAS018733: Failed to process phase STRUCTURE of deployment \"DeploymentOverlayDemo.war\"
> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS018776: Failed to get content for deployment overlay myOverLay_1 at /WEB-INF/lib/Hello.jar
> Caused by: java.io.IOException: VFS000017: Filesystem already mounted at mount point \"\"/content/DeploymentOverlayDemo.war/WEB-INF/lib/Hello.jar\"\""}}
> 12:09:59,809 ERROR [org.jboss.as.server] (management-handler-thread - 3) JBAS015860: Redeploy of deployment "DeploymentOverlayDemo.war" was rolled back with the following failure message:
> {"JBAS014671: Failed services" => {"jboss.deployment.unit.\"DeploymentOverlayDemo.war\".STRUCTURE" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"DeploymentOverlayDemo.war\".STRUCTURE: JBAS018733: Failed to process phase STRUCTURE of deployment \"DeploymentOverlayDemo.war\"
> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS018776: Failed to get content for deployment overlay myOverLay_1 at /WEB-INF/lib/Hello.jar
> Caused by: java.io.IOException: VFS000017: Filesystem already mounted at mount point \"\"/content/DeploymentOverlayDemo.war/WEB-INF/lib/Hello.jar\"\""}}
> 12:09:59,814 INFO [org.jboss.as.controller] (management-handler-thread - 3) JBAS014774: Service status report
> JBAS014777: Services which failed to start: service jboss.deployment.unit."DeploymentOverlayDemo.war".STRUCTURE: org.jboss.msc.service.StartException in service jboss.deployment.unit."DeploymentOverlayDemo.war".STRUCTURE: JBAS018733: Failed to process phase STRUCTURE of deployment "DeploymentOverlayDemo.war"
> {quote}
--
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
12 years, 4 months
[JBoss JIRA] (JGRP-1794) OOBTest method testNonBlockingUnicastOOBMessage fails to correctly receive all OOB mssages
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1794?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1794:
--------------------------------
OK, increasing the OOB pool size from min=1/max=2 to min=4/max=8 (like in master) seemed to fix this. Can't reproduce the error anymore with UDP. Now trying TCP...
> OOBTest method testNonBlockingUnicastOOBMessage fails to correctly receive all OOB mssages
> -------------------------------------------------------------------------------------------
>
> Key: JGRP-1794
> URL: https://issues.jboss.org/browse/JGRP-1794
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.2.13
> Environment: Solaris, RHEL, Windows, HPUX
> tcp stack only
> Reporter: Richard Achmatowicz
> Assignee: Bela Ban
> Fix For: 3.2.13, 3.5
>
>
> This test fails regularly on multiple platforms. It doesn't fail all the time, but perhaps on 5/10 platform executions.
> The test consists of a sender and a receiver. The receiver B will receive OOB messages but blocks on a latch for 25 seconds when it receives a non-OOB message. After 25 seconds, it unblocks and continues receiving
> The test does this:
> - send 1 regular message from A -> B
> - send 9 OOB meesages from A -> B
> - wait 20 seconds for messages to arrive
> - check that all 9 OOB messages have arrived
> - unblock the latch
> - check that all 10 message have arrived
> The test failures all involve the first 9 OOB messages not arriving completely. For example, sample lists of received messages before the first 20 second interval are:
> [3,2,6,8,9,10,4]
> [2,3,4,8,9,5]
> [2,3,4,8,7,9]
> [2,3,5,4,6]
> So, it appears that either the messages are slow to arrive or not arriving at all.
> A correct result looks like this:
> {noformat}
> list = [2, 4, 3, 7, 8, 9, 10, 5, 6]
> [main]: releasing latch
> list = [2, 4, 3, 7, 8, 9, 10, 5, 6, 1]
> {noformat}
>
--
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
12 years, 4 months
[JBoss JIRA] (WFLY-3003) Dropping unicast message to wrong destination warn after cluster node rejoin
by Eduardo Martins (JIRA)
Eduardo Martins created WFLY-3003:
-------------------------------------
Summary: Dropping unicast message to wrong destination warn after cluster node rejoin
Key: WFLY-3003
URL: https://issues.jboss.org/browse/WFLY-3003
Project: WildFly
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Clustering
Reporter: Eduardo Martins
Assignee: Paul Ferraro
There is a never ending warn log message printed after a cluster node rejoins, after a shutdown:
03:43:15,831 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
03:43:15,831 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
03:43:15,887 INFO [org.jboss.as.server] (Controller Boot Thread) JBAS018559: Deployed "wildfly-cluster-ha-singleton-service.jar" (runtime-name : "wildfly-cluster-ha-singleton-service.jar")
03:43:15,895 INFO [org.jboss.as] (Controller Boot Thread) JBAS015961: Http management interface listening on http://127.0.0.1:10090/management
03:43:15,895 INFO [org.jboss.as] (Controller Boot Thread) JBAS015951: Admin console listening on http://127.0.0.1:10090
03:43:15,896 INFO [org.jboss.as] (Controller Boot Thread) JBAS015874: WildFly 8.0.1.Final-SNAPSHOT "WildFly" started in 4855ms - Started 345 of 437 services (171 services are lazy, passive or on-demand)
03:43:16,332 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
03:43:16,332 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
03:43:16,833 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
03:43:16,834 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
03:43:17,335 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
03:43:17,336 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
03:43:17,835 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
03:43:17,836 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
03:43:18,335 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
03:43:18,336 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
03:43:18,837 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
03:43:18,838 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
03:43:19,339 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
03:43:19,340 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
03:43:19,840 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
03:43:19,840 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
03:43:20,003 INFO [org.jboss.as.quickstarts.cluster.hasingleton.service.ejb.SchedulerBean] (EJB default - 1) HASingletonTimer: Info=HASingleton timer @nodeTwo Sat Feb 22 03:43:15 WET 2014
03:43:20,003 INFO [org.jboss.as.quickstarts.cluster.hasingleton.service.ejb.SchedulerBean] (EJB default - 2) HASingletonTimer: Info=HASingleton timer @nodeTwo Sat Feb 22 03:43:15 WET 2014
03:43:20,341 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
03:43:20,342 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
03:43:20,841 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
03:43:20,842 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
03:43:21,342 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
03:43:21,342 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
03:43:21,842 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
03:43:21,843 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
03:43:22,343 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
03:43:22,344 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
03:43:22,845 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
03:43:22,845 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
03:43:23,345 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
03:43:23,346 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
03:43:23,846 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/server: dropping unicast message to wrong destination a1fdbb88-a500-483d-7405-70c93a8ab740
03:43:23,846 WARN [org.jgroups.protocols.TP$ProtocolAdapter] (INT-1,shared=udp) JGRP000031: nodeTwo/ejb: dropping unicast message to wrong destination f567dfca-cdad-2555-0e3b-22c8ebded75b
This can be seen using WildFly's cluster-ha-singleton quickstart (github project wildfly/quickstart). Just follow quickstart’s readme till point 4 of "Check the timer" section, and after stop node2 (not node1) start it gain.
--
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
12 years, 4 months
[JBoss JIRA] (DROOLS-404) NoClassDefFoundError happens when using "function"s in drl
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/DROOLS-404?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on DROOLS-404:
------------------------------------------------
Marek Winkler <mwinkler(a)redhat.com> changed the Status of [bug 1060218|https://bugzilla.redhat.com/show_bug.cgi?id=1060218] from ON_QA to VERIFIED
> NoClassDefFoundError happens when using "function"s in drl
> ----------------------------------------------------------
>
> Key: DROOLS-404
> URL: https://issues.jboss.org/browse/DROOLS-404
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 6.0.0.Final, 6.0.1.Final
> Environment: The base environment is the same as DefaultKieSessionExample.
> See attached maven project for details.
> Reporter: Nandor Galambosi
> Assignee: Mario Fusco
> Fix For: 6.1.0.Beta1
>
> Attachments: noclassdeffound.zip
>
>
> If I reuse a KieSession for multiple times, it seems to forget about the function defined in the DRL file.
> DRL:
> {noformat}
> package org.drools.example.api.defaultkiesession.Hal1
> import org.drools.example.api.defaultkiesession.Message
> function boolean alwaysTrue() {
> return true;
> }
> rule "rule 1" when
> m : Message( )
> then
> retract(m);
> end
> rule "rule 2" when
> Message( alwaysTrue(), text == "Hello, HAL. Do you read me, HAL?" )
> then
> insert( new Message("HAL", "Dave. I read you." ) );
> end
> {noformat}
> Java code:
> {noformat}
> package org.drools.example.api.defaultkiesession;
> import org.kie.api.KieServices;
> import org.kie.api.runtime.KieContainer;
> import org.kie.api.runtime.KieSession;
> public class DefaultKieSessionExample
> {
> static int counter = 0;
> public void failCase1()
> {
> KieServices ks = KieServices.Factory.get();
> KieContainer kContainer = ks.getKieClasspathContainer();
> KieSession kSession = kContainer.newKieSession();
> for( counter = 0; counter < 10000; ++counter) {
> kSession.insert(new Message("Dave", "Hello, HAL. Do you read me, HAL?"));
> kSession.fireAllRules();
> if (kSession.getFactCount() != 0) {
> System.err.println("error");
> }
> }
> }
> public static void main(String[] args)
> {
> try {
> DefaultKieSessionExample defaultKieSessionExample = new DefaultKieSessionExample();
> defaultKieSessionExample.failCase1();
> } catch (NoClassDefFoundError error) {
> System.err.println("Failed after "+counter+" testcases");
> error.printStackTrace();
> }
> }
> }
> {noformat}
> Runs fine for some iterations, and after a while an exception happens:
> {noformat}
> java.lang.NoClassDefFoundError: org/drools/example/api/defaultkiesession/Hal1/AlwaysTrue
> at ConditionEvaluator19fe4e382c304060b0046f5cdc6a59fa.evaluate(Unknown Source)
> at org.drools.core.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:217)
> at org.drools.core.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:174)
> at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:134)
> at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:502)
> at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:387)
> at org.drools.core.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:288)
> at org.drools.core.reteoo.EntryPointNode.assertObject(EntryPointNode.java:260)
> at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:360)
> at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:279)
> at org.drools.core.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:1148)
> at org.drools.core.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:1092)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:308)
> at org.drools.example.api.defaultkiesession.DefaultKieSessionExample.failCase1(DefaultKieSessionExample.java:17)
> at org.drools.example.api.defaultkiesession.DefaultKieSessionExample.main(DefaultKieSessionExample.java:29)
> Caused by: java.lang.ClassNotFoundException: org.drools.example.api.defaultkiesession.Hal1.AlwaysTrue
> at org.drools.core.common.ProjectClassLoader.tryDefineType(ProjectClassLoader.java:123)
> at org.drools.core.common.ProjectClassLoader.loadType(ProjectClassLoader.java:114)
> at org.drools.core.common.ProjectClassLoader.loadClass(ProjectClassLoader.java:84)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
> ... 15 more
> {noformat}
--
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
12 years, 4 months
[JBoss JIRA] (JBMETA-371) DefaultPropertyReplacer + PropertyResolver is broken for vault expressions
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/JBMETA-371?page=com.atlassian.jira.plugin... ]
Tomaz Cerar updated JBMETA-371:
-------------------------------
Bugzilla Update: (was: Perform)
> DefaultPropertyReplacer + PropertyResolver is broken for vault expressions
> --------------------------------------------------------------------------
>
> Key: JBMETA-371
> URL: https://issues.jboss.org/browse/JBMETA-371
> Project: JBoss Metadata
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: common
> Affects Versions: 7.0.4.Final
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 8.0.0.Final
>
>
> The DefaultPropertyReplacer + PropertyResolver algorithm is broken for vault expressions. It's based on the assumption that the contents of the expression string between "${" and "}" have a fixed format a la the old JBoss AS system properties (e.g. propertyname[: default value]) and then the PropertyResolver tries to resolve "propertyname".
> This is incorrect in the case of vault expressions, which do not follow this format. In particular the ":" char appears multiple places in a vault expression and does not serve as a delimiter between "propertyname" and "default value".
--
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
12 years, 4 months
[JBoss JIRA] (JGRP-1794) OOBTest method testNonBlockingUnicastOOBMessage fails to correctly receive all OOB mssages
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1794?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1794:
--------------------------------
This test works flawlessly on master with both UDP and TCP: running this with an invocationCount of 20, there's not a single failure. Investigating why this isn't happening on 3.2...
> OOBTest method testNonBlockingUnicastOOBMessage fails to correctly receive all OOB mssages
> -------------------------------------------------------------------------------------------
>
> Key: JGRP-1794
> URL: https://issues.jboss.org/browse/JGRP-1794
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.2.13
> Environment: Solaris, RHEL, Windows, HPUX
> tcp stack only
> Reporter: Richard Achmatowicz
> Assignee: Bela Ban
> Fix For: 3.2.13, 3.5
>
>
> This test fails regularly on multiple platforms. It doesn't fail all the time, but perhaps on 5/10 platform executions.
> The test consists of a sender and a receiver. The receiver B will receive OOB messages but blocks on a latch for 25 seconds when it receives a non-OOB message. After 25 seconds, it unblocks and continues receiving
> The test does this:
> - send 1 regular message from A -> B
> - send 9 OOB meesages from A -> B
> - wait 20 seconds for messages to arrive
> - check that all 9 OOB messages have arrived
> - unblock the latch
> - check that all 10 message have arrived
> The test failures all involve the first 9 OOB messages not arriving completely. For example, sample lists of received messages before the first 20 second interval are:
> [3,2,6,8,9,10,4]
> [2,3,4,8,9,5]
> [2,3,4,8,7,9]
> [2,3,5,4,6]
> So, it appears that either the messages are slow to arrive or not arriving at all.
> A correct result looks like this:
> {noformat}
> list = [2, 4, 3, 7, 8, 9, 10, 5, 6]
> [main]: releasing latch
> list = [2, 4, 3, 7, 8, 9, 10, 5, 6, 1]
> {noformat}
>
--
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
12 years, 4 months