Okay, let me know when you’re able to test with that branch. I think it
should solve your problem.
On Feb 20, 2024 at 6:32:06 AM, Kishore Mokkarala
wrote:
> @ Valliere I am not available for a week.
>
> On Tue, 20 Feb, 2024, 8:59 am Jonathan Valliere,
> wrote:
>
> @Kishore Mokkarala are you
@ Valliere I am not available for a week.
On Tue, 20 Feb, 2024, 8:59 am Jonathan Valliere, wrote:
> @Kishore Mokkarala are you able to test this
> branch? https://github.com/apache/mina/compare/2.2.X...bugfix/DIRMINA-1173
>
> On Feb 18, 2024 at 2:05:57 PM, Jonathan Valliere
> wrote:
>
>> The
@Kishore Mokkarala are you able to test this
branch? https://github.com/apache/mina/compare/2.2.X...bugfix/DIRMINA-1173
On Feb 18, 2024 at 2:05:57 PM, Jonathan Valliere wrote:
> The other diagram possibly had a consumer order issue. While the Queue
> will guarantee that the messages will be
The other diagram possibly had a consumer order issue. While the Queue
will guarantee that the messages will be pulled out of the Queue in order,
they do not guarantee that the processing of the messages will happen in
order.
The new diagram implements 3 synchronization objects. This will
Emmanuel,
The attached diagram is how I figured out we can solve this. The downside
is that it requires more concurrent queues and more lock/unlock but I think
it should ensure correct execution order.
I’m working on this now as SSLHandlerG1 so it stays separate from the
reference
Hi Jonathan,
I don'ty exclude we could also solve the issue by tweeking the
StateMachine filter. For instance, do we really need to take a lock
while processing the SessionOpened in the SM Filter?
I'm not very into the SM filter code, I have to study it, but that would
potentially save you
Okay so I need to figure out how to work it so no lock is held while
calling either the upper or lower filter.
CONFIDENTIALITY NOTICE: The contents of this email message and any
attachments are intended solely for the addressee(s) and may contain
confidential and/or privileged information and may
Hi Jonathan,
Kishore provided a thrzad dump a few weeks ago, which shows that there
is a lock:
NioProcessor-12
---
stackTrace:
java.lang.Thread.State: BLOCKED (on object monitor)
at org.apache.mina.statemachine.StateMachine.handle(StateMachine.java:138)
- waiting to lock
I’m trying to understand specifically, if its how the new SSL implements a
synchronized block on the receive and write IoFilter functions that is
causing this problem for you.
Before we go down various paths in trying to figure how to remove the
synchronized blocks, I would like to confirm that
These changes in 2.2.x might have introduced deadlock in conjunction with
the state machine.
--
M.V.S.Kishore
91-9886412814
On Sat, 17 Feb 2024 at 22:12, Emmanuel Lécharny wrote:
>
>
> On 17/02/2024 16:13, Kishore Mokkarala wrote:
> > My use case is only
On 17/02/2024 16:13, Kishore Mokkarala wrote:
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.
Hi Jonathan,
regarding the queing, we did that in MINA 2.1:
public void filterWrite(NextFilter nextFilter, IoSession session,
WriteRequest writeRequest) throws SSLException {
if (LOGGER.isDebugEnabled()) {
LOGGER.debug("{}: Writing Message : {}",
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, 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
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
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
Any time line for removing synchronization block in SSLFilter?
On Sat, 10 Feb, 2024, 9:48 pm Emmanuel Lécharny,
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
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
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, wrote:
> Hi Jonathan,
>
> in this very case, I think there is a race condition when using the
> SSLFilter in
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
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
wrote:
> Any response would be greatly appreciated.
> --
> M.V.S.Kishore
> 91-9886412814
>
>
>
Any response would be greatly appreciated.
--
M.V.S.Kishore
91-9886412814
On Wed, 31 Jan 2024 at 22:17, Kishore Mokkarala
wrote:
> Hi Emmanuel,
>
> Do we need to create a new instance of SSLFilter per tcp ip connection or
> can we reuse it ?
>
> For
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();
23 matches
Mail list logo
