[JBoss JIRA] (WFLY-9824) Getting javax.ejb.NoSuchEJBException: EJBCLIENT000079: Unable to discover destination for request for EJB EJBHomeLocator for "jsr-77/jsr-77/EJB" in resourceadpater
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFLY-9824?page=com.atlassian.jira.plugin.... ]
David Lloyd resolved WFLY-9824.
-------------------------------
Resolution: Rejected
Please see http://wildfly.org/gethelp/ for how to get help.
> Getting javax.ejb.NoSuchEJBException: EJBCLIENT000079: Unable to discover destination for request for EJB EJBHomeLocator for "jsr-77/jsr-77/EJB" in resourceadpater
> --------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-9824
> URL: https://issues.jboss.org/browse/WFLY-9824
> Project: WildFly
> Issue Type: Bug
> Components: EE, EJB
> Affects Versions: 11.0.0.Beta1, 11.0.0.Final
> Reporter: shubhashish dash
> Priority: Critical
> Attachments: EAR.ear, server.log
>
>
> I have deployed a EAR in wildfly 11.0.0 Final. The EAR has two sub deplyoment one is a .rar and another is a .war . The both the deployment contains below code
> ////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
> final InitialContext initialContext = new InitialContext();
> final ManagementHome mejb = (ManagementHome) initialContext.lookup("ejb/mgmt/MEJB");
> final ObjectName searchpattern = new ObjectName("*:j2eeType=J2EEServer,*");
> final Management management = mejb.create();
> final Set<ObjectName> set = management.queryNames(searchpattern, null);
> if (set != null && set.size() != 0) {
> final String s = management.getAttribute(set.iterator().next(), "serverVendor").toString();
> System.out.println(s);
> }
> ///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
> But while running the application I am getting "javax.ejb.NoSuchEJBException: EJBCLIENT000079: Unable to discover destination for request for EJB EJBHomeLocator for "jsr-77/jsr-77/EJB"" error. This error only comes in case of rar and not in the war.
> I have attached the sample app with this issue.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 2 months
[JBoss JIRA] (WFLY-9824) Getting javax.ejb.NoSuchEJBException: EJBCLIENT000079: Unable to discover destination for request for EJB EJBHomeLocator for "jsr-77/jsr-77/EJB" in resourceadpater
by shubhashish dash (JIRA)
[ https://issues.jboss.org/browse/WFLY-9824?page=com.atlassian.jira.plugin.... ]
shubhashish dash commented on WFLY-9824:
----------------------------------------
Please respond to my above concern .
Thanks,
Shubhashish
> Getting javax.ejb.NoSuchEJBException: EJBCLIENT000079: Unable to discover destination for request for EJB EJBHomeLocator for "jsr-77/jsr-77/EJB" in resourceadpater
> --------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-9824
> URL: https://issues.jboss.org/browse/WFLY-9824
> Project: WildFly
> Issue Type: Bug
> Components: EE, EJB
> Affects Versions: 11.0.0.Beta1, 11.0.0.Final
> Reporter: shubhashish dash
> Priority: Critical
> Attachments: EAR.ear, server.log
>
>
> I have deployed a EAR in wildfly 11.0.0 Final. The EAR has two sub deplyoment one is a .rar and another is a .war . The both the deployment contains below code
> ////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
> final InitialContext initialContext = new InitialContext();
> final ManagementHome mejb = (ManagementHome) initialContext.lookup("ejb/mgmt/MEJB");
> final ObjectName searchpattern = new ObjectName("*:j2eeType=J2EEServer,*");
> final Management management = mejb.create();
> final Set<ObjectName> set = management.queryNames(searchpattern, null);
> if (set != null && set.size() != 0) {
> final String s = management.getAttribute(set.iterator().next(), "serverVendor").toString();
> System.out.println(s);
> }
> ///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
> But while running the application I am getting "javax.ejb.NoSuchEJBException: EJBCLIENT000079: Unable to discover destination for request for EJB EJBHomeLocator for "jsr-77/jsr-77/EJB"" error. This error only comes in case of rar and not in the war.
> I have attached the sample app with this issue.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 2 months
[JBoss JIRA] (WFLY-10094) [Artemis 2.x upgrade] libAIO does not get loaded on RHEL 6 x86_64
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-10094?page=com.atlassian.jira.plugin... ]
Jeff Mesnil commented on WFLY-10094:
------------------------------------
> libAIO in artemis journal module from WF branch. Not from Artemis 2.5.0.Final tag.
I don't understand your comment.
the lib in EAP is the same than the one from Artemis 2.5.0.Final tag
I downloaded the http://central.maven.org/maven2/org/apache/activemq/artemis-native/2.5.0/... and checksummed the lib in it:
{code}
$ shasum lib/linux-x86_64/libartemis-native-64.so
e54de22dbc33f65dcec31f4a2be3b07907c7359b lib/linux-x86_64/libartemis-native-64.so
{code}
that's the same lib that is in https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/early-testing-...:
{code}
$ shasum jboss-eap/modules/system/layers/base/org/apache/activemq/artemis/journal/main/lib/linux-x86_64/libartemis-native-64.so
e54de22dbc33f65dcec31f4a2be3b07907c7359b jboss-eap/modules/system/layers/base/org/apache/activemq/artemis/journal/main/lib/linux-x86_64/libartemis-native-64.so
{code}
I can't run libaio on my mac but the issue is not having a different library file
> [Artemis 2.x upgrade] libAIO does not get loaded on RHEL 6 x86_64
> -----------------------------------------------------------------
>
> Key: WFLY-10094
> URL: https://issues.jboss.org/browse/WFLY-10094
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Reporter: Miroslav Novak
> Assignee: Jeff Mesnil
> Priority: Blocker
> Labels: activemq, feature-branch-blocker
>
> LibAIO does not get loaded on RHEL 6 x86_64:
> {code}
> [hudson@rhel6-large-2723 bin]$ sh standalone.sh -c standalone-full-ha.xml -Djboss.socket.binding.port-offset=1000
> =========================================================================
> JBoss Bootstrap Environment
> JBOSS_HOME: /tmp/jboss-eap
> JAVA: java
> JAVA_OPTS: -server -Xms64m -Xmx512m -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
> =========================================================================
> ...
> 10:14:31,918 INFO [org.wildfly.extension.messaging-activemq] (MSC service thread 1-1) WFLYMSGAMQ0075: AIO wasn't located on this platform, it will fall back to using pure Java NIO. Your platform is Linux, install LibAIO to enable the AIO journal and achieve optimal performance.
> 10:14:32,017 INFO [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 75) AMQ221000: live Message Broker is starting with configuration Broker Configuration (clustered=true,journalDirectory=/tmp/jboss-eap/standalone/data/activemq/journal,bindingsDirectory=/tmp/jboss-eap/standalone/data/activemq/bindings,largeMessagesDirectory=/tmp/jboss-eap/standalone/data/activemq/largemessages,pagingDirectory=/tmp/jboss-eap/standalone/data/activemq/paging)
> 10:14:32,110 INFO [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 75) AMQ221013: Using NIO Journal
> ...
> {code}
> libAIO in artemis journal module from WF branch. Not from Artemis 2.5.0.Final tag.
> Wildfly: https://github.com/jmesnil/wildfly/tree/WFLY-9407_upgrade_artemis_2.4.0_w... (06c878a313d3cad323889d017e60fd5533204d1a)
> Artemis: upstreadm master (577b62d5210cdcc0f86ab9bb1b24e944c877dfe7)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 2 months
[JBoss JIRA] (WFLY-10286) Consider to add secmgr options to CLI and JDR
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFLY-10286?page=com.atlassian.jira.plugin... ]
Jean-Francois Denise commented on WFLY-10286:
---------------------------------------------
In both cases (CLI, JDR), if we don't have a strong requirement for it, I would not invest in making changes to scripts. User can make changes directly in existing scripts if he has such an (un-common?) need.
Enabling the security-manager can have large side effect on the CLI. But here we are speaking about the JBOSS Module Security-Manager setup. All builtin modules are granted all permissions, so we are safe.
I would say that it makes sense to have this option to allow to start an embedded server with JBOSS module security manager enabled. Doing so you can reproduce a standalone context.
I would be on the same line as https://issues.jboss.org/browse/WFLY-10242?focusedCommentId=13561804&page...
An explicit -secmgr option (with the proper help to explain the embedded use-case) and SECMGR env.
For JDR, if it makes sense to have it enabled then same approach should be chosen. [~bmaxwell]?
> Consider to add secmgr options to CLI and JDR
> ---------------------------------------------
>
> Key: WFLY-10286
> URL: https://issues.jboss.org/browse/WFLY-10286
> Project: WildFly
> Issue Type: Bug
> Components: CLI, Scripts
> Reporter: Marek Kopecký
> Assignee: Jean-Francois Denise
>
> Wildfly standalone/domain/appclient scripts allows two ways for start EAP with security manager:
> * -secmgr command line argument ({{./standalone.sh -secmgr}})
> ** This is described in documentation only in Configuration guide in "A.1. Server Runtime Arguments"
> * SECMGR=true env property
> ** This is not described in documentation at all.
> Does it make sence to add secmgr parameter to CLI script? CLI allows to start embedded server, and standalone.sh (non-embedded server) script has the secmgr option. Does it make sence to add secmgr parameter to the jdr script too? JDR tool uses embedded cli server too in some cases.
> Cc: [~eduda], [~mnovak])
> See [this my command|https://issues.jboss.org/browse/WFLY-10242?focusedCommentId=13561...]
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 2 months
[JBoss JIRA] (WFLY-10068) [Artemis upgrade] Artemis creates and use NODE_MANAGER table even though HA is not configured
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-10068?page=com.atlassian.jira.plugin... ]
Jeff Mesnil updated WFLY-10068:
-------------------------------
Labels: activemq feature-branch-blocker (was: )
> [Artemis upgrade] Artemis creates and use NODE_MANAGER table even though HA is not configured
> ---------------------------------------------------------------------------------------------
>
> Key: WFLY-10068
> URL: https://issues.jboss.org/browse/WFLY-10068
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Reporter: Miroslav Novak
> Assignee: Jeff Mesnil
> Priority: Blocker
> Labels: activemq, feature-branch-blocker
> Attachments: standalone-full-ha.xml
>
>
> If Artemis is not configured to use HA then it should not create and use journal-node-manager-store-table table which is normally used by live/backup pair.
> Problem here is that especially if 2 servers are started and are using the database then administrator logically does not set journal-node-manager-store-table as HA is not used. However in the moment when both of the servers are started they use default values and both of them start to use the same table (default is NODE_MANAGER) then one of them fail with:
> {code}
> 09:20:03,246 INFO [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 74) AMQ221034: Waiting 60000 milliseconds to obtain live lock
> 09:21:03,517 ERROR [org.apache.activemq.artemis.core.server] (ServerService Thread Pool -- 74) AMQ224000: Failure in initialisation: java.lang.Exception: timed out waiting for lock
> at org.apache.activemq.artemis.core.server.impl.jdbc.JdbcNodeManager.lock(JdbcNodeManager.java:240) [artemis-server-2.5.0.jar:2.5.0]
> at org.apache.activemq.artemis.core.server.impl.jdbc.JdbcNodeManager.startLiveNode(JdbcNodeManager.java:346) [artemis-server-2.5.0.jar:2.5.0]
> at org.apache.activemq.artemis.core.server.impl.LiveOnlyActivation.run(LiveOnlyActivation.java:65) [artemis-server-2.5.0.jar:2.5.0]
> at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.internalStart(ActiveMQServerImpl.java:522) [artemis-server-2.5.0.jar:2.5.0]
> at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.start(ActiveMQServerImpl.java:461) [artemis-server-2.5.0.jar:2.5.0]
> at org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl.start(JMSServerManagerImpl.java:376) [artemis-jms-server-2.5.0.jar:2.5.0]
> at org.wildfly.extension.messaging.activemq.jms.JMSService.doStart(JMSService.java:205) [wildfly-messaging-activemq-13.0.0.Alpha1-SNAPSHOT.jar:13.0.0.Alpha1-SNAPSHOT]
> at org.wildfly.extension.messaging.activemq.jms.JMSService.access$000(JMSService.java:64) [wildfly-messaging-activemq-13.0.0.Alpha1-SNAPSHOT.jar:13.0.0.Alpha1-SNAPSHOT]
> at org.wildfly.extension.messaging.activemq.jms.JMSService$1.run(JMSService.java:99) [wildfly-messaging-activemq-13.0.0.Alpha1-SNAPSHOT.jar:13.0.0.Alpha1-SNAPSHOT]
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [rt.jar:1.8.0_131]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) [rt.jar:1.8.0_131]
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) [jboss-threads-2.3.1.Final.jar:2.3.1.Final]
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985) [jboss-threads-2.3.1.Final.jar:2.3.1.Final]
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487) [jboss-threads-2.3.1.Final.jar:2.3.1.Final]
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378) [jboss-threads-2.3.1.Final.jar:2.3.1.Final]
> at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_131]
> at org.jboss.threads.JBossThread.run(JBossThread.java:485) [jboss-threads-2.3.1.Final.jar:2.3.1.Final]
> 09:21:03,520 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 74) MSC000001: Failed to start service jboss.messaging-activemq.default.jms.manager: org.jboss.msc.service.StartException in service jboss.messaging-activemq.default.jms.manager: java.lang.Exception: timed out waiting for lock
> at org.wildfly.extension.messaging.activemq.jms.JMSService.lambda$doStart$0(JMSService.java:141) [wildfly-messaging-activemq-13.0.0.Alpha1-SNAPSHOT.jar:13.0.0.Alpha1-SNAPSHOT]
> at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.callActivationFailureListeners(ActiveMQServerImpl.java:1908) [artemis-server-2.5.0.jar:2.5.0]
> at org.apache.activemq.artemis.core.server.impl.LiveOnlyActivation.run(LiveOnlyActivation.java:82) [artemis-server-2.5.0.jar:2.5.0]
> at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.internalStart(ActiveMQServerImpl.java:522) [artemis-server-2.5.0.jar:2.5.0]
> at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.start(ActiveMQServerImpl.java:461) [artemis-server-2.5.0.jar:2.5.0]
> at org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl.start(JMSServerManagerImpl.java:376) [artemis-jms-server-2.5.0.jar:2.5.0]
> at org.wildfly.extension.messaging.activemq.jms.JMSService.doStart(JMSService.java:205) [wildfly-messaging-activemq-13.0.0.Alpha1-SNAPSHOT.jar:13.0.0.Alpha1-SNAPSHOT]
> at org.wildfly.extension.messaging.activemq.jms.JMSService.access$000(JMSService.java:64) [wildfly-messaging-activemq-13.0.0.Alpha1-SNAPSHOT.jar:13.0.0.Alpha1-SNAPSHOT]
> at org.wildfly.extension.messaging.activemq.jms.JMSService$1.run(JMSService.java:99) [wildfly-messaging-activemq-13.0.0.Alpha1-SNAPSHOT.jar:13.0.0.Alpha1-SNAPSHOT]
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [rt.jar:1.8.0_131]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) [rt.jar:1.8.0_131]
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) [jboss-threads-2.3.1.Final.jar:2.3.1.Final]
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985) [jboss-threads-2.3.1.Final.jar:2.3.1.Final]
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487) [jboss-threads-2.3.1.Final.jar:2.3.1.Final]
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378) [jboss-threads-2.3.1.Final.jar:2.3.1.Final]
> at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_131]
> at org.jboss.threads.JBossThread.run(JBossThread.java:485) [jboss-threads-2.3.1.Final.jar:2.3.1.Final]
> Caused by: java.lang.Exception: timed out waiting for lock
> at org.apache.activemq.artemis.core.server.impl.jdbc.JdbcNodeManager.lock(JdbcNodeManager.java:240) [artemis-server-2.5.0.jar:2.5.0]
> at org.apache.activemq.artemis.core.server.impl.jdbc.JdbcNodeManager.startLiveNode(JdbcNodeManager.java:346) [artemis-server-2.5.0.jar:2.5.0]
> at org.apache.activemq.artemis.core.server.impl.LiveOnlyActivation.run(LiveOnlyActivation.java:65) [artemis-server-2.5.0.jar:2.5.0]
> ... 14 more
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 2 months
[JBoss JIRA] (WFLY-10002) Incorrect number of messages on queue after remove of scheduled message
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-10002?page=com.atlassian.jira.plugin... ]
Jeff Mesnil updated WFLY-10002:
-------------------------------
Labels: activemq feature-branch-blocker (was: feature-branch-blocker)
> Incorrect number of messages on queue after remove of scheduled message
> -----------------------------------------------------------------------
>
> Key: WFLY-10002
> URL: https://issues.jboss.org/browse/WFLY-10002
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Reporter: Martin Styk
> Assignee: Justin Bertram
> Labels: activemq, feature-branch-blocker
>
> Removing scheduled message from queue cause incorrect number of messages reported by {{count-messages}} operation.
> It looks like the operation {{count-messages}} returns value equal to _actual number of messages_ minus _number of removed scheduled messages_
> *Scenario*
> # send 1 message with _AMQ_SCHED_DELIVERY property set to several minutes
> # remove scheduled emssage using CLI operation {{remove-message}}
> # find out number of messages on queue using CLI operation {{count-messages}} - it returns value -1
> This is broker related issue. It is regression against Artemis 1.5.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 2 months