[JBoss JIRA] (JGRP-2493) RELAY does not use protocol stack supplied programmatically
by S Pokutniy (Jira)
S Pokutniy created JGRP-2493:
--------------------------------
Summary: RELAY does not use protocol stack supplied programmatically
Key: JGRP-2493
URL: https://issues.redhat.com/browse/JGRP-2493
Project: JGroups
Issue Type: Bug
Affects Versions: 4.2.4
Reporter: S Pokutniy
Assignee: Bela Ban
RELAY does not use protocol stack supplied programmatically (i.e. stack which was set by using relay.setProtocolStack(protocolStack). Even though the stack is used in init(), the function below only relies on bridge_props file. Even though using an XML file is mostly possible, it becomes problematic when a custom SSLContext needs to be used in SSL_KEY_EXCHANGE, which can now only be set programmatically.
protected void createBridge() {
try {
if(log.isTraceEnabled())
log.trace("I'm the coordinator, creating a channel (props=" + bridge_props + ", cluster_name=" + bridge_name + ")");
{color:#FF0000}bridge=new JChannel(bridge_props);{color}
bridge.setDiscardOwnMessages(true); // don't receive my own messages
bridge.setReceiver(new Receiver());
bridge.connect(bridge_name);
}
catch(Exception e) {
log.error(Util.getMessage("FailedCreatingBridgeChannelProps") + bridge_props + ")", e);
}
}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 2 months
[JBoss JIRA] (WFLY-13684) Intermittent failures in MixedDomainDeployment700TestCase
by Radoslav Husar (Jira)
[ https://issues.redhat.com/browse/WFLY-13684?page=com.atlassian.jira.plugi... ]
Radoslav Husar commented on WFLY-13684:
---------------------------------------
Removing 'testJsfWorks' form the summary since all of those tests fail frequently all together, e.g. [https://ci.wildfly.org/project.html?buildTypeId=&tab=testDetails&pr... the PR disabled the test entirely on non-Windows OSes.
> Intermittent failures in MixedDomainDeployment700TestCase
> ---------------------------------------------------------
>
> Key: WFLY-13684
> URL: https://issues.redhat.com/browse/WFLY-13684
> Project: WildFly
> Issue Type: Bug
> Components: JMS, Management
> Reporter: Brian Stansberry
> Assignee: Emmanuel Hugonnet
> Priority: Major
>
> Lots of failures starting July 16, 2020: https://ci.wildfly.org/project.html?projectId=WF&buildTypeId=&tab=testDet...
> This is the first failure in a set of 12-13 failures.
> Odd thing is nothing was merged into master after July 12, so why these started failing is unclear.
> WFLY-12649 was a similar issue-, but there it was known that the version of Artemis of EAP 7.0.0 did not work properly on OpenJ9-. This current issue is affecting various jobs running different OpenJDK versions.
> I'll send up a PR ignoring this test.
> The problem details:
> {code}
> java.lang.AssertionError: {"WFLYDC0074: Operation failed or was rolled back on all servers. Server failures:" => {"server-group" => {"other-server-group" => {"host" => {"slave" => {"server-one" => {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-1" => {
> "WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.naming.context.java.module.test.test.DefaultJMSConnectionFactory is missing [jboss.naming.context.java.jboss.DefaultJMSConnectionFactory]"],
> "WFLYCTL0288: One or more services were unable to start due to one or more indirect dependencies not being available." => {
> "Services that were unable to start:" => [
> "jboss.deployment.unit.\"test.war\".CdiValidatorFactoryService",
> "jboss.deployment.unit.\"test.war\".WeldStartService",
> "jboss.deployment.unit.\"test.war\".component.\"com.sun.faces.config.ConfigureListener\".START",
> "jboss.deployment.unit.\"test.war\".component.\"com.sun.faces.config.ConfigureListener\".WeldInstantiator",
> "jboss.deployment.unit.\"test.war\".component.\"javax.faces.webapp.FacetTag\".START",
> "jboss.deployment.unit.\"test.war\".component.\"javax.faces.webapp.FacetTag\".WeldInstantiator",
> "jboss.deployment.unit.\"test.war\".component.\"javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV\".START",
> "jboss.deployment.unit.\"test.war\".component.\"javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV\".WeldInstantiator",
> "jboss.deployment.unit.\"test.war\".component.\"javax.servlet.jsp.jstl.tlv.ScriptFreeTLV\".START",
> "jboss.deployment.unit.\"test.war\".component.\"javax.servlet.jsp.jstl.tlv.ScriptFreeTLV\".WeldInstantiator",
> "jboss.deployment.unit.\"test.war\".component.\"org.jboss.weld.servlet.WeldInitialListener\".START",
> "jboss.deployment.unit.\"test.war\".component.\"org.jboss.weld.servlet.WeldInitialListener\".WeldInstantiator",
> "jboss.deployment.unit.\"test.war\".component.\"org.jboss.weld.servlet.WeldTerminalListener\".START",
> "jboss.deployment.unit.\"test.war\".component.\"org.jboss.weld.servlet.WeldTerminalListener\".WeldInstantiator",
> "jboss.deployment.unit.\"test.war\".deploymentCompleteService",
> "jboss.deployment.unit.\"test.war\".jndiDependencyService",
> "jboss.undertow.deployment.default-server.default-host./test",
> "jboss.undertow.deployment.default-server.default-host./test.UndertowDeploymentInfoService"
> ],
> "Services that may be the cause:" => [
> "jboss.clustering.singleton.server.default",
> "jboss.naming.context.java.jboss.DefaultJMSConnectionFactory"
> ]
> }
> }}}}}}}}}
> {code}
> In the server.log of the /host=slave/server=server-one server:
> {code}
> 2020-07-17 08:48:06,358 INFO [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 42) AMQ221000: live Message Broker is starting with configuration Broker Configuration (clustered=true,journalDirectory=/store/work/tc-work/f5da3564a57e9d74/testsuite/mixed-domain/target/domains/MixedDomain700TestSuite/slave/servers/server-one/data/activemq/journal,bindingsDirectory=/store/work/tc-work/f5da3564a57e9d74/testsuite/mixed-domain/target/domains/MixedDomain700TestSuite/slave/servers/server-one/data/activemq/bindings,largeMessagesDirectory=/store/work/tc-work/f5da3564a57e9d74/testsuite/mixed-domain/target/domains/MixedDomain700TestSuite/slave/servers/server-one/data/activemq/largemessages,pagingDirectory=/store/work/tc-work/f5da3564a57e9d74/testsuite/mixed-domain/target/domains/MixedDomain700TestSuite/slave/servers/server-one/data/activemq/paging)
> 2020-07-17 08:48:06,378 INFO [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 42) AMQ221012: Using AIO Journal
> 2020-07-17 08:48:06,478 INFO [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 42) AMQ221043: Protocol module found: [artemis-server]. Adding protocol support for: CORE
> 2020-07-17 08:48:06,481 INFO [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 42) AMQ221043: Protocol module found: [artemis-hornetq-protocol]. Adding protocol support for: HORNETQ
> 2020-07-17 08:48:06,509 WARN [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 42) AMQ222010: Critical IO Error, shutting down the server. file=AIOSequentialFile:/store/work/tc-work/f5da3564a57e9d74/testsuite/mixed-domain/target/domains/MixedDomain700TestSuite/slave/servers/server-one/data/activemq/journal/activemq-data-1.amq.tmp, message=Cannot open file:Invalid argument: java.io.IOException: Cannot open file:Invalid argument
> at org.apache.activemq.artemis.jlibaio.LibaioContext.open(Native Method)
> at org.apache.activemq.artemis.jlibaio.LibaioContext.openFile(LibaioContext.java:291)
> at org.apache.activemq.artemis.jlibaio.LibaioContext.openFile(LibaioContext.java:274)
> at org.apache.activemq.artemis.core.io.aio.AIOSequentialFile.open(AIOSequentialFile.java:133)
> at org.apache.activemq.artemis.core.journal.impl.JournalFilesRepository.createFile0(JournalFilesRepository.java:590)
> at org.apache.activemq.artemis.core.journal.impl.JournalFilesRepository.createFile(JournalFilesRepository.java:543)
> at org.apache.activemq.artemis.core.journal.impl.JournalFilesRepository.ensureMinFiles(JournalFilesRepository.java:206)
> at org.apache.activemq.artemis.core.journal.impl.JournalImpl.setUpCurrentFile(JournalImpl.java:2652)
> at org.apache.activemq.artemis.core.journal.impl.JournalImpl.load(JournalImpl.java:1728)
> at org.apache.activemq.artemis.core.journal.impl.JournalImpl.load(JournalImpl.java:1126)
> at org.apache.activemq.artemis.core.journal.impl.JournalImpl.load(JournalImpl.java:1110)
> at org.apache.activemq.artemis.core.persistence.impl.journal.JournalStorageManager.loadMessageJournal(JournalStorageManager.java:1260)
> at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.loadJournals(ActiveMQServerImpl.java:1701)
> at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.initialisePart2(ActiveMQServerImpl.java:1595)
> at org.apache.activemq.artemis.core.server.impl.LiveOnlyActivation.run(LiveOnlyActivation.java:60)
> at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.start(ActiveMQServerImpl.java:393)
> at org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl.start(JMSServerManagerImpl.java:381)
> at org.wildfly.extension.messaging.activemq.jms.JMSService.doStart(JMSService.java:199)
> at org.wildfly.extension.messaging.activemq.jms.JMSService.access$000(JMSService.java:63)
> at org.wildfly.extension.messaging.activemq.jms.JMSService$1.run(JMSService.java:97)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 2 months
[JBoss JIRA] (WFLY-13684) Intermittent failures in MixedDomainDeployment700TestCase
by Radoslav Husar (Jira)
[ https://issues.redhat.com/browse/WFLY-13684?page=com.atlassian.jira.plugi... ]
Radoslav Husar edited comment on WFLY-13684 at 7/22/20 9:25 AM:
----------------------------------------------------------------
Removing 'testJsfWorks' from the issue summary since all of those tests fail frequently all together, e.g. [https://ci.wildfly.org/project.html?buildTypeId=&tab=testDetails&pr... the PR disabled the test entirely on non-Windows OSes.
was (Author: rhusar):
Removing 'testJsfWorks' form the summary since all of those tests fail frequently all together, e.g. [https://ci.wildfly.org/project.html?buildTypeId=&tab=testDetails&pr... the PR disabled the test entirely on non-Windows OSes.
> Intermittent failures in MixedDomainDeployment700TestCase
> ---------------------------------------------------------
>
> Key: WFLY-13684
> URL: https://issues.redhat.com/browse/WFLY-13684
> Project: WildFly
> Issue Type: Bug
> Components: JMS, Management
> Reporter: Brian Stansberry
> Assignee: Emmanuel Hugonnet
> Priority: Major
>
> Lots of failures starting July 16, 2020: https://ci.wildfly.org/project.html?projectId=WF&buildTypeId=&tab=testDet...
> This is the first failure in a set of 12-13 failures.
> Odd thing is nothing was merged into master after July 12, so why these started failing is unclear.
> WFLY-12649 was a similar issue-, but there it was known that the version of Artemis of EAP 7.0.0 did not work properly on OpenJ9-. This current issue is affecting various jobs running different OpenJDK versions.
> I'll send up a PR ignoring this test.
> The problem details:
> {code}
> java.lang.AssertionError: {"WFLYDC0074: Operation failed or was rolled back on all servers. Server failures:" => {"server-group" => {"other-server-group" => {"host" => {"slave" => {"server-one" => {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-1" => {
> "WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.naming.context.java.module.test.test.DefaultJMSConnectionFactory is missing [jboss.naming.context.java.jboss.DefaultJMSConnectionFactory]"],
> "WFLYCTL0288: One or more services were unable to start due to one or more indirect dependencies not being available." => {
> "Services that were unable to start:" => [
> "jboss.deployment.unit.\"test.war\".CdiValidatorFactoryService",
> "jboss.deployment.unit.\"test.war\".WeldStartService",
> "jboss.deployment.unit.\"test.war\".component.\"com.sun.faces.config.ConfigureListener\".START",
> "jboss.deployment.unit.\"test.war\".component.\"com.sun.faces.config.ConfigureListener\".WeldInstantiator",
> "jboss.deployment.unit.\"test.war\".component.\"javax.faces.webapp.FacetTag\".START",
> "jboss.deployment.unit.\"test.war\".component.\"javax.faces.webapp.FacetTag\".WeldInstantiator",
> "jboss.deployment.unit.\"test.war\".component.\"javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV\".START",
> "jboss.deployment.unit.\"test.war\".component.\"javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV\".WeldInstantiator",
> "jboss.deployment.unit.\"test.war\".component.\"javax.servlet.jsp.jstl.tlv.ScriptFreeTLV\".START",
> "jboss.deployment.unit.\"test.war\".component.\"javax.servlet.jsp.jstl.tlv.ScriptFreeTLV\".WeldInstantiator",
> "jboss.deployment.unit.\"test.war\".component.\"org.jboss.weld.servlet.WeldInitialListener\".START",
> "jboss.deployment.unit.\"test.war\".component.\"org.jboss.weld.servlet.WeldInitialListener\".WeldInstantiator",
> "jboss.deployment.unit.\"test.war\".component.\"org.jboss.weld.servlet.WeldTerminalListener\".START",
> "jboss.deployment.unit.\"test.war\".component.\"org.jboss.weld.servlet.WeldTerminalListener\".WeldInstantiator",
> "jboss.deployment.unit.\"test.war\".deploymentCompleteService",
> "jboss.deployment.unit.\"test.war\".jndiDependencyService",
> "jboss.undertow.deployment.default-server.default-host./test",
> "jboss.undertow.deployment.default-server.default-host./test.UndertowDeploymentInfoService"
> ],
> "Services that may be the cause:" => [
> "jboss.clustering.singleton.server.default",
> "jboss.naming.context.java.jboss.DefaultJMSConnectionFactory"
> ]
> }
> }}}}}}}}}
> {code}
> In the server.log of the /host=slave/server=server-one server:
> {code}
> 2020-07-17 08:48:06,358 INFO [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 42) AMQ221000: live Message Broker is starting with configuration Broker Configuration (clustered=true,journalDirectory=/store/work/tc-work/f5da3564a57e9d74/testsuite/mixed-domain/target/domains/MixedDomain700TestSuite/slave/servers/server-one/data/activemq/journal,bindingsDirectory=/store/work/tc-work/f5da3564a57e9d74/testsuite/mixed-domain/target/domains/MixedDomain700TestSuite/slave/servers/server-one/data/activemq/bindings,largeMessagesDirectory=/store/work/tc-work/f5da3564a57e9d74/testsuite/mixed-domain/target/domains/MixedDomain700TestSuite/slave/servers/server-one/data/activemq/largemessages,pagingDirectory=/store/work/tc-work/f5da3564a57e9d74/testsuite/mixed-domain/target/domains/MixedDomain700TestSuite/slave/servers/server-one/data/activemq/paging)
> 2020-07-17 08:48:06,378 INFO [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 42) AMQ221012: Using AIO Journal
> 2020-07-17 08:48:06,478 INFO [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 42) AMQ221043: Protocol module found: [artemis-server]. Adding protocol support for: CORE
> 2020-07-17 08:48:06,481 INFO [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 42) AMQ221043: Protocol module found: [artemis-hornetq-protocol]. Adding protocol support for: HORNETQ
> 2020-07-17 08:48:06,509 WARN [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 42) AMQ222010: Critical IO Error, shutting down the server. file=AIOSequentialFile:/store/work/tc-work/f5da3564a57e9d74/testsuite/mixed-domain/target/domains/MixedDomain700TestSuite/slave/servers/server-one/data/activemq/journal/activemq-data-1.amq.tmp, message=Cannot open file:Invalid argument: java.io.IOException: Cannot open file:Invalid argument
> at org.apache.activemq.artemis.jlibaio.LibaioContext.open(Native Method)
> at org.apache.activemq.artemis.jlibaio.LibaioContext.openFile(LibaioContext.java:291)
> at org.apache.activemq.artemis.jlibaio.LibaioContext.openFile(LibaioContext.java:274)
> at org.apache.activemq.artemis.core.io.aio.AIOSequentialFile.open(AIOSequentialFile.java:133)
> at org.apache.activemq.artemis.core.journal.impl.JournalFilesRepository.createFile0(JournalFilesRepository.java:590)
> at org.apache.activemq.artemis.core.journal.impl.JournalFilesRepository.createFile(JournalFilesRepository.java:543)
> at org.apache.activemq.artemis.core.journal.impl.JournalFilesRepository.ensureMinFiles(JournalFilesRepository.java:206)
> at org.apache.activemq.artemis.core.journal.impl.JournalImpl.setUpCurrentFile(JournalImpl.java:2652)
> at org.apache.activemq.artemis.core.journal.impl.JournalImpl.load(JournalImpl.java:1728)
> at org.apache.activemq.artemis.core.journal.impl.JournalImpl.load(JournalImpl.java:1126)
> at org.apache.activemq.artemis.core.journal.impl.JournalImpl.load(JournalImpl.java:1110)
> at org.apache.activemq.artemis.core.persistence.impl.journal.JournalStorageManager.loadMessageJournal(JournalStorageManager.java:1260)
> at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.loadJournals(ActiveMQServerImpl.java:1701)
> at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.initialisePart2(ActiveMQServerImpl.java:1595)
> at org.apache.activemq.artemis.core.server.impl.LiveOnlyActivation.run(LiveOnlyActivation.java:60)
> at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.start(ActiveMQServerImpl.java:393)
> at org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl.start(JMSServerManagerImpl.java:381)
> at org.wildfly.extension.messaging.activemq.jms.JMSService.doStart(JMSService.java:199)
> at org.wildfly.extension.messaging.activemq.jms.JMSService.access$000(JMSService.java:63)
> at org.wildfly.extension.messaging.activemq.jms.JMSService$1.run(JMSService.java:97)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 2 months
[JBoss JIRA] (WFLY-13684) Intermittent failures in MixedDomainDeployment700TestCase
by Radoslav Husar (Jira)
[ https://issues.redhat.com/browse/WFLY-13684?page=com.atlassian.jira.plugi... ]
Radoslav Husar updated WFLY-13684:
----------------------------------
Summary: Intermittent failures in MixedDomainDeployment700TestCase (was: Intermittent failures in MixedDomainDeployment700TestCase.testJsfWorks)
> Intermittent failures in MixedDomainDeployment700TestCase
> ---------------------------------------------------------
>
> Key: WFLY-13684
> URL: https://issues.redhat.com/browse/WFLY-13684
> Project: WildFly
> Issue Type: Bug
> Components: JMS, Management
> Reporter: Brian Stansberry
> Assignee: Emmanuel Hugonnet
> Priority: Major
>
> Lots of failures starting July 16, 2020: https://ci.wildfly.org/project.html?projectId=WF&buildTypeId=&tab=testDet...
> This is the first failure in a set of 12-13 failures.
> Odd thing is nothing was merged into master after July 12, so why these started failing is unclear.
> WFLY-12649 was a similar issue-, but there it was known that the version of Artemis of EAP 7.0.0 did not work properly on OpenJ9-. This current issue is affecting various jobs running different OpenJDK versions.
> I'll send up a PR ignoring this test.
> The problem details:
> {code}
> java.lang.AssertionError: {"WFLYDC0074: Operation failed or was rolled back on all servers. Server failures:" => {"server-group" => {"other-server-group" => {"host" => {"slave" => {"server-one" => {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-1" => {
> "WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.naming.context.java.module.test.test.DefaultJMSConnectionFactory is missing [jboss.naming.context.java.jboss.DefaultJMSConnectionFactory]"],
> "WFLYCTL0288: One or more services were unable to start due to one or more indirect dependencies not being available." => {
> "Services that were unable to start:" => [
> "jboss.deployment.unit.\"test.war\".CdiValidatorFactoryService",
> "jboss.deployment.unit.\"test.war\".WeldStartService",
> "jboss.deployment.unit.\"test.war\".component.\"com.sun.faces.config.ConfigureListener\".START",
> "jboss.deployment.unit.\"test.war\".component.\"com.sun.faces.config.ConfigureListener\".WeldInstantiator",
> "jboss.deployment.unit.\"test.war\".component.\"javax.faces.webapp.FacetTag\".START",
> "jboss.deployment.unit.\"test.war\".component.\"javax.faces.webapp.FacetTag\".WeldInstantiator",
> "jboss.deployment.unit.\"test.war\".component.\"javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV\".START",
> "jboss.deployment.unit.\"test.war\".component.\"javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV\".WeldInstantiator",
> "jboss.deployment.unit.\"test.war\".component.\"javax.servlet.jsp.jstl.tlv.ScriptFreeTLV\".START",
> "jboss.deployment.unit.\"test.war\".component.\"javax.servlet.jsp.jstl.tlv.ScriptFreeTLV\".WeldInstantiator",
> "jboss.deployment.unit.\"test.war\".component.\"org.jboss.weld.servlet.WeldInitialListener\".START",
> "jboss.deployment.unit.\"test.war\".component.\"org.jboss.weld.servlet.WeldInitialListener\".WeldInstantiator",
> "jboss.deployment.unit.\"test.war\".component.\"org.jboss.weld.servlet.WeldTerminalListener\".START",
> "jboss.deployment.unit.\"test.war\".component.\"org.jboss.weld.servlet.WeldTerminalListener\".WeldInstantiator",
> "jboss.deployment.unit.\"test.war\".deploymentCompleteService",
> "jboss.deployment.unit.\"test.war\".jndiDependencyService",
> "jboss.undertow.deployment.default-server.default-host./test",
> "jboss.undertow.deployment.default-server.default-host./test.UndertowDeploymentInfoService"
> ],
> "Services that may be the cause:" => [
> "jboss.clustering.singleton.server.default",
> "jboss.naming.context.java.jboss.DefaultJMSConnectionFactory"
> ]
> }
> }}}}}}}}}
> {code}
> In the server.log of the /host=slave/server=server-one server:
> {code}
> 2020-07-17 08:48:06,358 INFO [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 42) AMQ221000: live Message Broker is starting with configuration Broker Configuration (clustered=true,journalDirectory=/store/work/tc-work/f5da3564a57e9d74/testsuite/mixed-domain/target/domains/MixedDomain700TestSuite/slave/servers/server-one/data/activemq/journal,bindingsDirectory=/store/work/tc-work/f5da3564a57e9d74/testsuite/mixed-domain/target/domains/MixedDomain700TestSuite/slave/servers/server-one/data/activemq/bindings,largeMessagesDirectory=/store/work/tc-work/f5da3564a57e9d74/testsuite/mixed-domain/target/domains/MixedDomain700TestSuite/slave/servers/server-one/data/activemq/largemessages,pagingDirectory=/store/work/tc-work/f5da3564a57e9d74/testsuite/mixed-domain/target/domains/MixedDomain700TestSuite/slave/servers/server-one/data/activemq/paging)
> 2020-07-17 08:48:06,378 INFO [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 42) AMQ221012: Using AIO Journal
> 2020-07-17 08:48:06,478 INFO [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 42) AMQ221043: Protocol module found: [artemis-server]. Adding protocol support for: CORE
> 2020-07-17 08:48:06,481 INFO [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 42) AMQ221043: Protocol module found: [artemis-hornetq-protocol]. Adding protocol support for: HORNETQ
> 2020-07-17 08:48:06,509 WARN [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 42) AMQ222010: Critical IO Error, shutting down the server. file=AIOSequentialFile:/store/work/tc-work/f5da3564a57e9d74/testsuite/mixed-domain/target/domains/MixedDomain700TestSuite/slave/servers/server-one/data/activemq/journal/activemq-data-1.amq.tmp, message=Cannot open file:Invalid argument: java.io.IOException: Cannot open file:Invalid argument
> at org.apache.activemq.artemis.jlibaio.LibaioContext.open(Native Method)
> at org.apache.activemq.artemis.jlibaio.LibaioContext.openFile(LibaioContext.java:291)
> at org.apache.activemq.artemis.jlibaio.LibaioContext.openFile(LibaioContext.java:274)
> at org.apache.activemq.artemis.core.io.aio.AIOSequentialFile.open(AIOSequentialFile.java:133)
> at org.apache.activemq.artemis.core.journal.impl.JournalFilesRepository.createFile0(JournalFilesRepository.java:590)
> at org.apache.activemq.artemis.core.journal.impl.JournalFilesRepository.createFile(JournalFilesRepository.java:543)
> at org.apache.activemq.artemis.core.journal.impl.JournalFilesRepository.ensureMinFiles(JournalFilesRepository.java:206)
> at org.apache.activemq.artemis.core.journal.impl.JournalImpl.setUpCurrentFile(JournalImpl.java:2652)
> at org.apache.activemq.artemis.core.journal.impl.JournalImpl.load(JournalImpl.java:1728)
> at org.apache.activemq.artemis.core.journal.impl.JournalImpl.load(JournalImpl.java:1126)
> at org.apache.activemq.artemis.core.journal.impl.JournalImpl.load(JournalImpl.java:1110)
> at org.apache.activemq.artemis.core.persistence.impl.journal.JournalStorageManager.loadMessageJournal(JournalStorageManager.java:1260)
> at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.loadJournals(ActiveMQServerImpl.java:1701)
> at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.initialisePart2(ActiveMQServerImpl.java:1595)
> at org.apache.activemq.artemis.core.server.impl.LiveOnlyActivation.run(LiveOnlyActivation.java:60)
> at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.start(ActiveMQServerImpl.java:393)
> at org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl.start(JMSServerManagerImpl.java:381)
> at org.wildfly.extension.messaging.activemq.jms.JMSService.doStart(JMSService.java:199)
> at org.wildfly.extension.messaging.activemq.jms.JMSService.access$000(JMSService.java:63)
> at org.wildfly.extension.messaging.activemq.jms.JMSService$1.run(JMSService.java:97)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 2 months
[JBoss JIRA] (DROOLS-5522) Fix InternalKieModule.createKieModule
by Gabriele Cardosi (Jira)
[ https://issues.redhat.com/browse/DROOLS-5522?page=com.atlassian.jira.plug... ]
Gabriele Cardosi updated DROOLS-5522:
-------------------------------------
Description:
{code:java}
org.drools.compiler.kie.builder.impl.InternalKieModule.createKieModule(ReleaseId releaseId, File jar)
{code}
has a couple of issues
1) there is not a check on the actual type of File received as parameter: it expects it to be a "jar" - but this is not checked anywhere - so
{code:java}
ZipFile zipFile = new ZipFile(jar)
{code}
throws an exception whenever the given file is not a "jar"
2) every exceptions are catch and simply logged; but it seems that whatever exception may happen inside this if
{code:java}
if (zipEntry != null) {
KieModuleModel kieModuleModel = KieModuleModelImpl.fromXML( zipFile.getInputStream( zipEntry ) );
setDefaultsforEmptyKieModule( kieModuleModel );
return kieModuleModel != null ? InternalKieModuleProvider.get( adapt( releaseId ), kieModuleModel, jar ) : null;
}
{code}
it is actually a grave exception, since it means that it was impossible to retrieve an expected KieModule out of a given "kjar" (we know it is a kjar because zipEntry != null)
was:
{code:java}
org.drools.compiler.kie.builder.impl.InternalKieModule.createKieModule(ReleaseId releaseId, File jar)
{code}
has a couple of issues
1) there is not a check on the actual type of File received as parameter: it expects it to be a "jar" - but this is not checked anywhere - so
{code:java}
ZipFile zipFile = new ZipFile(jar)
{code}
throws an exception whenever the given file is not a "jar"
2) every exceptions are catch and simply logged; but it seems that whatever exception may happen inside this if
{code:java}
if (zipEntry != null) {
KieModuleModel kieModuleModel = KieModuleModelImpl.fromXML( zipFile.getInputStream( zipEntry ) );
setDefaultsforEmptyKieModule( kieModuleModel );
return kieModuleModel != null ? InternalKieModuleProvider.get( adapt( releaseId ), kieModuleModel, jar ) : null;
}
{code}
it is actually a grave exception, since it means that it was impossible to retrieve an expected KieModule out of a given "kjar" (we know if is a kjar because zipEntry != null)
> Fix InternalKieModule.createKieModule
> -------------------------------------
>
> Key: DROOLS-5522
> URL: https://issues.redhat.com/browse/DROOLS-5522
> Project: Drools
> Issue Type: Task
> Reporter: Gabriele Cardosi
> Assignee: Mario Fusco
> Priority: Major
>
> {code:java}
> org.drools.compiler.kie.builder.impl.InternalKieModule.createKieModule(ReleaseId releaseId, File jar)
> {code}
> has a couple of issues
> 1) there is not a check on the actual type of File received as parameter: it expects it to be a "jar" - but this is not checked anywhere - so
> {code:java}
> ZipFile zipFile = new ZipFile(jar)
> {code}
> throws an exception whenever the given file is not a "jar"
> 2) every exceptions are catch and simply logged; but it seems that whatever exception may happen inside this if
> {code:java}
> if (zipEntry != null) {
> KieModuleModel kieModuleModel = KieModuleModelImpl.fromXML( zipFile.getInputStream( zipEntry ) );
> setDefaultsforEmptyKieModule( kieModuleModel );
> return kieModuleModel != null ? InternalKieModuleProvider.get( adapt( releaseId ), kieModuleModel, jar ) : null;
> }
> {code}
> it is actually a grave exception, since it means that it was impossible to retrieve an expected KieModule out of a given "kjar" (we know it is a kjar because zipEntry != null)
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 2 months
[JBoss JIRA] (DROOLS-5522) Fix InternalKieModule.createKieModule
by Gabriele Cardosi (Jira)
Gabriele Cardosi created DROOLS-5522:
----------------------------------------
Summary: Fix InternalKieModule.createKieModule
Key: DROOLS-5522
URL: https://issues.redhat.com/browse/DROOLS-5522
Project: Drools
Issue Type: Task
Reporter: Gabriele Cardosi
Assignee: Mario Fusco
{code:java}
org.drools.compiler.kie.builder.impl.InternalKieModule.createKieModule(ReleaseId releaseId, File jar)
{code}
has a couple of issues
1) there is not a check on the actual type of File received as parameter: it expects it to be a "jar" - but this is not checked anywhere - so
{code:java}
ZipFile zipFile = new ZipFile(jar)
{code}
throws an exception whenever the given file is not a "jar"
2) every exceptions are catch and simply logged; but it seems that whatever exception may happen inside this if
{code:java}
if (zipEntry != null) {
KieModuleModel kieModuleModel = KieModuleModelImpl.fromXML( zipFile.getInputStream( zipEntry ) );
setDefaultsforEmptyKieModule( kieModuleModel );
return kieModuleModel != null ? InternalKieModuleProvider.get( adapt( releaseId ), kieModuleModel, jar ) : null;
}
{code}
it is actually a grave exception, since it means that it was impossible to retrieve an expected KieModule out of a given "kjar" (we know if is a kjar because zipEntry != null)
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 2 months
[JBoss JIRA] (WFCORE-5022) The /subsystem=elytron/policy=* can be simplified a lot further
by Darran Lofthouse (Jira)
[ https://issues.redhat.com/browse/WFCORE-5022?page=com.atlassian.jira.plug... ]
Darran Lofthouse updated WFCORE-5022:
-------------------------------------
Fix Version/s: (was: 13.0.0.Beta3)
> The /subsystem=elytron/policy=* can be simplified a lot further
> ---------------------------------------------------------------
>
> Key: WFCORE-5022
> URL: https://issues.redhat.com/browse/WFCORE-5022
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Security
> Affects Versions: 12.0.1.Final
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Priority: Major
>
> At the moment this resource is quite verbose but the tasks it performs are very simple.
> {code:java}
> [standalone@localhost:9990 /] /subsystem=elytron/policy=*:read-resource-description
> {
> "outcome" => "success",
> "result" => [{
> "address" => [
> ("subsystem" => "elytron"),
> ("policy" => "*")
> ],
> "outcome" => "success",
> "result" => {
> "description" => "A definition that sets up a policy provider.",
> "max-occurs" => 1,
> "capabilities" => [{
> "name" => "org.wildfly.security.policy",
> "dynamic" => false
> }],
> "access-constraints" => {
> "sensitive" => {"elytron-security" => {"type" => "elytron"}},
> "application" => {"elytron-security" => {"type" => "elytron"}}
> },
> "attributes" => {
> "custom-policy" => {
> "type" => OBJECT,
> "description" => "A custom policy provider definition.",
> "expressions-allowed" => false,
> "required" => true,
> "nillable" => true,
> "alternatives" => ["jacc-policy"],
> "value-type" => {
> "class-name" => {
> "type" => STRING,
> "description" => "The name of a java.security.Policy implementation referencing a policy provider.",
> "expressions-allowed" => false,
> "required" => true,
> "nillable" => false,
> "min-length" => 1L,
> "max-length" => 2147483647L
> },
> "module" => {
> "type" => STRING,
> "description" => "The name of the module to load the provider from.",
> "expressions-allowed" => false,
> "required" => false,
> "nillable" => true,
> "min-length" => 1L,
> "max-length" => 2147483647L
> }
> },
> "access-type" => "read-write",
> "storage" => "configuration",
> "restart-required" => "no-services"
> },
> "default-policy" => {
> "type" => STRING,
> "description" => "Not used.",
> "expressions-allowed" => false,
> "required" => false,
> "nillable" => true,
> "min-length" => 1L,
> "max-length" => 2147483647L,
> "deprecated" => {
> "since" => "1.2.0",
> "reason" => "The 'default-policy' attribute is ignored, as a policy resource should be configured with only one policy."
> },
> "access-type" => "read-write",
> "storage" => "configuration",
> "restart-required" => "no-services"
> },
> "jacc-policy" => {
> "type" => OBJECT,
> "description" => "A policy provider definition that sets up JACC and related services.",
> "expressions-allowed" => false,
> "required" => true,
> "nillable" => true,
> "alternatives" => ["custom-policy"],
> "value-type" => {
> "policy" => {
> "type" => STRING,
> "description" => "The name of a java.security.Policy implementation referencing a policy provider.",
> "expressions-allowed" => false,
> "required" => false,
> "nillable" => true,
> "default" => "org.wildfly.security.authz.jacc.JaccDelegatingPolicy",
> "min-length" => 1L,
> "max-length" => 2147483647L
> },
> "configuration-factory" => {
> "type" => STRING,
> "description" => "The name of a javax.security.jacc.PolicyConfigurationFactory implementation referencing a policy configuration factory provider.",
> "expressions-allowed" => false,
> "required" => false,
> "nillable" => true,
> "default" => "org.wildfly.security.authz.jacc.ElytronPolicyConfigurationFactory",
> "min-length" => 1L,
> "max-length" => 2147483647L
> },
> "module" => {
> "type" => STRING,
> "description" => "The name of the module to load the provider from.",
> "expressions-allowed" => false,
> "required" => false,
> "nillable" => true,
> "min-length" => 1L,
> "max-length" => 2147483647L
> }
> },
> "access-type" => "read-write",
> "storage" => "configuration",
> "restart-required" => "no-services"
> }
> },
> "operations" => undefined,
> "notifications" => undefined,
> "children" => {}
> }
> }]
> }
> {code}
> Firstly it only makes sense to have a single policy defined, the outcome of this resource is JVM wide registration so multiple definitions would lead to undefined behaviour.
> Secondly this provides two primary functions.
> 1. Instantation of [https://docs.oracle.com/javase/8/docs/api/java/security/Policy.html] and registration via a call to [https://docs.oracle.com/javase/8/docs/api/java/security/Policy.html#setPo...]
> This first point needs a class name for the policy as well as a module.
> 2. Registration of the JVM wide [https://jakarta.ee/specifications/platform/8/apidocs/javax/security/jacc/...] again needing a classname and module.
> This is also not working correctly but the immediate bug is being addressed under WFCORE-5020
> The JACC APIs don't actually provide a nice way to register this so maybe this is something we should also propose via the spec, but this piece is effectively a class name and module name.
> We have ended up with custom and jacc variants as alternatives. Really both variants are optional but if the resource is defined at least one must be set.
> It may make sense for JACC to move to it's own subsystem for a couple of reasons.
> The JVM wide policy will likely need to be possible in both subsystems but use a capability to ensure it is defined in only one. We probably should move it's registration into the boot operations so registration is complete before DUPs begin.
> The PolicyConfigurationFactory would then be in a JACC subsystem only. Again handling during a boot operation may be preferable otherwise we see issues like WFLY-13615 but failing that ensuring the deployment depend upon the registration happening may be sufficient.
> Additionally the resource has some hard coded class names for the Policy and PolicyConfigurationFactory, we probably should not have these as class names and instead default to them if not defined - this means we still need a way to optionally activate their registration if JACC is required on the server.
> It probably should also be possible to independently set the module for Policy and PolicyContextHandler as these will presently be shared.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 2 months
[JBoss JIRA] (WFLY-12815) Wildfly 13 - Thread local state corrupted by deployed application explosion during session timeout leading to WELD-001304 - More than one context active for scope type javax.enterprise.context.SessionScoped
by Matěj Novotný (Jira)
[ https://issues.redhat.com/browse/WFLY-12815?page=com.atlassian.jira.plugi... ]
Matěj Novotný commented on WFLY-12815:
--------------------------------------
{quote}I am only not sure about the idea that we should normally be catching exceptions to prevent undersired behaivor like this one. In general, we always allow the application server to be "hammered" by our application exceptions,
{quote}
Well, that's what servlet spec says about it. And CDI integration into servlet via these very events so if you blow up the chain, you blow up the only reliable way CDI/Weld has of telling what is going on with requests and sessions. We already have some safety latches for request cases from what I saw but you there is likely always a case where it won't quite work as we will simply be unable to tell what state is it in and whether it is a serious error or if we should just (almost) silently clean up.
BTW I already have a Weld PR up - [https://github.com/weld/core/pull/2005/files]
I am testing it now against Weld TS and WFLY TS and will drop a comment once I know it is good. I can also give you the details on how to patch newer Weld into WFLY. But it is still a fix for WFLY 20/21 as the version 13 you reported it against is pretty ancient at this point (and uses way older Weld as well).
> Wildfly 13 - Thread local state corrupted by deployed application explosion during session timeout leading to WELD-001304 - More than one context active for scope type javax.enterprise.context.SessionScoped
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-12815
> URL: https://issues.redhat.com/browse/WFLY-12815
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 13.0.0.Final
> Environment: Environment independent the issue, it is purely a logical problem
> Reporter: NUNO GODINHO DE MATOS
> Assignee: Matěj Novotný
> Priority: Major
> Attachments: sourceCodeToSendToWildfly.7z
>
>
> The full description of the problem can be seen in stack overflow.
> Please consulder the issue:
> https://stackoverflow.com/questions/58930939/wildflt-13-weld-001304-more-...
> SUMMARY:
> (1) Setup you wildfly to have a session timeout of 1 minute - so that you can esaily make your http sessions timeout
> (2) Program in your WAR application a sessionDestroyed listener that will be broken.
> In our case whenever the session is timing out, we have some code that explodes in wildfly and not in weblogic because it expected for the RequestScope context to be active, but apparently in wildfly when Undertow to start killing of a session the request scope context is not made active so that caused our session destroyed handling to break
> (3) Do this sufficient amount of times to corrupted as may threads in the thread pool as possible
> (4) Now try to interact with your application making use of some session scoped beans .
> If you travel to ay sort of view that makes use of a session scoped bean that thread will be broken with the exception that multiple session scope context implementation are active.
> But this exception will only come out and aply if the thread handling the HTTP request is one of the threads that in the past were used by undertow to handle the session timeout.
> The only threads that have been corrupted forever are those that had a broken sessin timeout
> Explanation for the issue:
> - When the session timeout is being orchestrated by underdow, wildfly is activating a special HttpSessionDescrutionContext and making it active.
> This ACTIVE TRUE/FALSE flag is a ThreadLocal variable.
> So the activation of the scope context is marked on the thread itself.
> - When the thread blows up the thread context will remain for as long at the thread lives
> - in a future request the flag had that thread local variable active already.
> So when the BeanManagaerImpl is hunting to the one and only active http session context it finds the traditional happy path http session context active plust the DestructionSession context that was activated in a previous call.
> All of the illustrative stack traces that facilitate the comprehention of the issue are shown in the stack overflow thread.
> I am of the oppinion that errors like this can happen in the deployed applications.
> It would not hurt if wildfly would somehow be able to ensure that the thread that hand an explosion in a previous request is not corrupted when it is used to handle new requests.
> Many thanks for having a look.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 2 months