wildfly18

[pankaj narkhede]

Hi Team,

We recently migrated from wildfly 10 to wildfly Full 18.0.1.Final. and started seeing transaction rollbacks due to file descriptor leakage.(too many files open). We had seen similar transaction rollback issue during our JBOSS migrations but not due to file descriptor leaks. Redhat had advised us to add below property for that fix. We still have below property present in our wildfly 10 and didnt see any issue but seeing issues in wildfly 18. so would like to know if this property is causing any issues in wildfly 18. Any help would be appreciated.

-Dcom.arjuna.ats.arjuna.common.CoordinatorEnvironmentBean.dynamic1PC=false

Please see trace logs for complete error.

2020-04-06 08:49:34,910 ERROR [org.xnio.nio.tcp.server] (http-worker Accept) Exception accepting request, closing server channel TCP server (NIO) <6be07bee>: java.io.IOException: Too many o
pen files
        at sun.nio.ch.ServerSocketChannelImpl.accept0(Native Method) [rt.jar:1.8.0_231]
        at sun.nio.ch.ServerSocketChannelImpl.accept(ServerSocketChannelImpl.java:422) [rt.jar:1.8.0_231]
        at sun.nio.ch.ServerSocketChannelImpl.accept(ServerSocketChannelImpl.java:250) [rt.jar:1.8.0_231]
        at org.xnio.nio.QueuedNioTcpServer.handleReady(QueuedNioTcpServer.java:478) [xnio-nio-3.7.3.Final.jar:3.7.3.Final]
        at org.xnio.nio.QueuedNioTcpServerHandle.handleReady(QueuedNioTcpServerHandle.java:38) [xnio-nio-3.7.3.Final.jar:3.7.3.Final]
        at org.xnio.nio.WorkerThread.run(WorkerThread.java:591) [xnio-nio-3.7.3.Final.jar:3.7.3.Final]

2020-04-06 08:49:37,100 WARN  [com.arjuna.ats.arjuna] (default task-13) ARJUNA012073: BasicAction.End() - prepare phase of action-id 0:ffff87d5b9e6:-1ed218fc:5e8b44e0:420dd failed.

2020-04-06 08:49:37,101 WARN  [com.arjuna.ats.arjuna] (default task-13) ARJUNA012075: Action Aborting

