There is also some additional complexity supporting the scenario where two different threads are triggering “receive” events on the filter.
We either have to process ALL messages out of the payload, then AFTER send them to the downstream filters or we have to perform a kind of dual-locking mechanism to ensure that multiple receiver threads to not operate in parallel. Either way, we have to guarantee a serial processing of incoming messages. The more I think about it the more concerned I am that we’re following a rabbit down a hole. @Kishore Mokkarala <kishore....@gmail.com> have you tried NOT using the SSL and instead creating a dummy filter which simply added synchronized to the receive and write method? I would be interested to know if that causes the problem also. Put this dummy filter in the same place as the SSL would be. On Feb 17, 2024 at 2:00:30 AM, Emmanuel Lécharny <elecha...@gmail.com> wrote: > Hi Jonathan, > > there are two aspects to consider: > > - first the establishemnt of the secured session > - second the standard exchange of data when the session has been secured. > > In the first case, we should *never* have any write done by the > IoHandler, or those writes should be enqueued until the session has been > secured. Here, the upstream filters should not be aware that the session > has been secured or not (all in all, filters are supposed to be > independenct) > > In the second case, the SslFilter is responsible for handling the > encoding and decoding of the data, regardless of what the upper filters > are doing > > So there should not be any assumption made on what wcould or should do > the upstream filters (that's because anyone can add a filter, and we > should not force the implementors to take care of unerlying filters > constraints). > > So the best way to deal with writes while the Secured session > establishment is ongoing is to enqueue the writes until the session is > secured. It adds some complexity, but it's safe for the full stack > (reads are a different beast: we have to assume that we can only read > Handshake packets until the HS is completed) > > I guess it fits with what you have in mind. > > > On 17/02/2024 04:12, Jonathan Valliere wrote: > > I was thinking this over last weekend…. > > > If I simply removed the synchronization then there COULD be several > > incoming data corruption problems unless the upstream filters/ processors > > MUST guarantee FIFO of the data stream. > > > What I would have todo is push OR copy the incoming buffer into a Queue > > then perform processing off the head of that Queue. Essentially, do the > > same as the mEncodeQueue but for Decodes. The lock would then only be held > > when processing data off of that Decode queue. Following this pattern, I > > could probably remove both the READ and WRITE synchronization blocks. > > > My understanding, for MINA, that the assumption is that it SHOULD be safe > > to hold on to any object passed into a Filter since object lifecycles > > SHOULD be controlled by the VM and not the User’s code. > > > If we’re in agreement, I can make the change. > > > > On Feb 10, 2024 at 2:14:01 PM, Kishore Mokkarala <kishore....@gmail.com> > > wrote: > > > > Any time line for removing synchronization block in SSLFilter? > > > > > > On Sat, 10 Feb, 2024, 9:48 pm Emmanuel Lécharny, <elecha...@gmail.com> > > > wrote: > > > > > > Netty is not Apache, but Eclipse. > > > > > > > > > We are discussing the error at the moment, trying to move away the > > > > > > SSLFilter synchronized block. > > > > > > > > > On 10/02/2024 08:10, Kishore Mokkarala wrote: > > > > > >> We had to revert mina version to 2.0.25 from 2.2.1 to make it work in > > > > > >> production and trying for other alternatives like apache netty. > > > > > >> > > > > > >> On Fri, 9 Feb, 2024, 1:59 pm Emmanuel Lécharny, <elecha...@gmail.com > > > > > >> <mailto:elecha...@gmail.com>> wrote: > > > > > >> > > > > > >> Hi Jonathan, > > > > > >> > > > > > >> in this very case, I think there is a race condition when using the > > > > > >> SSLFilter in conjonction with the StateMachine filter. > > > > > >> > > > > > >> On 09/02/2024 05:33, Jonathan Valliere wrote: > > > > > >> > No, you should not have to create multiple instances. The > > > > > >> necessary > > > > > >> > stateful data is saved to the Connection. > > > > > >> > > > > > > >> > > > > > > >> > On Feb 1, 2024 at 5:22:36 AM, Kishore Mokkarala > > > > > >> <kishore....@gmail.com <mailto:kishore....@gmail.com>> > > > > > >> > wrote: > > > > > >> > > > > > > >> >> Any response would be greatly appreciated. > > > > > >> >> ------------------------------------------ > > > > > >> >> M.V.S.Kishore > > > > > >> >> 91-9886412814 > > > > > >> >> > > > > > >> >> > > > > > >> >> On Wed, 31 Jan 2024 at 22:17, Kishore Mokkarala > > > > > >> <kishore....@gmail.com <mailto:kishore....@gmail.com>> > > > > > >> >> wrote: > > > > > >> >> > > > > > >> >> Hi Emmanuel, > > > > > >> >> > > > > > >> >> > > > > > >> >> Do we need to create a new instance of SSLFilter per tcp ip > > > > > >> connection or > > > > > >> >> > > > > > >> >> can we reuse it ? > > > > > >> >> > > > > > >> >> > > > > > >> >> For example, do we need to repeat the same code for each tcp ip > > > > > >> connection > > > > > >> >> > > > > > >> >> ? > > > > > >> >> > > > > > >> >> > > > > > >> >> *Approach 1:* > > > > > >> >> > > > > > >> >> for(int i=0;i< 500;i++) > > > > > >> >> > > > > > >> >> { > > > > > >> >> > > > > > >> >> NioSocketConnector connector = new NioSocketConnector(); > > > > > >> >> > > > > > >> >> connector.getFilterChain().addLast("LoggingFilter", > > > > > >> >> > > > > > >> >> G10CaptureService.loggingFilter); > > > > > >> >> > > > > > >> >> connector.getFilterChain().addLast("codecFilter", > > > > > >> >> > > > > > >> >> G10CaptureService.probeCodecFilter); > > > > > >> >> > > > > > >> >> connector.getFilterChain().addLast("executorFilter", > > > > > >> >> > > > > > >> >> G10CaptureService.executorFilter); > > > > > >> >> > > > > > >> >> connector.getFilterChain().addLast("gpbMessageFilter", > > > > > >> >> > > > > > >> >> G10CaptureService.gpbMessageFilter); > > > > > >> >> > > > > > >> >> connector.getFilterChain().addLast("keepAliveFilter", > > > > > >> >> > > > > > >> >> G10CaptureService.keepAliveFilter); > > > > > >> >> > > > > > >> >> SslFilter sslFilter; > > > > > >> >> > > > > > >> >> try { > > > > > >> >> > > > > > >> >> SSLContext sslContext = TLSUtil.getSSLContext(); > > > > > >> >> > > > > > >> >> sslFilter = new CustomSslFilter(sslContext); > > > > > >> >> > > > > > >> >> connector.getFilterChain().addFirst("sslFilter", sslFilter); > > > > > >> >> > > > > > >> >> } catch (Exception e) { > > > > > >> >> > > > > > >> >> e.printStackTrace(); > > > > > >> >> > > > > > >> >> LOG.error("Exception during creating SSL context..." + > > > > > >> >> > > > > > >> >> XError.getStackTrace(e)); > > > > > >> >> > > > > > >> >> } > > > > > >> >> > > > > > >> >> //io handler creation > > > > > >> >> > > > > > >> >> StateMachine stateMachine = > > > > > >> >> > > > > > >> >> > > > > > > StateMachineFactory.getInstance(IoHandlerTransition.class).create( > > > > > >> >> > > > > > >> >> G10MinaClient.CONNECTED, new > > > > > >> G10MinaClient(processor)); > > > > > >> >> > > > > > >> >> > > > > > >> >> IoHandler ioHandler = new > > > > > >> >> > > > > > >> >> StateMachineProxyBuilder().setStateContextLookup( > > > > > >> >> > > > > > >> >> new IoSessionStateContextLookup(new > > > > > >> StateContextFactory() { > > > > > >> >> > > > > > >> >> @Override > > > > > >> >> > > > > > >> >> public StateContext create() { > > > > > >> >> > > > > > >> >> final G10StateContext stateContext = > new > > > > > >> >> > > > > > >> >> G10StateContext(); > > > > > >> >> > > > > > >> >> stateContext.setStartedTime(new > Date()); > > > > > >> >> > > > > > >> >> LOG.info("G10StateContext initialized > > > > > > at:{} > > > > > >> >> > > > > > >> >> ",System.currentTimeMillis()); > > > > > >> >> > > > > > >> >> return stateContext; > > > > > >> >> > > > > > >> >> } > > > > > >> >> > > > > > >> >> })).create(IoHandler.class, stateMachine); > > > > > >> >> > > > > > >> >> connector.setHandler(ioHandler); > > > > > >> >> > > > > > >> >> connector.connect(primaryAddress); > > > > > >> >> > > > > > >> >> connectFuture.awaitUninterruptibly(); > > > > > >> >> > > > > > >> >> if (connectFuture.isConnected()) { > > > > > >> >> > > > > > >> >> IoSession session = connectFuture.getSession(); > > > > > >> >> > > > > > >> >> // Do something with the session if needed > > > > > >> >> > > > > > >> >> } else { > > > > > >> >> > > > > > >> >> System.err.println("Connection failed for iteration: " + i); > > > > > >> >> > > > > > >> >> } > > > > > >> >> > > > > > >> >> } > > > > > >> >> > > > > > >> >> > > > > > >> >> *Approach 2:* > > > > > >> >> > > > > > >> >> Reuse the generic connector implemented above for opening all > > > > > > TCP/IP > > > > > >> >> > > > > > >> >> connections. > > > > > >> >> > > > > > >> >> //just do the below for getting connections for example > > > > > >> >> > > > > > >> >> NioSocketConnector connector = new NioSocketConnector(); > > > > > >> >> > > > > > >> >> //filter chain creation > > > > > >> >> > > > > > >> >> //add SSLFilter to filer chain > > > > > >> >> > > > > > >> >> > > > > > >> >> for(int i=0;i< 500;i++) > > > > > >> >> > > > > > >> >> { > > > > > >> >> > > > > > >> >> ConnectFuture connectFuture = connector.connect(serverAddress); > > > > > >> >> > > > > > >> >> connectFuture.awaitUninterruptibly(); > > > > > >> >> > > > > > >> >> if (connectFuture.isConnected()) { > > > > > >> >> > > > > > >> >> IoSession session = connectFuture.getSession(); > > > > > >> >> > > > > > >> >> // Do something with the session if needed > > > > > >> >> > > > > > >> >> } else { > > > > > >> >> > > > > > >> >> System.err.println("Connection failed for iteration: " + i); > > > > > >> >> > > > > > >> >> } > > > > > >> >> > > > > > >> >> } > > > > > >> >> > > > > > >> >> > > > > > >> >> Which approach is better ? > > > > > >> >> > > > > > >> >> > > > > > >> >> Regards, > > > > > >> >> > > > > > >> >> ------------------------------------------ > > > > > >> >> > > > > > >> >> M.V.S.Kishore > > > > > >> >> > > > > > >> >> 91-9886412814 > > > > > >> >> > > > > > >> >> > > > > > >> >> > > > > > >> > > > > > > >> > > > > > >> -- > > > > > >> *Emmanuel Lécharny* P. +33 (0)6 08 33 32 61 > > > > > >> elecha...@apache.org <mailto:elecha...@apache.org> > > > > > >> > > > > > >> > --------------------------------------------------------------------- > > > > > >> To unsubscribe, e-mail: users-unsubscr...@mina.apache.org > > > > > >> <mailto:users-unsubscr...@mina.apache.org> > > > > > >> For additional commands, e-mail: users-h...@mina.apache.org > > > > > >> <mailto:users-h...@mina.apache.org> > > > > > >> > > > > > > > > > -- > > > > > > *Emmanuel Lécharny* P. +33 (0)6 08 33 32 61 > > > > > > elecha...@apache.org > > > > > > > > > > > > > -- > *Emmanuel Lécharny* P. +33 (0)6 08 33 32 61 > elecha...@apache.org >
