Remoting config-based-ejb-client-endpoint threads remain after context.close()

[mph999]

( Wildfly 10.1.0.Final, Windows 10 )

Hi,

we have a client app framework which launches component apps, loading their classes dynamically.

One of these apps uses EJBs and I've just updated from JBoss 4 to Wildfly 10.1.0.Final.

It runs nicely, the ejbs get looked up (not using Scoped EJB client contexts), and ejb calls work.

When the app closes, initialContext.close() is called, and 2 or 3 threads close, but about 18 threads hang around

(Remoting  "config-based-ejb-client-endpoint" I/O-1, Accept, task-1 ...task-16 ) which is a show stopper.

I've replicated this behaviour using a modified quickstart ejb-remote/client project, and the context and remote beans eventually get GC'd

These worker threads eventually get shutdown when the main app closes, it looks like by a VM shutdown hook.

I couldn't get Scoped EJB client contexts to work, which is a separate issue, but I shouldn't need to, should I?

I've tried adding KEEP_ALIVE options to jboss-ejb-client.properties, to no avail:

remote.connectionprovider.create.options.org.xnio.Options.KEEP_ALIVE=false

remote.connectionprovider.create.options.org.xnio.Options.WORKER_TASK_KEEPALIVE=5000

I really need to be able to shut these threads down when the component app closes.

(As the component app launches with a new classloader each time, we get 18 threads created each time)

Many thanks for any help.

[jaikiran]

Can you attach a thread dump of the state you reach when the context is closed?

On a different note, WildFly 11 has been released WildFly 11 Final is now available! · WildFly , maybe you might want to upgrade to that.

[mph999]

Hi Jaikiran,

many thanks for replying. I've attached the thread dump after the context.close() call. I've been looking at the code, stepping through with the debugger on creation, and the code to close these workers is indeed added as JVM shutdown hooks.

I also tried Wildfly 11 this morning, with the ejb-remote/client quickstart app, without the dynamic classloading and the gui mods, but the principle is the same.

The Worker thread creation has changed a lot since Wildfly 10, but the shutdown of the worker threads is still only done at JVM shutdown, and the Context.close() method (of the defaultInitCtx) now looks completely empty.

If there is absolutely no option to manually terminate the ejb receivers on the client end, I will have to launch this particular component app in a separate VM

[jaikiran]

I actually misread your first post a bit. I thought you were using (JNDI) scoped EJB client contexts in WildFly 10. Now that I read it again, you in fact aren't using it. What that means is the JNDI context close that you are doing won't have an effect on the EJB client context which is scoped to the application. What you need to do is, close the (right) EJBClientContext when you are done with it. I say "right" EJBClientContext because I haven't seen your application code to know how many or who creates them. If it's just one EJBClientContext (which I guess is the case), then all you have to do is EJBClientContext.getCurrent().close(), when your application is done with its usage of EJBs.

[mph999]

Many thanks, Jaikiran,

I've tried that now with Wildfly 10, (needed to modify the pom to set the scope for wildfly-ejb-client-bom to compile)  and it works!

(the config-based-ejb-client-endpoint and config-based-naming-client-endpoint threads stopped immediately on EjbClientContext.getCurrent.close(),

the ejb-client-context-tasks-1-threads (1-3) stopped after a couple of GC's. )

But...

it looks like EjbClientContext has lost the close() method in Wildfly 11, which would prevent us from upgrading at a later time.

Is there an equivalent in Wildfly 11? (or if not, any chance close() could be re-instated?)

Many thanks, again, this is a big step forward.

Best regards,

Matthew.

[jaikiran]

Matthew Harrison wrote:

Many thanks, Jaikiran,

I've tried that now with Wildfly 10, (needed to modify the pom to set the scope for wildfly-ejb-client-bom to compile) and it works!

Glad to hear

Matthew Harrison wrote:

But...

it looks like EjbClientContext has lost the close() method in Wildfly 11, which would prevent us from upgrading at a later time.

Is there an equivalent in Wildfly 11? (or if not, any chance close() could be re-instated?)

WildFly 11 has undergone certain enhancements. One of them is to improve and simplify lookup, invocations and usage of EJBs from remote clients. I haven't fully caught up on the implementation details, so I don't have the complete picture of it yet. From what I read in one JIRA, the close() method isn't needed in the new scheme of things.

You might want to read these blogs which explain the new scheme of things, around remote EJB clients, in WildFly 11:

Getting started with EJBs and Elytron Part 1: Securing EJBs and invoking them from remote clients

Getting started with EJBs and Elytron Part 2: EJB invocations from remote servers

[mph999]

But...

it looks like EjbClientContext has lost the close() method in Wildfly 11, which would prevent us from upgrading at a later time.

Is there an equivalent in Wildfly 11? (or if not, any chance close() could be re-instated?)

WildFly 11 has undergone certain enhancements. One of them is to improve and simplify lookup, invocations and usage of EJBs from remote clients. I haven't fully caught up on the implementation details, so I don't have the complete picture of it yet. From what I read in one JIRA, the close() method isn't needed in the new scheme of things.

Many thanks for the links, I was able to reduce the size of the worker task pool using the new wildfly-config.xml, but they still live until VM shutdown.

So I've only slowed down the eventual exhaustion of threads (and memory, due to the URLClassLoader, and all its loaded classes, and any objects being pinned in place by the threads).

To be able to upgrade to Wildfly 11, I still need some means of closing the connections and worker threads ( or of triggering that) when the client app knows they will no longer be needed.

Best rgds,

Matthew.

[mph999]

I asked here for Wildfly 11 [JBEAP-9401] EJBClientContext needs a close() method - JBoss Issue Tracker

and got an answer from David Lloyd.

So a big thank you, Jaikiran, I think I can go ahead with Wildfly 10, now that I also know that Wildfly 11 is also possible for us.