2020-04-06 08:49:37,115 ERROR [org.jboss.as.ejb3.invocation] (default task-13) WFLYEJB0034: EJB Invocation failed on component XXXXX for method public abstract java.util.HashMap com.sbc.dbus.ejb.XXXX.ProcessEventForReaderRequiresNew(java.util.HashMap,java.lang.String): javax.ejb.EJBTransactionRolledbackException: javax.transaction.RollbackException: ARJUNA016053: Could not commit transaction.

        at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:114) [wildfly-ejb3-18.0.1.Final.jar:18.0.1.Final]

        at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:261) [wildfly-ejb3-18.0.1.Final.jar:18.0.1.Final]

        at org.jboss.as.ejb3.tx.CMTTxInterceptor.requiresNew(CMTTxInterceptor.java:388) [wildfly-ejb3-18.0.1.Final.jar:18.0.1.Final]

        at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:146) [wildfly-ejb3-18.0.1.Final.jar:18.0.1.Final]

        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)

        at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:509)

        at org.jboss.weld.module.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:81) [weld-ejb-3.1.2.Final.jar:3.1.2.Final]

        at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:89)

        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)

        at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [wildfly-ejb3-18.0.1.Final.jar:18.0.1.Final]

        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)

        at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:47) [wildfly-ejb3-18.0.1.Final.jar:18.0.1.Final]

        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)

        at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100) [wildfly-ejb3-18.0.1.Final.jar:18.0.1.Final]

        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)

        at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22) [wildfly-ejb3-18.0.1.Final.jar:18.0.1.Final]

        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)

        at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) [wildfly-ejb3-18.0.1.Final.jar:18.0.1.Final]

        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)

        at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:57) [wildfly-ejb3-18.0.1.Final.jar:18.0.1.Final]

 at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)

        at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:67) [wildfly-ejb3-18.0.1.Final.jar:18.0.1.Final]

        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)

        at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)

        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)

        at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:60)

        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)

        at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:438)

        at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:627) [wildfly-elytron-security-manager-1.10.4.Final.jar:1.10.4.Final]

        at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:57)

        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)

        at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:53)

        at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198)

        at org.wildfly.security.auth.server.SecurityIdentity.runAsFunctionEx(SecurityIdentity.java:406) [wildfly-elytron-auth-server-1.10.4.Final.jar:1.10.4.Final]

        at org.jboss.as.ejb3.remote.AssociationImpl.invokeWithIdentity(AssociationImpl.java:593) [wildfly-ejb3-18.0.1.Final.jar:18.0.1.Final]

        at org.jboss.as.ejb3.remote.AssociationImpl.invokeMethod(AssociationImpl.java:574) [wildfly-ejb3-18.0.1.Final.jar:18.0.1.Final]

        at org.jboss.as.ejb3.remote.AssociationImpl.lambda$receiveInvocationRequest$0(AssociationImpl.java:205) [wildfly-ejb3-18.0.1.Final.jar:18.0.1.Final]

        at org.jboss.as.ejb3.remote.AssociationImpl.execute(AssociationImpl.java:298) [wildfly-ejb3-18.0.1.Final.jar:18.0.1.Final]

        at org.jboss.as.ejb3.remote.AssociationImpl.receiveInvocationRequest(AssociationImpl.java:251) [wildfly-ejb3-18.0.1.Final.jar:18.0.1.Final]

        at org.jboss.ejb.protocol.remote.EJBServerChannel$ReceiverImpl.handleInvocationRequest(EJBServerChannel.java:465) [jboss-ejb-client-4.0.23.Final.jar:4.0.23.Final]

        at org.jboss.ejb.protocol.remote.EJBServerChannel$ReceiverImpl.handleMessage(EJBServerChannel.java:203) [jboss-ejb-client-4.0.23.Final.jar:4.0.23.Final]

        at org.jboss.remoting3.remote.RemoteConnectionChannel.lambda$handleMessageData$3(RemoteConnectionChannel.java:430)

        at org.jboss.remoting3.EndpointImpl$TrackingExecutor.lambda$execute$0(EndpointImpl.java:991)

        at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)

        at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)

        at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)

        at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)

        at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_231]

Caused by: javax.transaction.RollbackException: ARJUNA016053: Could not commit transaction.

        at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1299) [narayana-jts-idlj-5.9.8.Final.jar:5.9.8.Final (revision: 92f28)]

        at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126) [narayana-jts-idlj-5.9.8.Final.jar:5.9.8.Final (revision: 92f28)]

        at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:94)

        at org.wildfly.transaction.client.LocalTransaction.commitAndDissociate(LocalTransaction.java:75) [wildfly-transaction-client-1.1.7.Final.jar:1.1.7.Final]

        at org.wildfly.transaction.client.ContextTransactionManager.commit(ContextTransactionManager.java:71) [wildfly-transaction-client-1.1.7.Final.jar:1.1.7.Final]

        at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:88) [wildfly-ejb3-18.0.1.Final.jar:18.0.1.Final]

[pankaj narkhede]

We recently migrated from wildfly 10 to wildfly 18 and are seeing file descriptor leaks (too many open files) resulting into transaction rollbacks for EJB calls. We had added below property during our jboss migrations  

for transaction rollback issue. and never saw issue until wildfly 10. 

com.arjuna.ats.arjuna.common.CoordinatorEnvironmentBean.dynamic1PC=false 

Post wildfly 18 migration, we started seeing below errors. So would like to know if above property is causing any issues.? or any other issue ? 

2020-04-06 08:49:34,910 ERROR [org.xnio.nio.tcp.server] (http-worker Accept) Exception accepting request, closing server channel TCP server (NIO) <6be07bee>: java.io.IOException: Too many o

