Yes, multithreaded.

The affected EJB method calls were done

in the run() of a TimerTask

or

in the run() of javax.swing.SwingUtilities.invokeLater()

Our client uses approx. 5 threads and a few JMS topic subscriber.

Just for info, this is the content of our JNDI properties file

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

remote.connections=default

remote.connection.default.connect.options.org.xnio.Options.SSL_STARTTLS=false

remote.connection.default.host=oliver2

remote.connection.default.port=9000

remote.connection.default.connect.options.org.xnio.Options.SASL_POLICY_NOANONYMOUS=false

remote.connection.default.username=xxxx

remote.connection.default.password=yyyy

We use one context for all threads.

Could too small values for MAX_OUTBOUND_MESSAGES and  MAX_INBOUND_MESSAGES cause a

“channel is busy” exception?

MAX_OUTBOUND_MESSAGES has default of 80.

https://docs.jboss.org/author/display/EJBCLIENT/Overview+of+Client+properties

But what is the default for MAX_INBOUND_MESSAGES?

I have set following connection options:

remote.connection.default.channel.options.org.jboss.remoting3.RemotingOptions.MAX_OUTBOUND_MESSAGES=200

remote.connection.default.channel.options.org.jboss.remoting3.RemotingOptions.MAX_INBOUND_MESSAGES=200

but if my client runs for a while (some hours), I get on client side still:

org.jboss.remoting3.ChannelBusyException: JBREM000207: Failed to send a message (channel is busy)

at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:214)

So it seems, the (channel is busy) has nothing to do with these options.

But what else can I do?

Thanks.

We have migrated to WildFly 8.0.0.Final and the "channel is busy" problem has not occurred anymore.

It seems the major remoting changes with Wildfly (http-remoting, new  EJB Client) fixed the problem.

Oliver