[JBoss JIRA] (WFLY-2608) MDB not receiving messages from JMS queue.
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-2608?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil resolved WFLY-2608.
-------------------------------
Fix Version/s: 9.0.0.Alpha1
Resolution: Done
Fixed in HornetQ since 2.4.2.Final
> MDB not receiving messages from JMS queue.
> ------------------------------------------
>
> Key: WFLY-2608
> URL: https://issues.jboss.org/browse/WFLY-2608
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 8.0.0.Beta1
> Reporter: Corey Puffalt
> Assignee: Jeff Mesnil
> Fix For: 9.0.0.Alpha1
>
>
> We've run into a situation where MDBs stopped receiving messages from a JMS queue although the JMS queue itself was continuing to receive new messages from an EJB. The forum thread referenced below has more background information but basically at some point we see the following in our server logs:
> {code}
> 00:50:28,915 WARN [org.hornetq.core.protocol.core.impl.RemotingConnectionImpl] (hornetq-failure-check-thread) Connection failure has been detected: Did not receive data from invm:0. It is likely the client has exited or crashed without closing its connection, or the network between the server and client has failed. You also might have configured connection-ttl and client-failure-check-period incorrectly. Please check user manual for more information. The connection will now be closed. [code=3]
> 00:50:29,208 WARN [org.hornetq.core.server.impl.ServerSessionImpl] (hornetq-failure-check-thread) Client connection failed, clearing up resources for session e33d5fe6-caf3-11e2-bc0f-3d92824f2653
> 00:50:29,235 WARN [org.hornetq.core.server.impl.ServerSessionImpl] (hornetq-failure-check-thread) Cleared up resources for session e33d5fe6-caf3-11e2-bc0f-3d92824f2653
> [the above two messages are repeated a number of times in rapid succession...and then finally we get...]
> 00:50:30,187 WARN [org.hornetq.jms.server.recovery.RecoveryDiscovery] (Thread-18647 (HornetQ-client-global-threads-2106576636)) Notified of connection failure in xa discovery, we will retry on the next recovery: HornetQException[errorCode=2 message=Channel disconnected]
> at org.hornetq.core.client.impl.ClientSessionFactoryImpl.connectionDestroyed(ClientSessionFactoryImpl.java:381) [hornetq-core-2.2.16.Final.jar:2.2.16.Final (HQ_2_2_16_FINAL, 122)]
> at org.hornetq.core.remoting.impl.invm.InVMConnector$Listener$1.run(InVMConnector.java:203) [hornetq-core-2.2.16.Final.jar:2.2.16.Final (HQ_2_2_16_FINAL, 122)]
> at org.hornetq.utils.OrderedExecutorFactory$OrderedExecutor$1.run(OrderedExecutorFactory.java:100) [hornetq-core-2.2.16.Final.jar:2.2.16.Final (HQ_2_2_16_FINAL, 122)]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [rt.jar:1.7.0_07]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [rt.jar:1.7.0_07]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_07]
> 00:50:29,240 WARN [org.hornetq.jms.server.recovery.HornetQXAResourceWrapper] (Thread-18651 (HornetQ-client-global-threads-2106576636)) Notified of connection failure in xa recovery connectionFactory for provider ClientSessionFactoryImpl [serverLocator=ServerLocatorImpl [initialConnectors=[org-hornetq-core-remoting-impl-invm-InVMConnectorFactory?server-id=0], discoveryGroupConfiguration=null], connectorConfig=org-hornetq-core-remoting-impl-invm-InVMConnectorFactory?server-id=0, backupConfig=null] will attempt reconnect on next pass: HornetQException[errorCode=2 message=Channel disconnected]
> at org.hornetq.core.client.impl.ClientSessionFactoryImpl.connectionDestroyed(ClientSessionFactoryImpl.java:381) [hornetq-core-2.2.16.Final.jar:2.2.16.Final (HQ_2_2_16_FINAL, 122)]
> at org.hornetq.core.remoting.impl.invm.InVMConnector$Listener$1.run(InVMConnector.java:203) [hornetq-core-2.2.16.Final.jar:2.2.16.Final (HQ_2_2_16_FINAL, 122)]
> at org.hornetq.utils.OrderedExecutorFactory$OrderedExecutor$1.run(OrderedExecutorFactory.java:100) [hornetq-core-2.2.16.Final.jar:2.2.16.Final (HQ_2_2_16_FINAL, 122)]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [rt.jar:1.7.0_07]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [rt.jar:1.7.0_07]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_07]
> 00:50:38,633 INFO [org.hornetq.jms.server.recovery.RecoveryDiscovery] (HornetQ Recovery Discovery Reinitialization) Starting RecoveryDiscovery on XARecoveryConfig [transportConfiguration = [org-hornetq-core-remoting-impl-invm-InVMConnectorFactory?server-id=0], discoveryConfiguration = null, username=null, password=null]
> 00:50:38,636 INFO [org.hornetq.jms.server.recovery.RecoveryDiscovery] (HornetQ Recovery Discovery Reinitialization) RecoveryDiscovery started fine on XARecoveryConfig [transportConfiguration = [org-hornetq-core-remoting-impl-invm-InVMConnectorFactory?server-id=0], discoveryConfiguration = null, username=null, password=null]
> {code}
> After this our MDB never receives any further messages until a server restart. HornetQ should be recovering from this situation (whatever the cause).
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (WFCORE-621) Support legacy slaves when invoking wildcard reads in a domain
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-621:
---------------------------------------
Summary: Support legacy slaves when invoking wildcard reads in a domain
Key: WFCORE-621
URL: https://issues.jboss.org/browse/WFCORE-621
Project: WildFly Core
Issue Type: Enhancement
Components: Domain Management
Reporter: Brian Stansberry
Priority: Critical
Fix For: 2.0.0.Beta1
This is a follow-on to WFCORE-282.
The WFCORE-282 will not work for requests with address patterns /host=*/server=* or /host=somename/server=* if the host named 'somename' is running a WFCORE version prior to 1.0.0.CR1 (or whatever release first has WFCORE-282 introduced.)
In particular, it won't work with slaves running EAP 6.x.
The problem is with either of those address patterns the DC will send a request addressed to /host=somename/server=* to the slave, and the slave will not be able to handle it, as it won't have the WFCORE-282 logic that lets it identify the relevant servers and send requests on to them.
Potentially this could be fixed by having the DC detect these patterns and not call /host=somename/server=*, instead adding a step to read the server child names from /host=somename and then call /host=somename/server=a, /host=somename/server=b, etc.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (JBLOGGING-111) LoggerProvider configured with new ServiceLoader crash
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/JBLOGGING-111?page=com.atlassian.jira.plu... ]
James Perkins commented on JBLOGGING-111:
-----------------------------------------
Yeah it's in 3.2.0.Final. Fixed and thanks for pointing it out.
> LoggerProvider configured with new ServiceLoader crash
> ------------------------------------------------------
>
> Key: JBLOGGING-111
> URL: https://issues.jboss.org/browse/JBLOGGING-111
> Project: JBoss Logging
> Issue Type: Bug
> Affects Versions: 3.2.0.Beta1
> Environment: Weblogic 10.3.2.0
> Configured in ejb jar, deployed by an ear file
> Reporter: Frederic Allard
> Assignee: James Perkins
> Fix For: 3.2.0.Final
>
>
> There is a new feature in the beta which uses the ServiceLoader to specify a LoggerProvider to be used by JBoss Logging.
> org.jboss.logging.LoggerProviders snippet :
> {code}
> // Next try for a service provider
> try {
> final ServiceLoader<LoggerProvider> loader = ServiceLoader.load(LoggerProvider.class, cl);
> if (loader.iterator().hasNext()) {
> return loader.iterator().next();
> }
> } catch (Throwable ignore) {
> // TODO consider printing the stack trace as it should only happen once
> }
> {code}
> When you try to configure a provider (ex. org.jboss.logging.Slf4jLoggerProvider), the ServiceLoader crash silently and ignore the provider.
> {code}
> java.util.ServiceConfigurationError: org.jboss.logging.LoggerProvider: Provider org.jboss.logging.Slf4jLoggerProvider could not be instantiated: java.lang.IllegalAccessException: Class java.util.ServiceLoader$LazyIterator can not access a member of class org.jboss.logging.Slf4jLoggerProvider with modifiers ""
> at java.util.ServiceLoader.fail(ServiceLoader.java:207)
> at java.util.ServiceLoader.access$100(ServiceLoader.java:164)
> at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:353)
> at java.util.ServiceLoader$1.next(ServiceLoader.java:421)
> at org.jboss.logging.LoggerProviders.findProvider(LoggerProviders.java:70)
> at org.jboss.logging.LoggerProviders.find(LoggerProviders.java:32)
> at org.jboss.logging.LoggerProviders.<clinit>(LoggerProviders.java:29)
> at org.jboss.logging.Logger.getLogger(Logger.java:2177)
> at org.jboss.logging.Logger$1.run(Logger.java:2277)
> at java.security.AccessController.doPrivileged(Native Method)
> at org.jboss.logging.Logger.getMessageLogger(Logger.java:2241)
> at org.jboss.logging.Logger.getMessageLogger(Logger.java:2228)
> at org.hibernate.cfg.Configuration.<clinit>(Configuration.java:176)
> ...
> {code}
> This is caused by the fact that all JBoss providers are not public classes and are instead package classes.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (WFCORE-601) Boot sometimes fails on restart when deployments are present in the deployments directory and the deployment scanner is in use
by ehsavoie Hugonnet (JIRA)
[ https://issues.jboss.org/browse/WFCORE-601?page=com.atlassian.jira.plugin... ]
ehsavoie Hugonnet commented on WFCORE-601:
------------------------------------------
Leaving Stuart as assigned since I can't reproduce it locally.
> Boot sometimes fails on restart when deployments are present in the deployments directory and the deployment scanner is in use
> ------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-601
> URL: https://issues.jboss.org/browse/WFCORE-601
> Project: WildFly Core
> Issue Type: Bug
> Components: Server
> Reporter: Stuart Douglas
> Assignee: Stuart Douglas
>
> I observed this today, looks to be some kind of race in the deployment scanner on boot
> {code}
> 21:52:08,618 INFO [org.jboss.modules] (main) JBoss Modules version 1.4.1.Final
> 21:52:10,370 INFO [org.jboss.msc] (main) JBoss MSC version 1.2.4.Final
> 21:52:10,440 INFO [org.jboss.as] (MSC service thread 1-6) WFLYSRV0049: WildFly Full 9.0.0.Alpha2-SNAPSHOT (WildFly Core 1.0.0.Alpha19) starting
> 21:52:11,390 INFO [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 20) WFLYCTL0028: Attribute enabled is deprecated, and it might be removed in future version!
> 21:52:11,409 INFO [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 1) WFLYDS0015: Re-attempting failed deployment mysql-ds.xml
> 21:52:11,413 INFO [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 1) WFLYDS0015: Re-attempting failed deployment wildfly-ee7.war
> 21:52:11,488 INFO [org.jboss.as.repository] (ServerService Thread Pool -- 3) WFLYDR0001: Content added at location /Users/stuart/workspace/wildfly/build/target/wildfly-9.0.0.Alpha2-SNAPSHOT/standalone/data/content/48/032d14f289775249a004205c059588ab0f44d4/content
> 21:52:11,504 INFO [org.jboss.as.repository] (ServerService Thread Pool -- 3) WFLYDR0001: Content added at location /Users/stuart/workspace/wildfly/build/target/wildfly-9.0.0.Alpha2-SNAPSHOT/standalone/data/content/c6/7babde4791697ddc6509fbd43ba1ec25952d47/content
> 21:52:11,506 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 3) WFLYCTL0013: Operation ("add") failed - address: ([("deployment" => "wildfly-ee7.war")]) - failure description: "WFLYCTL0212: Duplicate resource [(\"deployment\" => \"wildfly-ee7.war\")]"
> 21:52:11,509 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) "WFLYCTL0193: Failed executing subsystem deployment-scanner boot operations"
> 21:52:11,512 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("parallel-subsystem-boot") failed - address: ([]) - failure description: "\"WFLYCTL0193: Failed executing subsystem deployment-scanner boot operations\""
> 21:52:11,514 FATAL [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
> 21:52:11,514 INFO [org.jboss.as.server] (Thread-2) WFLYSRV0220: Server shutdown has been requested.
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (WFCORE-416) Inconsistent tab completion behaviour between commands and arguments
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFCORE-416?page=com.atlassian.jira.plugin... ]
Jeff Mesnil closed WFCORE-416.
------------------------------
Resolution: Won't Fix
> Inconsistent tab completion behaviour between commands and arguments
> --------------------------------------------------------------------
>
> Key: WFCORE-416
> URL: https://issues.jboss.org/browse/WFCORE-416
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Reporter: Jeff Mesnil
> Assignee: Jeff Mesnil
> Priority: Minor
>
> When tab is used for completion, the behavior changes when there is only 1 remaining candidate.
> For commands, when the completion leads to a single candidate, a whitespace is appended and we can proceed to the arguments
> For arguments using a TabCompleter, when the completion leads to a single candidate, no whitespace is appended and we have to type it to be able to proceed to the next argument
>
> Example:
> * deployment-over<TAB>
> => will complete to deployment-overlay<WHITESPACE><CURSOR> (a whitespace is appended to the single candidate)
> * deployment-overlay a<TAB>
> => will complete to deployment-overlay add<CURSOR> (no whitespace appended even though add is the only candidate matched)
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (WFLY-4483) Resteasy+Spring integration can result in double VFS mount if deployment fails
by ehsavoie Hugonnet (JIRA)
[ https://issues.jboss.org/browse/WFLY-4483?page=com.atlassian.jira.plugin.... ]
ehsavoie Hugonnet updated WFLY-4483:
------------------------------------
Description:
I have a spring MVC war that failed during deployment because of some external resource missing ( a cassandra keyspace).
When I tried to deploy the war again after fixing the issue (through the web console) I got :
Caused by: java.io.IOException: VFS000017: Filesystem already mounted at mount point \"\"/wildfly/modules/system/layers/base/org/jboss/resteasy/resteasy-spring/main/bundled/resteasy-spring-jar/resteasy-spring-3.0.11.Final.jar
It looks like we are trying to mount the file again while the service managing the mounthandle hasn't stopped.
was:
I have a spring MVC war that failed during deployment because of some external resource missing.
When I tried to deploy the war again after fixing the issue I got :
> Resteasy+Spring integration can result in double VFS mount if deployment fails
> ------------------------------------------------------------------------------
>
> Key: WFLY-4483
> URL: https://issues.jboss.org/browse/WFLY-4483
> Project: WildFly
> Issue Type: Bug
> Components: REST
> Affects Versions: 9.0.0.Beta2
> Reporter: ehsavoie Hugonnet
> Assignee: Stuart Douglas
>
> I have a spring MVC war that failed during deployment because of some external resource missing ( a cassandra keyspace).
> When I tried to deploy the war again after fixing the issue (through the web console) I got :
> Caused by: java.io.IOException: VFS000017: Filesystem already mounted at mount point \"\"/wildfly/modules/system/layers/base/org/jboss/resteasy/resteasy-spring/main/bundled/resteasy-spring-jar/resteasy-spring-3.0.11.Final.jar
> It looks like we are trying to mount the file again while the service managing the mounthandle hasn't stopped.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (WFCORE-620) JBoss Product Installation Report
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-620:
---------------------------------------
Summary: JBoss Product Installation Report
Key: WFCORE-620
URL: https://issues.jboss.org/browse/WFCORE-620
Project: WildFly Core
Issue Type: Feature Request
Components: Domain Management
Reporter: Brian Stansberry
Assignee: ehsavoie Hugonnet
Fix For: 2.0.0.CR1
Provide ability to report on existing WildFly instance details for entitlements review purposes.
It can run in domain and standalone mode. While running in domain mode; the report includes information on all the instances in the domain.
Per instance the following a list of attributes are captured: (including but not limited to)
Organization Identifier
Instance Identifier (a unique identifier of an installation instance)
Product Name
Product Version #
Product Install Date
Product Last Update Date
Product-Community Identifier
JVM Version
Host Core Count
Host Name
Host OS
Host CPU Architecture
StandAlone-or-Domain-Identifier
The generated report should have a versioned schema so that it can be extensible (adding new meta data). The report data format is up to the engineering decision; but it should be same for all the JBoss products.
See: https://mojo.redhat.com/docs/DOC-982877
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months