[JBoss JIRA] (WFLY-10078) [Artemis 2.x Upgrade] Replicated HA: Live and Backup do not form cluster and initial synchronization is not triggered
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-10078?page=com.atlassian.jira.plugin... ]
Jeff Mesnil updated WFLY-10078:
-------------------------------
Affects Version/s: (was: 13.0.0.Beta1)
> [Artemis 2.x Upgrade] Replicated HA: Live and Backup do not form cluster and initial synchronization is not triggered
> ---------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-10078
> URL: https://issues.jboss.org/browse/WFLY-10078
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Reporter: Erich Duda
> Assignee: Jeff Mesnil
> Priority: Blocker
> Labels: activemq, feature-branch-blocker
> Attachments: server1-trace.log, server1.log, server2-trace.log, server2.log
>
>
> Across all replicated HA tests I often see an issue that initial synchronization between Live and Backup was not triggered.
> *Scenario*
> # There are two Wildfly servers configured as replicated Live-Backup pair.
> # Live server is killed/shutdown
> *Expectation:* Backup server becomes active.
> *Reality:* Backup server does not become active, because initial synchronization with Live server was not triggered.
> *Users impact:* Replicated HA feature doesn't work properly.
> *Blocker* priority was set because this is regression against previous Wildfly releases.
> *Detail description of the issue*
> In the trace log there is last message from the {{SharedNothingBackupActivation}} which says that it is waiting on cluster connection. It is interested that JGroups subsystem is booting after this message was logged. However I am not sure if this could cause the issue.
> {code}
> 13:42:06,489 DEBUG [org.apache.activemq.artemis.core.client.impl.Topology] (AMQ119000: Activation for server ActiveMQServerImpl::serverUUID=null) Topology@6a834ff0[owner=ServerLocatorImpl [initialConnectors=[],
> discoveryGroupConfiguration=DiscoveryGroupConfiguration{name='dg-group1', refreshTimeout=10000, discoveryInitialWaitTimeout=10000}]] is sending topology to org.apache.activemq.artemis.core.server.impl.NamedLiveN
> odeLocatorForReplication@38150570
> 13:42:06,489 TRACE [org.apache.activemq.artemis.core.server.impl.SharedNothingBackupActivation] (AMQ119000: Activation for server ActiveMQServerImpl::serverUUID=null) Waiting on cluster connection
> 13:42:06,502 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-6) ISPN000078: Starting JGroups channel ejb
> 13:42:06,503 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-7) ISPN000078: Starting JGroups channel ejb
> 13:42:06,504 INFO [org.infinispan.CLUSTER] (MSC service thread 1-6) ISPN000094: Received new cluster view for channel ejb: [node-1|1] (2) [node-1, node-2]
> 13:42:06,506 INFO [org.infinispan.CLUSTER] (MSC service thread 1-7) ISPN000094: Received new cluster view for channel ejb: [node-1|1] (2) [node-1, node-2]
> 13:42:06,506 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-8) ISPN000078: Starting JGroups channel ejb
> 13:42:06,506 INFO [org.infinispan.CLUSTER] (MSC service thread 1-8) ISPN000094: Received new cluster view for channel ejb: [node-1|1] (2) [node-1, node-2]
> 13:42:06,510 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-3) ISPN000078: Starting JGroups channel ejb
> 13:42:06,510 INFO [org.infinispan.CLUSTER] (MSC service thread 1-3) ISPN000094: Received new cluster view for channel ejb: [node-1|1] (2) [node-1, node-2]
> 13:42:06,516 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-8) ISPN000079: Channel ejb local address is node-2, physical addresses are [127.0.0.1:56200]
> 13:42:06,527 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-3) ISPN000079: Channel ejb local address is node-2, physical addresses are [127.0.0.1:56200]
> 13:42:06,527 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-7) ISPN000079: Channel ejb local address is node-2, physical addresses are [127.0.0.1:56200]
> 13:42:06,529 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-6) ISPN000079: Channel ejb local address is node-2, physical addresses are [127.0.0.1:56200]
> 13:42:06,551 INFO [org.infinispan.factories.GlobalComponentRegistry] (MSC service thread 1-7) ISPN000128: Infinispan version: Infinispan 'Gaina' 9.2.0.Final
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 10 months
[JBoss JIRA] (WFLY-10153) Replicated HA: Live and Backup do not form cluster and initial synchronization is not triggered
by Jeff Mesnil (JIRA)
Jeff Mesnil created WFLY-10153:
----------------------------------
Summary: Replicated HA: Live and Backup do not form cluster and initial synchronization is not triggered
Key: WFLY-10153
URL: https://issues.jboss.org/browse/WFLY-10153
Project: WildFly
Issue Type: Bug
Components: JMS
Affects Versions: 13.0.0.Beta1
Reporter: Erich Duda
Assignee: Jeff Mesnil
Priority: Blocker
Across all replicated HA tests I often see an issue that initial synchronization between Live and Backup was not triggered.
*Scenario*
# There are two Wildfly servers configured as replicated Live-Backup pair.
# Live server is killed/shutdown
*Expectation:* Backup server becomes active.
*Reality:* Backup server does not become active, because initial synchronization with Live server was not triggered.
*Users impact:* Replicated HA feature doesn't work properly.
*Blocker* priority was set because this is regression against previous Wildfly releases.
*Detail description of the issue*
In the trace log there is last message from the {{SharedNothingBackupActivation}} which says that it is waiting on cluster connection. It is interested that JGroups subsystem is booting after this message was logged. However I am not sure if this could cause the issue.
{code}
13:42:06,489 DEBUG [org.apache.activemq.artemis.core.client.impl.Topology] (AMQ119000: Activation for server ActiveMQServerImpl::serverUUID=null) Topology@6a834ff0[owner=ServerLocatorImpl [initialConnectors=[],
discoveryGroupConfiguration=DiscoveryGroupConfiguration{name='dg-group1', refreshTimeout=10000, discoveryInitialWaitTimeout=10000}]] is sending topology to org.apache.activemq.artemis.core.server.impl.NamedLiveN
odeLocatorForReplication@38150570
13:42:06,489 TRACE [org.apache.activemq.artemis.core.server.impl.SharedNothingBackupActivation] (AMQ119000: Activation for server ActiveMQServerImpl::serverUUID=null) Waiting on cluster connection
13:42:06,502 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-6) ISPN000078: Starting JGroups channel ejb
13:42:06,503 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-7) ISPN000078: Starting JGroups channel ejb
13:42:06,504 INFO [org.infinispan.CLUSTER] (MSC service thread 1-6) ISPN000094: Received new cluster view for channel ejb: [node-1|1] (2) [node-1, node-2]
13:42:06,506 INFO [org.infinispan.CLUSTER] (MSC service thread 1-7) ISPN000094: Received new cluster view for channel ejb: [node-1|1] (2) [node-1, node-2]
13:42:06,506 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-8) ISPN000078: Starting JGroups channel ejb
13:42:06,506 INFO [org.infinispan.CLUSTER] (MSC service thread 1-8) ISPN000094: Received new cluster view for channel ejb: [node-1|1] (2) [node-1, node-2]
13:42:06,510 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-3) ISPN000078: Starting JGroups channel ejb
13:42:06,510 INFO [org.infinispan.CLUSTER] (MSC service thread 1-3) ISPN000094: Received new cluster view for channel ejb: [node-1|1] (2) [node-1, node-2]
13:42:06,516 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-8) ISPN000079: Channel ejb local address is node-2, physical addresses are [127.0.0.1:56200]
13:42:06,527 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-3) ISPN000079: Channel ejb local address is node-2, physical addresses are [127.0.0.1:56200]
13:42:06,527 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-7) ISPN000079: Channel ejb local address is node-2, physical addresses are [127.0.0.1:56200]
13:42:06,529 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-6) ISPN000079: Channel ejb local address is node-2, physical addresses are [127.0.0.1:56200]
13:42:06,551 INFO [org.infinispan.factories.GlobalComponentRegistry] (MSC service thread 1-7) ISPN000128: Infinispan version: Infinispan 'Gaina' 9.2.0.Final
{code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 10 months
[JBoss JIRA] (WFLY-10152) Last value queues do not work
by Jeff Mesnil (JIRA)
Jeff Mesnil created WFLY-10152:
----------------------------------
Summary: Last value queues do not work
Key: WFLY-10152
URL: https://issues.jboss.org/browse/WFLY-10152
Project: WildFly
Issue Type: Bug
Components: JMS
Reporter: Martin Styk
Assignee: Martyn Taylor
Priority: Blocker
Last value queues are not working as expected.
# Set {{last-value-queue="true"}} for an address settings {{#}}
# Send 10 messages with {{message.setStringProperty("_AMQ_LVQ_NAME", "myProperty");}}
# Receiver receives 10 messages. (it is expected to receive the single message)
This looks like broker related regression against Artemis 1.5.
Wildfly: {{https://github.com/jmesnil/wildfly/tree/WFLY-9407_upgrade_artemis_2.4.0_with_prefix}} (06c878a313d3cad323889d017e60fd5533204d1a)
Artemis: upstreadm master (577b62d5210cdcc0f86ab9bb1b24e944c877dfe7)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 10 months
[JBoss JIRA] (DROOLS-1663) Kie DMN doesn't support IMPORT decisions between DMN files
by Matteo Mortari (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1663?page=com.atlassian.jira.plugi... ]
Matteo Mortari updated DROOLS-1663:
-----------------------------------
Attachment: dmn import defaults.odt
> Kie DMN doesn't support IMPORT decisions between DMN files
> ----------------------------------------------------------
>
> Key: DROOLS-1663
> URL: https://issues.jboss.org/browse/DROOLS-1663
> Project: Drools
> Issue Type: Enhancement
> Components: dmn engine
> Reporter: Stylianos Koussouris
> Assignee: Matteo Mortari
> Attachments: IMG_2197.jpg, IMG_2198.jpg, IMG_2199.jpg, dmn import defaults.odt
>
>
> DMN Spec 1.1
> Page 40.
> import: Import [*] This attribute is used to import externally defined elements and
> make them available for use by elements in this Definitions.
> Section 6.3.3 Import metamodel
> The aim here is to be able to import one Decision defined in a separate DMN into another where it is used as a supporting decision and is referenced (RequiredDecision)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 10 months
[JBoss JIRA] (DROOLS-1663) Kie DMN doesn't support IMPORT decisions between DMN files
by Matteo Mortari (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1663?page=com.atlassian.jira.plugi... ]
Matteo Mortari commented on DROOLS-1663:
----------------------------------------
Raised PR to align *_defaults_* of DMN Import element attributes to the following requirement:
{quote}The "drools:name" property should never be used to lookup a model,
it should be used exclusively to assign an alias to whatever model is
imported, otherwise we would be overloading its semantics.{quote}
Summarized in attachment: [^dmn import defaults.odt]
PR: https://github.com/kiegroup/drools/pull/1846
> Kie DMN doesn't support IMPORT decisions between DMN files
> ----------------------------------------------------------
>
> Key: DROOLS-1663
> URL: https://issues.jboss.org/browse/DROOLS-1663
> Project: Drools
> Issue Type: Enhancement
> Components: dmn engine
> Reporter: Stylianos Koussouris
> Assignee: Matteo Mortari
> Attachments: IMG_2197.jpg, IMG_2198.jpg, IMG_2199.jpg, dmn import defaults.odt
>
>
> DMN Spec 1.1
> Page 40.
> import: Import [*] This attribute is used to import externally defined elements and
> make them available for use by elements in this Definitions.
> Section 6.3.3 Import metamodel
> The aim here is to be able to import one Decision defined in a separate DMN into another where it is used as a supporting decision and is referenced (RequiredDecision)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 10 months
[JBoss JIRA] (WFLY-8620) wildfly-bean-validation LazyValidatorFactoryTestCase test failed when running with JDK9
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFLY-8620?page=com.atlassian.jira.plugin.... ]
David Lloyd commented on WFLY-8620:
-----------------------------------
[~zhfeng] are you working on this issue or can someone else take it?
> wildfly-bean-validation LazyValidatorFactoryTestCase test failed when running with JDK9
> ---------------------------------------------------------------------------------------
>
> Key: WFLY-8620
> URL: https://issues.jboss.org/browse/WFLY-8620
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Reporter: Amos Feng
> Assignee: Amos Feng
> Priority: Critical
> Labels: Java9
>
> {noformat}
> Running org.jboss.as.ee.beanvalidation.LazyValidatorFactoryTestCase
> Tests run: 2, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.467 sec <<< FAILURE! - in org.jboss.as.ee.beanvalidation.LazyValidatorFactoryTestCase
> testSpecificProviderCanBeConfiguredInValidationXml(org.jboss.as.ee.beanvalidation.LazyValidatorFactoryTestCase) Time elapsed: 0.283 sec <<< ERROR!
> javax.validation.ValidationException: HV000100: Unable to parse META-INF/validation.xml.
> at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:533)
> at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:186)
> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:476)
> at java.base/java.lang.Class.forName0(Native Method)
> at java.base/java.lang.Class.forName(Class.java:292)
> at javax.xml.bind.ContextFinder.safeLoadClass(ContextFinder.java:508)
> at javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:194)
> at javax.xml.bind.ContextFinder.find(ContextFinder.java:405)
> at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:618)
> at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:565)
> at org.hibernate.validator.internal.util.privilegedactions.NewJaxbContext.run(NewJaxbContext.java:33)
> at org.hibernate.validator.internal.util.privilegedactions.NewJaxbContext.run(NewJaxbContext.java:19)
> at org.hibernate.validator.internal.xml.ValidationXmlParser.run(ValidationXmlParser.java:219)
> at org.hibernate.validator.internal.xml.ValidationXmlParser.unmarshal(ValidationXmlParser.java:127)
> at org.hibernate.validator.internal.xml.ValidationXmlParser.parseValidationXml(ValidationXmlParser.java:88)
> at org.hibernate.validator.internal.engine.ConfigurationImpl.getBootstrapConfiguration(ConfigurationImpl.java:393)
> at org.hibernate.validator.internal.engine.ConfigurationImpl.parseValidationXml(ConfigurationImpl.java:476)
> at org.hibernate.validator.internal.engine.ConfigurationImpl.buildValidatorFactory(ConfigurationImpl.java:309)
> at org.jboss.as.ee.beanvalidation.LazyValidatorFactory.initFactory(LazyValidatorFactory.java:81)
> at org.jboss.as.ee.beanvalidation.LazyValidatorFactory.getDelegate(LazyValidatorFactory.java:58)
> at org.jboss.as.ee.beanvalidation.LazyValidatorFactory.getValidator(LazyValidatorFactory.java:73)
> at org.jboss.as.ee.beanvalidation.LazyValidatorFactoryTestCase.testSpecificProviderCanBeConfiguredInValidationXml(LazyValidatorFactoryTestCase.java:70)
> {noformat}
> It could need to add the java.xml modules
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 10 months
[JBoss JIRA] (WFLY-10045) [Artemis 2.x Upgrade] MDB doesn't find its source queue when useJndi property is set to false
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-10045?page=com.atlassian.jira.plugin... ]
Jeff Mesnil updated WFLY-10045:
-------------------------------
Labels: activemq feature-branch-blocker (was: )
> [Artemis 2.x Upgrade] MDB doesn't find its source queue when useJndi property is set to false
> ---------------------------------------------------------------------------------------------
>
> Key: WFLY-10045
> URL: https://issues.jboss.org/browse/WFLY-10045
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Reporter: Martin Styk
> Assignee: Jeff Mesnil
> Priority: Blocker
> Labels: activemq, feature-branch-blocker
>
> Having a MDB configured as follows:
> {code}
> @MessageDriven(name = "mdb",
> activationConfig = {
> @ActivationConfigProperty(propertyName = "destinationType", propertyValue = "javax.jms.Queue"),
> @ActivationConfigProperty(propertyName = "destination", propertyValue ="InQueue"),
> @ActivationConfigProperty(propertyName = "useJNDI", propertyValue = "false"),
> })
> {code}
> MDB is not able to receive messages from InQueue.
> Server logs:
> {noformat}
> 09:53:29,128 INFO [org.apache.activemq.artemis.ra] (default-threads - 1) AMQ151004: Instantiating javax.jms.Queue "jms/queue/InQueue" directly since UseJNDI=false.
> 09:53:29,188 INFO [org.jboss.as.server] (management-handler-thread - 1) WFLYSRV0010: Deployed "Mdb.jar" (runtime-name : "Mdb.jar")
> 09:53:29,306 INFO [org.wildfly.naming] (default task-1) WildFly Naming version 1.0.7.Final
> 09:53:29,364 INFO [org.apache.activemq.artemis.ra] (default-threads - 1) AMQ151000: awaiting topic/queue creation jms/queue/InQueue
> 09:53:31,366 INFO [org.apache.activemq.artemis.ra] (default-threads - 1) AMQ151001: Attempting to reconnect org.apache.activemq.artemis.ra.inflow.ActiveMQActivationSpec(ra=org.wildfly.extension.messaging.activemq.ActiveMQResourceAdapter@2bd07716 destination=jms/queue/InQueue destinationType=javax.jms.Queue ack=Auto-acknowledge durable=false clientID=null user=null maxSession=15)
> 09:53:31,368 INFO [org.apache.activemq.artemis.ra] (default-threads - 1) AMQ151004: Instantiating javax.jms.Queue "jms/queue/InQueue" directly since UseJNDI=false.
> 09:53:33,480 INFO [org.apache.activemq.artemis.ra] (default-threads - 1) AMQ151004: Instantiating javax.jms.Queue "jms/queue/InQueue" directly since UseJNDI=false.
> 09:53:35,092 INFO [org.jboss.as.server] (management-handler-thread - 1) WFLYSRV0236: Suspending server with no timeout.
> {noformat}
> In {{ActiveMQActivation.setup()}}, call to {{setupDestination()}} is made. Destiantion InQueue is instantiated there. However, during the {{ActiveMQMessageHandler.setup()}} call. consumer can not be created for this destination and exception {{AMQ119017: Queue InQueue does not exist}} is being thrown.
> {code:title=ActiveMQActivation.setup()}
> protected synchronized void setup() throws Exception {
> logger.debug("Setting up " + spec);
> setupCF();
> setupDestination();
> Exception firstException = null;
> for (int i = 0; i < spec.getMaxSession(); i++) {
> ClientSessionFactory cf = null;
> ClientSession session = null;
> try {
> cf = factory.getServerLocator().createSessionFactory();
> session = setupSession(cf);
> ActiveMQMessageHandler handler = new ActiveMQMessageHandler(factory, this, ra.getTM(), (ClientSessionInternal) session, cf, i);
> handler.setup();
> handlers.add(handler);
> } catch (Exception e) {
> ...
> }
> }
> ...
> }
> {code}
> This is regression against Artemis 1.5.
> Wildfly: https://github.com/jmesnil/wildfly/tree/WFLY-9407_upgrade_artemis_2.4.0_w... (06c878a313d3cad323889d017e60fd5533204d1a)
> Artemis: upstream master (577b62d5210cdcc0f86ab9bb1b24e944c877dfe7)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 10 months
[JBoss JIRA] (WFLY-10151) MDB doesn't find its source queue when useJndi property is set to false
by Jeff Mesnil (JIRA)
Jeff Mesnil created WFLY-10151:
----------------------------------
Summary: MDB doesn't find its source queue when useJndi property is set to false
Key: WFLY-10151
URL: https://issues.jboss.org/browse/WFLY-10151
Project: WildFly
Issue Type: Bug
Components: JMS
Reporter: Martin Styk
Assignee: Jeff Mesnil
Priority: Blocker
Having a MDB configured as follows:
{code}
@MessageDriven(name = "mdb",
activationConfig = {
@ActivationConfigProperty(propertyName = "destinationType", propertyValue = "javax.jms.Queue"),
@ActivationConfigProperty(propertyName = "destination", propertyValue ="InQueue"),
@ActivationConfigProperty(propertyName = "useJNDI", propertyValue = "false"),
})
{code}
MDB is not able to receive messages from InQueue.
Server logs:
{noformat}
09:53:29,128 INFO [org.apache.activemq.artemis.ra] (default-threads - 1) AMQ151004: Instantiating javax.jms.Queue "jms/queue/InQueue" directly since UseJNDI=false.
09:53:29,188 INFO [org.jboss.as.server] (management-handler-thread - 1) WFLYSRV0010: Deployed "Mdb.jar" (runtime-name : "Mdb.jar")
09:53:29,306 INFO [org.wildfly.naming] (default task-1) WildFly Naming version 1.0.7.Final
09:53:29,364 INFO [org.apache.activemq.artemis.ra] (default-threads - 1) AMQ151000: awaiting topic/queue creation jms/queue/InQueue
09:53:31,366 INFO [org.apache.activemq.artemis.ra] (default-threads - 1) AMQ151001: Attempting to reconnect org.apache.activemq.artemis.ra.inflow.ActiveMQActivationSpec(ra=org.wildfly.extension.messaging.activemq.ActiveMQResourceAdapter@2bd07716 destination=jms/queue/InQueue destinationType=javax.jms.Queue ack=Auto-acknowledge durable=false clientID=null user=null maxSession=15)
09:53:31,368 INFO [org.apache.activemq.artemis.ra] (default-threads - 1) AMQ151004: Instantiating javax.jms.Queue "jms/queue/InQueue" directly since UseJNDI=false.
09:53:33,480 INFO [org.apache.activemq.artemis.ra] (default-threads - 1) AMQ151004: Instantiating javax.jms.Queue "jms/queue/InQueue" directly since UseJNDI=false.
09:53:35,092 INFO [org.jboss.as.server] (management-handler-thread - 1) WFLYSRV0236: Suspending server with no timeout.
{noformat}
In {{ActiveMQActivation.setup()}}, call to {{setupDestination()}} is made. Destiantion InQueue is instantiated there. However, during the {{ActiveMQMessageHandler.setup()}} call. consumer can not be created for this destination and exception {{AMQ119017: Queue InQueue does not exist}} is being thrown.
{code:title=ActiveMQActivation.setup()}
protected synchronized void setup() throws Exception {
logger.debug("Setting up " + spec);
setupCF();
setupDestination();
Exception firstException = null;
for (int i = 0; i < spec.getMaxSession(); i++) {
ClientSessionFactory cf = null;
ClientSession session = null;
try {
cf = factory.getServerLocator().createSessionFactory();
session = setupSession(cf);
ActiveMQMessageHandler handler = new ActiveMQMessageHandler(factory, this, ra.getTM(), (ClientSessionInternal) session, cf, i);
handler.setup();
handlers.add(handler);
} catch (Exception e) {
...
}
}
...
}
{code}
This is regression against Artemis 1.5.
Wildfly: https://github.com/jmesnil/wildfly/tree/WFLY-9407_upgrade_artemis_2.4.0_w... (06c878a313d3cad323889d017e60fd5533204d1a)
Artemis: upstream master (577b62d5210cdcc0f86ab9bb1b24e944c877dfe7)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 10 months
[JBoss JIRA] (WFLY-10022) [Artemis 2.x Upgrade] File leak - Artemis crashes on Critical IO Error, shutting down the server. file=NIOSequentialFile .../largemessages/55851.msg, message=.../largemessages/55851.msg (Too many open files)
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-10022?page=com.atlassian.jira.plugin... ]
Jeff Mesnil updated WFLY-10022:
-------------------------------
Labels: activemq feature-branch-blocker (was: activemq)
> [Artemis 2.x Upgrade] File leak - Artemis crashes on Critical IO Error, shutting down the server. file=NIOSequentialFile .../largemessages/55851.msg, message=.../largemessages/55851.msg (Too many open files)
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-10022
> URL: https://issues.jboss.org/browse/WFLY-10022
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Reporter: Miroslav Novak
> Assignee: Jeff Mesnil
> Priority: Blocker
> Labels: activemq, feature-branch-blocker
>
> There is file leak in Artemis master branch (577b62d5210cdcc0f86ab9bb1b24e944c877dfe7) when large messages are consumed from topic. This is regression against Artemis 1.5.x.
> Test Scenario:
> * Start WF12 (Jeff's WF WFLY-9407_upgrade_artemis_2.5.0 branch - 06c878a313d3cad323889d017e60fd5533204d1a) with deployed "testTopic"
> * create durable subscriptions on testTopic
> * start sending large messages on testTopic
> * subscribers start to consume one by one so there is a huge difference in number of consumed messages between subscriptions
> Pass Criteria: Subscribers must receive correct number of messages.
> Actual Result:
> Artemis server shutdown/crashes itself on (ulimit for max number of open files was set to 8196):
> {code}
> 15:21:54,717 WARN [org.apache.activemq.artemis.core.server] (Thread-21 (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$5@1787a3ac)) AMQ222010: Critical IO Error, shutting down the server. file=NIOSequentialFile /home/mnovak/hornetq_eap6_dev/internal/eap-tests-hornetq/scripts/journal-A/largemessages/55851.msg, message=/home/mnovak/hornetq_eap6_dev/internal/eap-tests-hornetq/scripts/journal-A/largemessages/55851.msg (Too many open files): ActiveMQIOErrorException[errorType=IO_ERROR message=/home/mnovak/hornetq_eap6_dev/internal/eap-tests-hornetq/scripts/journal-A/largemessages/55851.msg (Too many open files)]
> at org.apache.activemq.artemis.core.io.nio.NIOSequentialFile.open(NIOSequentialFile.java:87) [artemis-journal-2.5.0-SNAPSHOT.jar:2.5.0-SNAPSHOT]
> at org.apache.activemq.artemis.core.io.nio.NIOSequentialFile.open(NIOSequentialFile.java:73) [artemis-journal-2.5.0-SNAPSHOT.jar:2.5.0-SNAPSHOT]
> at org.apache.activemq.artemis.core.persistence.impl.journal.LargeServerMessageImpl.openFile(LargeServerMessageImpl.java:397) [artemis-server-2.5.0-SNAPSHOT.jar:2.5.0-SNAPSHOT]
> at org.apache.activemq.artemis.core.persistence.impl.journal.LargeServerMessageImpl.validateFile(LargeServerMessageImpl.java:376) [artemis-server-2.5.0-SNAPSHOT.jar:2.5.0-SNAPSHOT]
> at org.apache.activemq.artemis.core.persistence.impl.journal.JournalStorageManager.createLargeMessage(JournalStorageManager.java:495) [artemis-server-2.5.0-SNAPSHOT.jar:2.5.0-SNAPSHOT]
> at org.apache.activemq.artemis.core.protocol.core.ServerSessionPacketHandler.sendLarge(ServerSessionPacketHandler.java:937) [artemis-server-2.5.0-SNAPSHOT.jar:2.5.0-SNAPSHOT]
> at org.apache.activemq.artemis.core.protocol.core.ServerSessionPacketHandler.slowPacketHandler(ServerSessionPacketHandler.java:302) [artemis-server-2.5.0-SNAPSHOT.jar:2.5.0-SNAPSHOT]
> at org.apache.activemq.artemis.core.protocol.core.ServerSessionPacketHandler.onMessagePacket(ServerSessionPacketHandler.java:281) [artemis-server-2.5.0-SNAPSHOT.jar:2.5.0-SNAPSHOT]
> at org.apache.activemq.artemis.utils.actors.Actor.doTask(Actor.java:33) [artemis-commons-2.5.0-SNAPSHOT.jar:2.5.0-SNAPSHOT]
> at org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:66) [artemis-commons-2.5.0-SNAPSHOT.jar:2.5.0-SNAPSHOT]
> at org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:42) [artemis-commons-2.5.0-SNAPSHOT.jar:2.5.0-SNAPSHOT]
> at org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:31) [artemis-commons-2.5.0-SNAPSHOT.jar:2.5.0-SNAPSHOT]
> at org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:66) [artemis-commons-2.5.0-SNAPSHOT.jar:2.5.0-SNAPSHOT]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_131]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_131]
> at org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118) [artemis-commons-2.5.0-SNAPSHOT.jar:2.5.0-SNAPSHOT]
> Caused by: java.io.FileNotFoundException: /home/mnovak/hornetq_eap6_dev/internal/eap-tests-hornetq/scripts/journal-A/largemessages/55851.msg (Too many open files)
> at java.io.RandomAccessFile.open0(Native Method) [rt.jar:1.8.0_131]
> at java.io.RandomAccessFile.open(RandomAccessFile.java:316) [rt.jar:1.8.0_131]
> at java.io.RandomAccessFile.<init>(RandomAccessFile.java:243) [rt.jar:1.8.0_131]
> at org.apache.activemq.artemis.core.io.nio.NIOSequentialFile.open(NIOSequentialFile.java:79) [artemis-journal-2.5.0-SNAPSHOT.jar:2.5.0-SNAPSHOT]
> ... 15 more
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 10 months
[JBoss JIRA] (WFLY-10043) [Artemis 2.x Upgrade] Last value queues do not work
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-10043?page=com.atlassian.jira.plugin... ]
Jeff Mesnil updated WFLY-10043:
-------------------------------
Labels: activemq feature-branch-blocker (was: activemq)
> [Artemis 2.x Upgrade] Last value queues do not work
> ---------------------------------------------------
>
> Key: WFLY-10043
> URL: https://issues.jboss.org/browse/WFLY-10043
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Reporter: Martin Styk
> Assignee: Martyn Taylor
> Priority: Blocker
> Labels: activemq, feature-branch-blocker
>
> Last value queues are not working as expected.
> # Set {{last-value-queue="true"}} for an address settings {{#}}
> # Send 10 messages with {{message.setStringProperty("_AMQ_LVQ_NAME", "myProperty");}}
> # Receiver receives 10 messages. (it is expected to receive the single message)
> This looks like broker related regression against Artemis 1.5.
> Wildfly: {{https://github.com/jmesnil/wildfly/tree/WFLY-9407_upgrade_artemis_2.4.0_with_prefix}} (06c878a313d3cad323889d017e60fd5533204d1a)
> Artemis: upstreadm master (577b62d5210cdcc0f86ab9bb1b24e944c877dfe7)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 10 months