My use case is only with SSLFilter. We want secure communication between application and sniffer. We reverted to mina 2.0.25,we are not facing this issue now.
I would like to know what is the difference between 2.0.25 and 2.2.1/2.2.3. On Sat, 17 Feb, 2024, 6:37 pm Jonathan Valliere, <john...@apache.org> wrote: > 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 >> >