pen files

        at sun.nio.ch.ServerSocketChannelImpl.accept0(Native Method) [rt.jar:1.8.0_231]

        at sun.nio.ch.ServerSocketChannelImpl.accept(ServerSocketChannelImpl.java:422) [rt.jar:1.8.0_231]

        at sun.nio.ch.ServerSocketChannelImpl.accept(ServerSocketChannelImpl.java:250) [rt.jar:1.8.0_231]

        at org.xnio.nio.QueuedNioTcpServer.handleReady(QueuedNioTcpServer.java:478) [xnio-nio-3.7.3.Final.jar:3.7.3.Final]

        at org.xnio.nio.QueuedNioTcpServerHandle.handleReady(QueuedNioTcpServerHandle.java:38) [xnio-nio-3.7.3.Final.jar:3.7.3.Final]

        at org.xnio.nio.WorkerThread.run(WorkerThread.java:591) [xnio-nio-3.7.3.Final.jar:3.7.3.Final]

2020-04-06 08:49:37,115 ERROR [org.jboss.as.ejb3.invocation] (default task-13) WFLYEJB0034: EJB Invocation failed on component XXXXXX for method public abstract java.util.HashMap com.xxx.

xxx.ejb.xxx.ProcessEventForReaderRequiresNew(java.util.HashMap,java.lang.String): javax.ejb.EJBTransactionRolledbackException: javax.transaction.RollbackException: ARJUNA016053: Could not

Thanks & Regards,

Pankaj N

[pankaj narkhede]

Can someone please guide on this issue ?

Thanks & Regards,

Pankaj N

[Tomaž Cerar]

hey,

as part of upgrade you probably also updated your server where WildFly is deployed to.

Guessing it is linux based system which would indicate you have default open files security limitations which is 1024 open files per user.

In linux open file can be anything from network connection to actual file.

so it is quite possible that you just need to update linux kernel security configuration to allow more than default open files.

--

tomaž

--
You received this message because you are subscribed to the Google Groups "WildFly" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wildfly+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/wildfly/9450772e-60e2-4ed2-b3c6-fbe9b9df0a7a%40googlegroups.com.

[pankaj narkhede]

Hi Tomaz,

Thanks for the reply. There are no changes in Linux. All ulimits are same as before. With same settings, we are not seeing any issues in Wildfly 10 but in Wildfly 18.

Thanks & Regards,

Pankaj Narkhede

To unsubscribe from this group and stop receiving emails from it, send an email to wil...@googlegroups.com.

[Tomaž Cerar]

hey,

than take a look what are the open files.

run "lsof" on the system to show you what the open files are.

from there we can move on to see what is keeping them open

To unsubscribe from this group and stop receiving emails from it, send an email to wildfly+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/wildfly/ab7cfdc4-79fd-4df9-a44e-0857bf459c45%40googlegroups.com.

[pankaj narkhede]

All open files are from ejb-xa-recovery. 

To view this discussion on the web visit https://groups.google.com/d/msgid/wildfly/ab7cfdc4-79fd-4df9-a44e-0857bf459c45%40googlegroups.com.

[pankaj narkhede]

can someone please help ?

[Ondra Chaloupka]

Hi Pankaj,

 

