I can't reproduce this being fixed.

Doing everything the original reporter suggests (setting the options on the client and on the server and setting log level for org.xnio.channels.framed to TRACE), I can still see the original behavior (options are honored on the client, but not on the server).

I even went as far as doing this:

--- a/src/main/java/org/jboss/remoting3/remote/RemoteConnectionProvider.java
+++ b/src/main/java/org/jboss/remoting3/remote/RemoteConnectionProvider.java
@@ -103,6 +103,8 @@ final class RemoteConnectionProvider extends AbstractHandleableCloseable<Connect
         xnioWorker = connectionProviderContext.getXnioWorker();
         this.connectionProviderContext = connectionProviderContext;
         defaultBufferSize = optionMap.get(RemotingOptions.RECEIVE_BUFFER_SIZE, RemotingOptions.DEFAULT_RECEIVE_BUFFER_SIZE);
+        log.info("!!!!!!!!!!!!!!!!!!!!!!!!!!!! default buffer size = " + defaultBufferSize);
+        log.info("!!!!!!!!!!!!!!!!!!!!!!!!!!!! optionMap = " + optionMap);
         MBeanServer server = null;
         ObjectName objectName = null;
         try {

And the only time this gets printed out is during application server startup:

12:48:17,874 INFO  [org.jboss.remoting.remote] (MSC service thread 1-3) !!!!!!!!!!!!!!!!!!!!!!!!!!!! default buffer size = 8192
12:48:17,874 INFO  [org.jboss.remoting.remote] (MSC service thread 1-4) !!!!!!!!!!!!!!!!!!!!!!!!!!!! default buffer size = 8192
12:48:17,876 INFO  [org.jboss.remoting.remote] (MSC service thread 1-4) !!!!!!!!!!!!!!!!!!!!!!!!!!!! optionMap = {org.jboss.remoting3.RemotingOptions.RECEIVE_WINDOW_SIZE=>32768}
12:48:17,878 INFO  [org.jboss.remoting.remote] (MSC service thread 1-3) !!!!!!!!!!!!!!!!!!!!!!!!!!!! optionMap = {org.xnio.Options.WORKER_TASK_KEEPALIVE=>60,org.xnio.Options.WORKER_WRITE_THREADS=>1,org.xnio.Options.WORKER_TASK_CORE_THREADS=>4,org.xnio.Options.WORKER_TASK_LIMIT=>16384,org.xnio.Options.WORKER_TASK_MAX_THREADS=>16,org.xnio.Options.WORKER_READ_THREADS=>1}

When doing an EJB call, the XNIO trace log show that the buffers are indeed still 8192 bytes long on the server:

12:50:49,605 TRACE [org.xnio.channels.framed] (Remoting "argondie" read-1) Created new framed message channel around TCP socket channel (NIO) <45a270b2>, receive buffer Pooled buffer java.nio.HeapByteBuffer[pos=0 lim=8196 cap=8196], transmit buffer Pooled buffer java.nio.HeapByteBuffer[pos=0 lim=8196 cap=8196]

It's entirey possible I configured this wrong (I copied the excerpts from the original reporter, both the changes in the ejb3 subsystem and in the remoting subsystem). On the client, I'm also using scoped client contexts, just like the original reporter. Could you please advise?

I can't reproduce this not being fixed. :-)

Maybe Brad or Coty might be a better one to ask?  You are probably just setting the option in the wrong place (or not bundling the JAR correctly or something), I guess.

Thanks, David.

Coty, could you please provide a reproducer (that shows that it's fixed)? I tried, but I still see the bug.

Created attachment 933898 [details]
Small reproducer to demonstrate the buffer changes.

I put a readme in there with instructions on how to run it. Its just a helloWorld EAR deployed and then call from a client. Both ends buffer sizes have been configured to 65k. I ran this on EAP 6.2.0 OOB and saw that the changes did not apply. After I applied the patch (also provided), then I am able to set the buffer sizes.

Coty, thanks for your reproducer. It confirmed that I'm not doing anything wrong -- I'm able to verify the fix with EAP 6.2.0 and your patched Remoting JAR, using both your reproducer and my own (they are conceptually the same).

However, I'm _not_ able to verify the fix with EAP 6.3.1.CR1. Either the Remoting JAR in 6.3.1.CR1 doesn't contain the fix, or the Remoting subsystem in EAP has changed since 6.2.0 so that patching Remoting itself is not enough. Or something else, not sure.

Anyway, FailedQA and current status ASSIGNED are correct from my POV.