The migration from WildFly 10 to WildFly 18 means a change in the underlying ejb remoting subsystem which processes transaction context propagation. The former versions of WildFly were managing the remote transaction propagation inside of the EJB code while the later ones introduced a new project WildFly Transaction Client (WFTC, see https://github.com/wildfly/wildfly-transaction-client). The new approach fixes some possible consistency issues which were not handled before. The WFTC requires to store some more data during EJB remote calls (from one WildFly server to another) and those are saved as files in ejb-xa-recovery. Every file should be closed and deleted after the EJB remote call finishes and the transaction is committed or rolled-back.

The WildFly 18 uses the WFTC in version 1.1.7. That version suffers with few issues about deleting these descriptor files in some cases. Do you think you may check if the same error happens on WildFly 19 where WFTC is in version 1.1.9.Final?

Or could you please just upgrade the WFTC version in the WildFly 18?

(The fastest way for testing this is to download the 1.1.9.Final? release from jboss nexus or from maven central https://repository.jboss.org/nexus/service/local/artifact/maven/redirect?r=central&g=org.wildfly.transaction&a=wildfly-transaction-client&v=1.1.9.Final&e=jar, then copy it under $WILDFLY_HOME/modules/system/layers/base/org/wildfly/transaction/client/main/ and update the module.xml at the same place with the jar file of the new name)

With this we can find out if the provided fixes help your case (there could be some undiscovered issue). Still, it's good to note that the WildFly 18 now opens one more file for every EJB remote call than it was in case of WildFly 10.

Regarding the '-Dcom.arjuna.ats.arjuna.common.CoordinatorEnvironmentBean.dynamic1PC=false'. The older version of WildFly (Narayana component specifically) contained the issue https://issues.redhat.com/browse/JBTM-2916 which was probably the cause of the error you were observing. But the new versions of WildFly already fixed that deficiency. I think it's not necessary to configure the CoordinatorEnvironmentBean.dynamic1PC to false. In fact I would recommend leaving it rather with the default value of true as it could enhance the throughput of the transaction processing in some cases.

Kind regards,

Ondra

To unsubscribe from this group and stop receiving emails from it, send an email to wildfly+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/wildfly/b7483320-a8c3-46a1-875e-9a965d025296%40googlegroups.com.

[pankaj narkhede]

Thanks Ondra for your inputs. We will try and let you know.

Thanks & Regards,

Pankaj Narkhede

On Tuesday, April 7, 2020 at 1:09:27 PM UTC-5, pankaj narkhede wrote:

[pankaj narkhede]

Hi Ondra,

Thanks for your valuable inputs. After updating wildfly client jar helped to fix ejb-xa-recovery issue. Not seeing file descriptor leakage issue as well. 

However we are seeing intermittent issue for remote EJB calls. In our environment we have most of the remote EJB calls between jvms in same domain. We never saw this issue in wildfly10 but seeing now in wildfly18. Could you please provide your inputs on this ? 

default-threads - 34] ERROR-633521018_iPkakdIXGGyPkrPR@631037154_80986331_16404_1_0 46673421 10 DbusJMSReaderBean.55 [602] onMessage ProcessEventRequiresNew failed: javax.ejb.NoSuchEJBException: EJBCLIENT000079: Unable to discover destination for request for EJB StatelessEJBLocator for "dbusEAP5/dbusEJB3/DbusBean", view is interface com.sbc.dbus.ejb.Dbus, affinity is None

Thanks & Regards,

Pankaj Narkhede

[Ondra Chaloupka]

Hi Pankaj,

This is a bit of a generic error message. As it can be assumed it says there is trouble finding the EJB bean.

There are plenty of reasons why this could occur. For example, there could be some instability in the network and once in a while (it's so that the `onMessage` invokes the EJB remote call, right?)

I agree this does not explain why you haven't seen this in WildFly 10 and you experience the error message with WildFly 18. For sure there were changes in EJB remoting in comparison to those two versions.

But I don't know the exact details here.

Would you have some more context on what is the configuration of the DbusBean injection or how the remote lookup is set up?

It would be useful if you could provide more logging - e.g. the trace logging[1] of the ejb remoting at time this issue happens. The best would be for both servers.

Ondra

[1] something like this

/subsystem=logging/logger=org.jboss.ejb.client:add(level=TRACE)
/subsystem=logging/logger=org.jboss.as.remoting:add(level=TRACE)
/subsystem=logging/logger=org.jboss.remoting3:add(level=TRACE)
/subsystem=logging/logger=org.jboss.ejb.protocol.remote:add(level=TRACE)

--
You received this message because you are subscribed to the Google Groups "WildFly" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wildfly+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/wildfly/3086d43a-82ce-408c-8047-97a058f8fd25%40googlegroups.com.

[pankaj narkhede]

Hi Ondra,

We have enabled below trace in our domain and please see log (server.log) which has success as well as error.

Could you please review and let us know your inputs?

Thanks & Regards,

Pankaj Narkhede

To unsubscribe from this group and stop receiving emails from it, send an email to wil...@googlegroups.com.

[pankaj narkhede]

Hi Ondra,

Did you get a chance to review logs? 

Thanks & Regards,

Pankaj Narkhede

[Ondra Chaloupka]

Hi Pankaj,

Thanks for asking, there was a national holiday at the end of the last week and I haven't got to check your logs yet. But as I'm doing right now I'm if I can see the errors.

By my interpretation the log you provided contains two types of "errors". First is trouble with read-operation error[1] and second is trace logging of NoSuchEJBException[2] (which you've referred about, right?).

The second trouble[2] is in fact not a trouble - particularly in this server. It's TRACE logging and it could be that remoting tries the different options to connect to and it's logging these attempts under TRACE. Such processing is expected and usually not seen by users as it's not common to have TRACE logging category enabled. As it could be seen later in the log the remoting says that it's not able to get the bean but just in a couple of seconds is capable of reaching it[3]. As there is no ERROR or stacktrace seen it seems fine to me. Or is it that this TRACE log is promoted to your application as an Exception?

I wonder if the first error[1] could be somehow connected to what we are discussing here. It seems to be like the ear would be undeployed and deployed again in a minute. Could that be? Could be that the EAR file just disappears for a while and is redeployed on the target server as well? If you can track intermittent failures for the time the EAR is not available (under redeployment) on the target server then the ejb client throws the exception that it's not capable of getting the EJB but when the EAR is deployed again it can reach it. Could that be something similar for your case?

Btw. If you plan to provide some more logs for discussion it would be great if you can provide the logs from both servers - from the server which calls (the log which was provided this time) and from the second server which contains the EJB which is called. It could shed some light on what's happening on both servers at that particular time.

Ondra

[1] 2020-05-07 11:43:50,817 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 89) WFLYCTL0013: Operation ("read-attribute") failed - address: ([
    ("deployment" => "dbusPrimeBiller5QReaderEAP5.ear"),
    ("subdeployment" => "dbusJMSReaderEJB3.jar"),
    ("subsystem" => "ejb3"),
    ("message-driven-bean" => "dbusJMSReaderEJB")

    ....

[2] 2020-05-07 16:57:37,974 TRACE [org.jboss.ejb.client] (default-threads - 46) Encountered exception while calling getResult(): exception = javax.ejb.NoSuchEJBException: EJBCLIENT000079: Unable to discover destination for request for EJB StatelessEJBLocator for "dbusEAP5/dbusEJB3/DbusBean", view is interface com.sbc.dbus.ejb.Dbus, affinity is None

[3] 2020-05-07 16:56:39,418 DEBUG [org.jboss.ejb.client.invocation] (default-threads - 43) Calling invoke(module = dbusEAP5/dbusEJB3/DbusBean, strong affinity = None, weak affinity = None):
2020-05-07 16:56:39,419 DEBUG [org.jboss.ejb.client.invocation] (default-threads - 43) sendRequest: calling interceptor: org.jboss.ejb.client.TransactionInterceptor@31f07db

To unsubscribe from this group and stop receiving emails from it, send an email to wildfly+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/wildfly/fbe00b20-4271-4c4c-92a9-8fef2c6b4a4b%40googlegroups.com.

[pankaj narkhede]

Hi Ondra,

Thanks for taking time to review logs. 

[1] - this error is valid and can be ignored as respective MQ Queue is not present and hence error

for [2] and [3] - please find updated logs for server and client logs. dbusreader is the jvm which has all mdbs which is calling dbusEJB on dbusjvm.

in Application logs also we are seeing same EJB exception which is causing our readers to go down. 

I didnt find any redeployment log for dbus EAR in dbus jvm. 

Thanks & Regards,

Pankaj Narkhede

To view this discussion on the web visit https://groups.google.com/d/msgid/wildfly/fbe00b20-4271-4c4c-92a9-8fef2c6b4a4b%40googlegroups.com.

[Ondra Chaloupka]

Hi Pankaj,

I apologize but I'm not able to find much more from the logs.

If I get it right the file 'server.log' is one you referring to as the client, the 'server.log_dbus' is the other you referring to as server.

The client deploys the message driven beans, when the message is processed there is the EJB remote call to the server.

I was interested if there could be some more information found if I compare the time in server.log when NoSuchEJBException is thrown from the client and the log messages at server.

Unfortunately, the first NoSuchEJBException is shown in server.log at 16:56:37[1] but the server.log_dbus ends at 16:25:58.

The other thing is that the server.log contains only TRACE logging messages.They should be just fine. I was not able to find the message from your prior email[2] in the logs.

What does it mean for your "readers to go down"? I can't see such a thing in the log either.

Kind regards,

Ondra

[1] 2020-05-07 16:56:37,873 TRACE [org.jboss.ejb.client] (default-threads - 44) Encountered exception while calling getResult(): exception = javax.ejb.NoSuchEJBException: EJBCLIENT000079: Unable to discover destination for request for EJB StatelessEJBLocator for "dbusEAP5/dbusEJB3/DbusBean", view is interface com.sbc.dbus.ejb.Dbus, affinity is None

[2]

default-threads - 34] ERROR-633521018_iPkakdIXGGyPkrPR@631037154_80986331_16404_1_0 46673421 10 DbusJMSReaderBean.55 [602] onMessage ProcessEventRequiresNew failed: javax.ejb.NoSuchEJBException: EJBCLIENT000079: Unable to discover destination for request for EJB StatelessEJBLocator for "dbusEAP5/dbusEJB3/DbusBean", view is interface com.sbc.dbus.ejb.Dbus, affinity is None

To unsubscribe from this group and stop receiving emails from it, send an email to wildfly+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/wildfly/ae9ce90d-be70-4e65-9a0e-4650a8154a48%40googlegroups.com.

[pankaj narkhede]

Hi Ondra,

Sorry for any confusion.

If I get it right the file 'server.log' is one you referring to as the client, the 'server.log_dbus' is the other you referring to as server. - correct 

I was interested if there could be some more information found if I compare the time in server.log when NoSuchEJBException is thrown from the client and the log messages at server.

Unfortunately, the first NoSuchEJBException is shown in server.log at 16:56:37[1] but the server.log_dbus ends at 16:25:58.  -  This is the only logging we are seeing in logs after enabling TRACE. we are seeing only EJBCLIENT exception in the logs. Please find updated server.log.2020-05-12 for dbus jvm which has complete log.

What does it mean for your "readers to go down"? I can't see such a thing in the log either. - We have MQ manager which has Queues/listeners configured for each mdb. After no of unsuccessful retries our Quesus/listeners goes down. 

Thanks & Regards,

Pankaj Narkhede

To view this discussion on the web visit https://groups.google.com/d/msgid/wildfly/ae9ce90d-be70-4e65-9a0e-4650a8154a48%40googlegroups.com.

[Ondra Chaloupka]

Hi Pankaj,

thanks for confirmation but I can't get it.

The exceptions in the TRACE logging does not mean there is something wrong. The TRACE log may show some exceptions that may help in investigation of the behaviour. But if it's TRACE it means the code/library recovers from such situations and continue working. E.g. in this case the TRACE logging shows there is retry of the connection. And if I don't see it wrong the connection is successful at the end (there is no ERROR or Exception stacktrace).

If you can see only those TRACE logging information in the log then it's fine and there is no trouble.

If there is some trouble for your application based on what the WildFly server does then first I would expect to see some ERRORs in the log second, there is some impact to your application (aka. something you refer to as "readers to go down").

If it's not the case then just switch off the trace logging and you are fine.

Ondra

To unsubscribe from this group and stop receiving emails from it, send an email to wildfly+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/wildfly/d99c2962-3267-447e-88b9-5cc8a6514e8a%40googlegroups.com.