Re: [ASK] Proper Handling of Concurrency

[Emmanuel Lécharny]

Hi Bobby,

the Acceptor will spread the load across many threads (where many = nb 
core +1, so with a 8 core CPU, you will have a pool with 9 threads).


That can be tuned, but the idea is to use the CPU as much as possible.

Note that for an UDP session, it will use the same IoProcessor, so the 
same thread (sticky thread, sort of)


The ExecutorFilter is your addition, it also use a pool of threads for 
some other means. It *may* be useful if you have asynchronous I/O that 
may take some time. Usually, it's rare you need to use a thread pool in 
the chain: if you already are at 100% CPU use (or close to that), adding 
more threads are a waste.


On 30/04/2024 04:09, Bobby R. Harsono wrote:

Good day,

I built a UDP Server using Mina, however i need to async'ed several 
operations;
Currently, i have exactly one class extends IoHandlerAdapter called 
MainHandler, i wrote all of operations in this class.


Now, within Bootstrap building, i notice that there are several points 
that using Thread(pool),


#1 acceptor = new NioDatagramAcceptor(Executors.newCachedThreadPool());
#2 DefaultIoFilterChainBuilder chain = acceptor.getFilterChain();
chain.addLast("threadPool", new 
ExecutorFilter(Executors.newCachedThreadPool()));
#3 Also, my SPV write a class that extends Thread to enable 
ThreadedMainHandler class (see above)


I can't find clear explanations of what does the different between using 
thread like the above, i mean, what is the DO and DON'T here;

Did i do this wrong? or maybe i dont need to do one of them?

Currently this application is running well (around 10k TPS per core, so 
in production, one deployment can handle around 80-100k TPS), however i 
would like to see the explanations of those points if anyone don't mind


Thanks
Bobby



--
*Emmanuel Lécharny* P. +33 (0)6 08 33 32 61
elecha...@apache.org

-
To unsubscribe, e-mail: users-unsubscr...@mina.apache.org
For additional commands, e-mail: users-h...@mina.apache.org

Re: Individual SSLFilter per connector

[Emmanuel Lécharny]

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 some time...


On 18/02/2024 01:33, Jonathan Valliere wrote:
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 be legally protected 
from disclosure.



On Sat, Feb 17, 2024 at 5:06 PM Emmanuel Lécharny <mailto:elecha...@gmail.com>> wrote:


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 <0x7fc1611faec8> (a
com.netscout.nsaapp.geo.minaG10Proto.server.G10StateContext)
at

org.apache.mina.statemachine.StateMachineProxyBuilder$MethodInvocationHandler.invoke(StateMachineProxyBuilder.java:261)
at jdk.proxy4.$Proxy83.event(jdk.proxy4/Unknown Source)
at

org.apache.mina.core.filterchain.DefaultIoFilterChain$TailFilter.event(DefaultIoFilterChain.java:1039)
at

org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextFilterEvent(DefaultIoFilterChain.java:789)
at

org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1700(DefaultIoFilterChain.java:49)
at

org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.event(DefaultIoFilterChain.java:1164)
at

org.apache.mina.core.filterchain.IoFilterAdapter.event(IoFilterAdapter.java:162)
at

org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextFilterEvent(DefaultIoFilterChain.java:789)
at

org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1700(DefaultIoFilterChain.java:49)
at

org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.event(DefaultIoFilterChain.java:1164)
at

org.apache.mina.core.filterchain.IoFilterAdapter.event(IoFilterAdapter.java:162)
at

org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextFilterEvent(DefaultIoFilterChain.java:789)
at

org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1700(DefaultIoFilterChain.java:49)
at

org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.event(DefaultIoFilterChain.java:1164)
at

org.apache.mina.core.filterchain.IoFilterAdapter.event(IoFilterAdapter.java:162)
at

org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextFilterEvent(DefaultIoFilterChain.java:789)
at

org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1700(DefaultIoFilterChain.java:49)
at

org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.event(DefaultIoFilterChain.java:1164)
at

org.apache.mina.core.filterchain.IoFilterAdapter.event(IoFilterAdapter.java:162)
at

org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextFilterEvent(DefaultIoFilterChain.java:789)
at

org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1700(DefaultIoFilterChain.java:49)
at

org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.event(DefaultIoFilterChain.java:1164)
at

org.apache.mina.core.filterchain.IoFilterAdapter.event(IoFilterAdapter.java:162)
at

org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextFilterEvent(DefaultIoFilterChain.java:789)
at

org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1700(DefaultIoFilterChain.java:49)
at

org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.event(DefaultIoFilterChain.java:1164)
at

org.apache.mina.filter.ssl.SSLHandlerG0.finish_handshake(SSLHandlerG0.java:589)
- locked <0x7fc1611fb470> (a
org.apache.mina.filter.ssl.SSLHandlerG0)
at
org.apache.mina.filter.ssl.SSLHandlerG0.receive_loop(SSLHandlerG0.java:271)
at
org.apache.mina.filter.ssl.SSLHandlerG0.receive_loop(SSLHandlerG0.java:246)
at
org.apache.mina.filter.ssl.SSLHandlerG0.receive_loop(SSLHandlerG0.java:246)
at
org.apache.mina.filter.ssl.SSLHandlerG0.receive(SSLHandlerG0.java:162)
- locked <0x7fc1611fb470> (a
org.apache.mina.filter.ssl.SSLHandlerG0)
at
org.apache.mina.filter.ssl.SslFilter.messageReceived(SslFilter.java:405)
...


and


pool-120-thread-37
--
stackTrace:
java.lang.Thread.State: BLOCKED (on object monitor)
at org.apache.mina.filter.ssl.SSLHandlerG0.write(SSLHandlerG0.java:312)
- waiting 

Re: Individual SSLFilter per connector

[Emmanuel Lécharny]

oFilterChain.access$1500(DefaultIoFilterChain.java:49)
at 
org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.filterWrite(DefaultIoFilterChain.java:1146)
at 
org.apache.mina.filter.executor.ExecutorFilter.filterWrite(ExecutorFilter.java:595)
at 
org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:753)
at 
org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1500(DefaultIoFilterChain.java:49)
at 
org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.filterWrite(DefaultIoFilterChain.java:1146)
at 
com.netscout.nsaapp.geo.minaG10Proto.server.G10GPBMessageIoFilter.filterWrite(G10GPBMessageIoFilter.java:63)
at 
org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:753)
at 
org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1500(DefaultIoFilterChain.java:49)
at 
org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.filterWrite(DefaultIoFilterChain.java:1146)
at 
org.apache.mina.core.filterchain.IoFilterAdapter.filterWrite(IoFilterAdapter.java:138)
at 
org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:753)
at 
org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1500(DefaultIoFilterChain.java:49)
at 
org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.filterWrite(DefaultIoFilterChain.java:1146)
at 
org.apache.mina.core.filterchain.IoFilterAdapter.filterWrite(IoFilterAdapter.java:138)
at 
org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:753)
at 
org.apache.mina.core.filterchain.DefaultIoFilterChain.fireFilterWrite(DefaultIoFilterChain.java:746)
at 
org.apache.mina.core.session.AbstractIoSession.write(AbstractIoSession.java:575)
at 
org.apache.mina.core.session.AbstractIoSession.write(AbstractIoSession.java:520)
at 
com.netscout.nsaapp.geo.g10Plugin.g10.processor.G10PluginCaptureProcessor.verifyAndSendStartMsgs(G10PluginCaptureProcessor.java:2627)
at 
com.netscout.nsaapp.geo.g10Plugin.g10.processor.G10PluginCaptureProcessor.sessionConnected(G10PluginCaptureProcessor.java:2552)
at 
com.netscout.nsaapp.geo.minaG10Proto.server.G10MinaClient.connect(G10MinaClient.java:220)

at jdk.internal.reflect.GeneratedMethodAccessor99.invoke(Unknown Source)
at 
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@17.0.7/DelegatingMethodAccessorImpl.java:43)

at java.lang.reflect.Method.invoke(java.base@17.0.7/Method.java:568)
at 
org.apache.mina.statemachine.transition.MethodTransition.invokeMethod(MethodTransition.java:281)
at 
org.apache.mina.statemachine.transition.MethodTransition.doExecute(MethodTransition.java:232)
at 
org.apache.mina.statemachine.transition.AbstractTransition.execute(AbstractTransition.java:100)

at org.apache.mina.statemachine.StateMachine.handle(StateMachine.java:183)
at 
org.apache.mina.statemachine.StateMachine.processEvents(StateMachine.java:170)

at org.apache.mina.statemachine.StateMachine.handle(StateMachine.java:158)
- locked <0x7fc1611faec8> (a 
com.netscout.nsaapp.geo.minaG10Proto.server.G10StateContext)
at 
org.apache.mina.statemachine.StateMachineProxyBuilder$MethodInvocationHandler.invoke(StateMachineProxyBuilder.java:261)

at jdk.proxy4.$Proxy83.sessionOpened(jdk.proxy4/Unknown Source)
at 
org.apache.mina.core.filterchain.DefaultIoFilterChain$TailFilter.sessionOpened(DefaultIoFilterChain.java:940)

...


Basically, on the sessionOpened event, the StateMachine filter takes a 
lock (0x7fc1611faec8), then the IoHandler tries to write some data, 
which ends in the SslFilter.filterWrite method, which takes a lock 
(0x7fc1611fb470)


Another thread is processing the messageReceived method, go through the 
SslFilter.messageReceived method which takes a lock 
(0x7fc1611fb470), the same as in the upper thread, then goes through 
the StateMachine.handle method, which takes a lock (0x7fc1611faec8, 
already seen upper).


The IoHandler should not try to write something on the sessionOpened 
message IMO (until the session has been secured), but in any case, the 
double lock is clearly the root cause of the problem.





On 17/02/2024 17:41, Emmanuel Lécharny wrote:

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 : {}", 
getSessionInfo(session), writeRequest);

     }

     boolean needsFlush = true;
     SslHandler sslHandler = getSslSessionHandler(session);

     try {
     synchronized (sslHandler) {
     if (!isSslStarted(session)) {
     sslHandler.scheduleFilterWrite(nextFilter, 
writeRequest);

     }
...

and

     /* no qualifier */void scheduleFilterWrite(NextFilte

Re: Individual SSLFilter per connector

[Emmanuel Lécharny]

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. <http://2.2.3.>


In MINA 2.2, the SslFilter has been fully rewrote to fix some painful 
issues we had, and to add the support of TLS 1.3.


--
*Emmanuel Lécharny* P. +33 (0)6 08 33 32 61
elecha...@apache.org

-
To unsubscribe, e-mail: users-unsubscr...@mina.apache.org
For additional commands, e-mail: users-h...@mina.apache.org

Re: Individual SSLFilter per connector

[Emmanuel Lécharny]

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 : {}", 
getSessionInfo(session), writeRequest);

}

boolean needsFlush = true;
SslHandler sslHandler = getSslSessionHandler(session);

try {
synchronized (sslHandler) {
if (!isSslStarted(session)) {
sslHandler.scheduleFilterWrite(nextFilter, 
writeRequest);

}
...

and

/* no qualifier */void scheduleFilterWrite(NextFilter nextFilter, 
WriteRequest writeRequest) {
filterWriteEventQueue.add(new IoFilterEvent(nextFilter, 
IoEventType.WRITE, session, writeRequest));

}

Sobasically, of the session handshake has not been fully negociated, 
then we enqueue the write request. Pretty much what you suggest to do 
instead of using synchronized blocks around read and write.


Otherwise, comments inline:

On 17/02/2024 14:06, Jonathan Valliere wrote:

  There is also some additional complexity supporting the scenario where two
different threads are triggering “receive” events on the filter.


You mean on the same session?



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.


Actually, this is not a problem unless someone puts an executor filter 
*before the SslFilter in the chain. We process the incoming message in a 
way a given session is associated with one single IoProcessor instance, 
so all the messages for a given session should be processed sequentially 
by this Io processor. If we don't have an excutor filter before the 
Sslfilter, it should be safe.




The more I think about it the more concerned I am that we’re following a
rabbit down a hole.

@Kishore Mokkarala  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.


Another way to deal with the lock would be to check for the 
SessioSnecured event in the IoHandler side:

- if the event has not be received, then don't send writes, but enqueue them
- if the session has been secured, then you can write at will
- when teh sessionSecured even is received, unqueue the write messages.

Somehow, that should replace what I think we should do in the SslFilter.

But I don't think the burden should be put on the MINA library user...



On Feb 17, 2024 at 2:00:30 AM, Emmanuel Lécharny 
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, 

Re: Individual SSLFilter per connector

[Emmanuel Lécharny]

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 
wrote:


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 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, 


<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



 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



 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

Re: LDAP bind requests being dropped

[Emmanuel Lécharny]

Ok, so...

If you activate CODEC_LOG in DEBUG mod,e you'll have all the info about 
the PDU decoding. This part:


if ( messageContainer.getState() == TLVStateEnum.PDU_DECODED )
{
if ( CODEC_LOG.isDebugEnabled() )
{
	CODEC_LOG.debug( I18n.msg( 
I18n.MSG_14002_DECODED_LDAP_MESSAGE, messageContainer.getMessage() )	

}

Message message = messageContainer.getMessage();

decodedMessages.add( message );
messageContainer.clean();
}

will tell you if the PDU is correctly drafted, and you should get a 
meesage like:


Decoded LdapMessage: blah

in the logs for every BindRequest (and all the other requests)

If you see the PDU, but not that message, that means the PDU is 
incorrect, or that the decoding is flawed.


I'm still wanting to see the PDU, with redacted data from it.

Otherwise, when the BindRequest is decoded, it flows up to the 
LdapRequestHandler which is directly plugged on top of MINA:
- at startup the BindRequestHandler is associated with the class 
BindRequest (which is instanciated by the decoder)
- when a Bind Request is received, it's decoded and a BindRequest object 
is created
- this instance is pushed up to the DemuxingIoHandler (a MINA class), 
which select the proper handler to manage the incoming message

- last, not least, the BindRequestHandler is executed

So if the pb is not during the decoding part, then it's somewhere in 
between the decoding and the handling. There is a lack of logs because 
this part was never problematic since 2005, so my bet is that the 
decoding is failing. It's not only a bet, though, because if it's not 
that, then we are a bit naked to find out what could go wrong...


Otherwise, *if* the decodning is successful, if the BindRequest instance 
is created, if it flows up to the ApacheDS handler, then it goes through 
this function:


public void messageReceived( IoSession session, Object message ) 
throws Exception

{
if ( ( ( Request ) message ).getControls().size() > 0
&& message instanceof ResultResponseRequest )
{
// This is where we go if the request contains some controls
}

super.messageReceived( session, message );
}

It then calls this function:

public void messageReceived(IoSession session, Object message) throws 
Exception {
	MessageHandler handler = 
findReceivedMessageHandler(message.getClass());


if (handler != null) {
handler.handleMessage(session, message);
} else {
throw new UnknownMessageTypeException("No message handler 
found for message type: "

+ message.getClass().getSimpleName());
}
}

which calls the proper handler:

public void handle( LdapSession ldapSession, BindRequest 
bindRequest ) throws Exception

{
LOG.debug( "Received: {}", bindRequest );  <<--- This is 
the log you should see if teh decoding was successful


// Guard clause:  LDAP version 3
if ( !bindRequest.getVersion3() )
{
// error -> get out
...
}

// Deal with the two kinds of authentication : Simple and SASL
if ( bindRequest.isSimple() )
{
handleSimpleAuth( ldapSession, bindRequest );
}
else
{
handleSaslAuth( ldapSession, bindRequest );
}
}




On 14/02/2024 02:19, Marc Boorshtein wrote:



so you see the PDU being processed on the server, AFAIU.



Yes



Do you get any log from the BindRequestHandler?



No, we enabled logging on BindRequestHandler and see logging for other
transactions, but not these



Is this a Sasl bind request?

No, simple bind




Any control in the BindRequest?



I don't believe so but will double check.




Could you provide the PDUs?



unfortunately, no.  it only happens in production and the customer will
never let me share that.



--
*Emmanuel Lécharny* P. +33 (0)6 08 33 32 61
elecha...@apache.org

-
To unsubscribe, e-mail: users-unsubscr...@mina.apache.org
For additional commands, e-mail: users-h...@mina.apache.org

Re: LDAP bind requests being dropped

[Emmanuel Lécharny]

Hi Marc,

so you see the PDU being processed on the server, AFAIU.

Do you get any log from the BindRequestHandler?

Like the one in the handle() method:

public void handle( LdapSession ldapSession, BindRequest bindRequest ) 
throws Exception

{
LOG.debug( "Received: {}", bindRequest );

(you can set the BindRequestHandler filter in log4j configuration in 
DEBUG mode to only capture this specific logs, to avoid being flooded by 
debug logs from every other parts of the server)


Is this a Sasl bind request?

Any control in the BindRequest?

Could you provide the PDUs?

On 13/02/2024 22:12, Marc Boorshtein wrote:

I'm seeing a very strange issue where an LDAP Bind request is coming into
the server, we can see it in a packet capture, but the ApacheDS frontend is
not registering it.  There doesn't appear to be a heavy load, and for the
couple of seconds before hand it doesn't look like there are any requests.
The issue only seems to be happening during peak hours and it is
intermittent, but enough to be noticeable.  I verified that the request is
getting dropped somewhere between when the packet capture receives the
packets and when BindRequestHandler.handle gets called.  I suspect the
issue is environmental, but I don't see any evidence of it.  There are no
timeout exceptions (or exceptions of any kind).  I know this isn't much to
go on (I'm debugging this with a hand tied behind my back) but I was
wondering if this is something that has been seen?  I want to get a thread
capture, but the issue is so intermittent that I'd need someone to be
staring at the console to try to capture it.

MINA: mina-core-2.1.5.jar

Thanks
Marc



--
*Emmanuel Lécharny* P. +33 (0)6 08 33 32 61
elecha...@apache.org

-
To unsubscribe, e-mail: users-unsubscr...@mina.apache.org
For additional commands, e-mail: users-h...@mina.apache.org

Re: Individual SSLFilter per connector

[Emmanuel Lécharny]

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, <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
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
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.er

Re: Individual SSLFilter per connector

[Emmanuel Lécharny]

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 
wrote:


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 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

-
To unsubscribe, e-mail: users-unsubscr...@mina.apache.org
For additional commands, e-mail: users-h...@mina.apache.org

Re: Mina UDP Server TPS Performance is Low

[Emmanuel Lécharny]

Hi Bobby,

in your case, what needs to be checked is if you are maxing the CPU or 
not. It's very likely that your handler is waiting for Kafka to process 
some operation, locking the thread if this operation is synchronous.


In this case, the server where your MINA handler is running will 
basically do nothing but wait, and the performance might be abysmal.


Increasing the number of threads capable of handling incoming messages 
is the way to go, up to a point.


The acceptor thread pool, as you said, is maxed by the number of 
existing processor. It can be increased if needed, up to a point. So you 
are doing the right thing here, because the default NioDatagramAcceptor 
constructor does not declare a thread pool.


All in all, that should flow. What I would suggest at this point, and 
because I don't have your code, so what I say are just pure conjectures, 
would be to mock the Kafka endpoint in your handler, to see how fast the 
MINA server is doing when the mock kafka handler is doing nothing 
(eventually printing a message, but no more). That would narrow the search:

- if it's fast, MINA is not the culprit
- if it's still slow, that it will be time to go further on mina side, 
and a piece of code I can debug would then be useful.


Thanks!

On 18/01/2024 08:37, Bobby R. Harsono wrote:

Hi Emmanuel,


By increasing num of threads of handling, i believe i have done so,

*|UDPListener| --> |MainAdapterHandler| --> |KafkaProducer|*

This is basic of my application, so to summarize

 1. - UDPListener: this class holds NioDatagram objects etc;
 2. - MainAdapterHandler: this class holds all of my handling logic,
extends IoHandlerAdapter Inside this class, i called KafkaProducer
to submit message

  Things to notes are:

 1. I set a threadpool executor as parameter of NioDatagramAcceptor, the
executor has max value of available processors (acceptor=
newNioDatagramAcceptor(IOExecutor.get());)
 2. I set a threadpool in defaultIoChainBuilder
(chain.addLast("threadPool",
newExecutorFilter(filterChainBuilderExecutorMaxPoolSize));)
 3. Also, i make MainAdapterHandler class threaded by creating a class
extends Thread (ThreadedHandlerAdapter), so if i set another
executor, this line will be executed
(executor.get().execute(newThreadedHandlerAdapter(this, session,
message));)

Or am i missing somethings here?

Thank you


On 17/01/2024 17:00, Emmanuel Lécharny wrote:

Hi,

hard to tell.

Have you profiled your application? Are you CPU bound? If not, you 
should probably increase the default number of threads capable of 
handling the incoming messages (it defaults to Nb cores + 1 )


On 16/01/2024 09:04, Bobby R. Harsono wrote:

Hi all,

Im using Mina 2.2.3 to build a UDP Server,

Currently, i implemented one IoHandlerAdapterclass, lets call this 
MainHandlerAdapter, inside i have plenty of variables of custom 
instance; Several of them are @Autowired on the parent class and when 
creating UDP Server i set them through constructor.


In the end of processing, i use KafkaProducer class to send event to 
kafka topic. All is fine and well, until i found leaked threads, i 
fixed this by


1. supplying custom threadpool executor in acceptor=
    newNioDatagramAcceptor(IOExecutor.get());
2. removing @Async on my send() method in KafkaProducer - this way,
    will not spawn any more threads
3. made MainHandlerAdapter threaded,
4. supply executor in filterchainbuilder -> DefaultIoFilterChainBuilder
    chain = acceptor.getFilterChain();
    chain.addLast("threadPool", new
    ExecutorFilter(Executors.newCachedThreadPool()));

The thread leaked is no more but there is another problem,

My UDP Listener received around 500k TPS, an instance deployed in K8 
can handle around 30-50k TPS but when measuring with core utilizing, 
1 core only handled around 1-4k TPS, this is very low compared to 
another component (not using Mina) that achieved minn 8k TPS


Are there any suggestions how to improve my UDP Server performance ??

Another problem is when i increased deployment pod, no significant 
tps improved






--
---
Bobby R. Harsono
Software Developer
Tricada Intronik - Bandung



--
*Emmanuel Lécharny* P. +33 (0)6 08 33 32 61
elecha...@apache.org

-
To unsubscribe, e-mail: users-unsubscr...@mina.apache.org
For additional commands, e-mail: users-h...@mina.apache.org

Re: Mina UDP Server TPS Performance is Low

[Emmanuel Lécharny]

Hi,

hard to tell.

Have you profiled your application? Are you CPU bound? If not, you 
should probably increase the default number of threads capable of 
handling the incoming messages (it defaults to Nb cores + 1 )


On 16/01/2024 09:04, Bobby R. Harsono wrote:

Hi all,

Im using Mina 2.2.3 to build a UDP Server,

Currently, i implemented one IoHandlerAdapterclass, lets call this 
MainHandlerAdapter, inside i have plenty of variables of custom 
instance; Several of them are @Autowired on the parent class and when 
creating UDP Server i set them through constructor.


In the end of processing, i use KafkaProducer class to send event to 
kafka topic. All is fine and well, until i found leaked threads, i fixed 
this by


1. supplying custom threadpool executor in acceptor=
    newNioDatagramAcceptor(IOExecutor.get());
2. removing @Async on my send() method in KafkaProducer - this way,
    will not spawn any more threads
3. made MainHandlerAdapter threaded,
4. supply executor in filterchainbuilder -> DefaultIoFilterChainBuilder
    chain = acceptor.getFilterChain();
    chain.addLast("threadPool", new
    ExecutorFilter(Executors.newCachedThreadPool()));

The thread leaked is no more but there is another problem,

My UDP Listener received around 500k TPS, an instance deployed in K8 can 
handle around 30-50k TPS but when measuring with core utilizing, 1 core 
only handled around 1-4k TPS, this is very low compared to another 
component (not using Mina) that achieved minn 8k TPS


Are there any suggestions how to improve my UDP Server performance ??

Another problem is when i increased deployment pod, no significant tps 
improved





--
*Emmanuel Lécharny* P. +33 (0)6 08 33 32 61
elecha...@apache.org

-
To unsubscribe, e-mail: users-unsubscr...@mina.apache.org
For additional commands, e-mail: users-h...@mina.apache.org

Re: Deadlock in Apache mina version 2.2.1

[Emmanuel Lécharny]

Hi Kishore,

can you indicate which @Transition you have implemented in your Handler? 
I'm interested in the annotation and method signature, not the code of 
each mothod.



On 03/01/2024 18:16, Kishore Mokkarala wrote:

Hi Emmanuel,
Hope you recovered from Covid.
May I know who else can help in this regard?

--
M.V.S.Kishore
91-9886412814


On Sat, 30 Dec 2023 at 03:10, Emmanuel Lécharny <mailto:elecha...@gmail.com>> wrote:


Sorry, stuck in bed with covid atm :/

On 29/12/2023 09:08, Kishore Mokkarala wrote:
 > Hi Emmanuel,
 > Any help would be greatly appreciated.
 > --
 > M.V.S.Kishore
 > 91-9886412814
 >
 >
 > On Thu, 28 Dec 2023 at 13:34, Kishore Mokkarala
mailto:kishore@gmail.com>
 > <mailto:kishore@gmail.com <mailto:kishore@gmail.com>>> wrote:
 >
 >
 >     Thanks Emmanuel,I appreciate your quick response. I have one
quick
 >     question as you said  "*finish_handshake method will
prob-pagate the
 >     Session_secured event to the IoHandler"*  how to incorporate this
 >     code in my state machine code ?
 >     Currently we are on mina 2.2.1 code. Also i am sharing some sudo
 >     code too.
 >
 >     public class G10MinaClient {
 >
 >          private final G10CaptureProcessor captureProcessor;
 >
 >          public G10MinaClient(final G10CaptureProcessor
captureProcessor) {
 >              this.captureProcessor = captureProcessor;
 >          }
 >
 >          /**
 >           * This method is called when a new session is created.
 >           *
 >           * @param context Context for this state machine session.
 >           * @param session The current IO session.
 >           */
 >          @IoHandlerTransition(on = SESSION_CREATED, in = CONNECTED)
 >          public void create(final G10StateContext context, final
 >     IoSession session) {
 >              captureProcessor.sessionCreated(context, session);
 >          }
 >
 >
 >          @IoHandlerTransition(on = SESSION_CLOSED, in = OPENED)
 >          public void sessionClose(final G10StateContext context,
final
 >     IoSession session) {
 >              captureProcessor.sessionClosed(context, session, false);
 >          }
 >
 >          @IoHandlerTransition(on = SESSION_OPENED, in = CONNECTED)
 >          public void connect(final G10StateContext context, final
 >     IoSession session) {
 >     //This will write data on to SSL socket
 >     //Here how to check hand shake is over or not ?
 >              captureProcessor.verifyAndSendStartMsgs(context,
session);
 >          }
 >     }
 >
 >     *State machine,IO handler and Filter Chain 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);
 >
 >
 >     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;

Re: Deadlock in Apache mina version 2.2.1

[Emmanuel Lécharny]

Sorry, stuck in bed with covid atm :/

On 29/12/2023 09:08, Kishore Mokkarala wrote:

Hi Emmanuel,
Any help would be greatly appreciated.
--
M.V.S.Kishore
91-9886412814


On Thu, 28 Dec 2023 at 13:34, Kishore Mokkarala <mailto:kishore@gmail.com>> wrote:



Thanks Emmanuel,I appreciate your quick response. I have one quick
question as you said  "*finish_handshake method will prob-pagate the
Session_secured event to the IoHandler"*  how to incorporate this
code in my state machine code ?
Currently we are on mina 2.2.1 code. Also i am sharing some sudo
code too.

public class G10MinaClient {

     private final G10CaptureProcessor captureProcessor;

     public G10MinaClient(final G10CaptureProcessor captureProcessor) {
         this.captureProcessor = captureProcessor;
     }

     /**
      * This method is called when a new session is created.
      *
      * @param context Context for this state machine session.
      * @param session The current IO session.
      */
     @IoHandlerTransition(on = SESSION_CREATED, in = CONNECTED)
     public void create(final G10StateContext context, final
IoSession session) {
         captureProcessor.sessionCreated(context, session);
     }


     @IoHandlerTransition(on = SESSION_CLOSED, in = OPENED)
     public void sessionClose(final G10StateContext context, final
IoSession session) {
         captureProcessor.sessionClosed(context, session, false);
     }

     @IoHandlerTransition(on = SESSION_OPENED, in = CONNECTED)
     public void connect(final G10StateContext context, final
IoSession session) {
//This will write data on to SSL socket
//Here how to check hand shake is over or not ?
         captureProcessor.verifyAndSendStartMsgs(context, session);
     }
}

*State machine,IO handler and Filter Chain 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);


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));
}
connector.setHandler(ioHandler);*
*
*
*








    ------
M.V.S.Kishore


On Thu, 28 Dec 2023 at 04:29, Emmanuel Lécharny mailto:elecha...@gmail.com>> wrote:

Hi,

what I can see from the 2 blocked threads is that one his
holding a lock
on the SM context, then tries to write something over a TLS
connection,
while the other receives something through the TLS connection,
and tries
to process a SM event.

There is a clear inter-blockage, with thread 1 doing:
- hold lock on the SSLHandlerG0 instance in the finish_handshake
function (which is synchronized)
- get a lock on the SM context

and thread 2 doing:
- hold a lock on the SM contect
- and tries to get a lock on the SSLHandlerG0 instance to write
something that is generated in the verifyAndSendStartMsgs function.

The finish_handshake method will prob-pagate the Session_secured
event
to the IoHandler, and I think it's a good idea to handle it before
trying t

Re: Deadlock in Apache mina version 2.2.1

[Emmanuel Lécharny]

Hi,

what I can see from the 2 blocked threads is that one his holding a lock 
on the SM context, then tries to write something over a TLS connection, 
while the other receives something through the TLS connection, and tries 
to process a SM event.


There is a clear inter-blockage, with thread 1 doing:
- hold lock on the SSLHandlerG0 instance in the finish_handshake 
function (which is synchronized)

- get a lock on the SM context

and thread 2 doing:
- hold a lock on the SM contect
- and tries to get a lock on the SSLHandlerG0 instance to write 
something that is generated in the verifyAndSendStartMsgs function.


The finish_handshake method will prob-pagate the Session_secured event 
to the IoHandler, and I think it's a good idea to handle it before 
trying to write anything. That means you need to avoid writing anything 
until the session_secured event has been handled.


I wonder if the verifyAndSendStartMsgs should not be sent in 
session-secured event rather than in the session-opened...



On 27/12/2023 17:30, Kishore Mokkarala wrote:

Hi Emmanuel,

You can use the attached thread dump to analyze.hope it will load.This 
is generated using jstack.

--
M.V.S.Kishore
Lead Dev Engineer
NetScout S/w Pvt. Ltd.
91-9886412814


On Wed, 27 Dec 2023 at 14:47, Kishore Mokkarala <mailto:kishore@gmail.com>> wrote:


Here is the thread dump.

Regards,
--
M.V.S.Kishore
91-9886412814


On Wed, 27 Dec 2023 at 10:59, Kishore Mokkarala
mailto:kishore@gmail.com>> wrote:

We cannot share the source code,i have tried with latest Mina
version 2.2.3 also,this is also not working.Dead lock is
happening.Our Organization won't allow to share the source
code.I am sure there is an issue with the state machine and
Apache mina SSL used together.Please let me know how to proceed
on this further ? i am open to zoom or webex call .

Thanks & Regards,
M.V.S.Kishore
91-9886412814


On Sun, 24 Dec 2023 at 08:06, Emmanuel Lécharny
mailto:elecha...@gmail.com>> wrote:

Can you provide the code you use that is related to the
StateMachine usage?

On 24/12/2023 03:22, Emmanuel Lécharny wrote:
 > Hi,
 >
 > the problem is most certainly in the StateMachine part. I
have to see
 > what it does.
 >
 > On 22/12/2023 17:13, Kishore Mokkarala wrote:
 >> *Hi Emmanuel,*
 >> *
 >> *
 >> *Deadlock is happening in the 3rd party jars,not within
the code,which
 >> is out of the scope of the business logic. When large
data is being
 >> transferred between two entities with parallel TCP ip
connections
 >> **over SSL connection.** This is happening *
 >> *Could you please provide a work around this problem,we
are kind of
 >> stuck now in the production.*
 >> *Currently we are using mina version 2.2.1.*
 >> *
 >> *
 >> *StateMachine.java:138*
 >>
 >> *public*  *void*  handle(Event
 >>

<https://nightlies.apache.org/mina/mina/2.0.24/xref/org/apache/mina/statemachine/event/Event.html#Event
 
<https://nightlies.apache.org/mina/mina/2.0.24/xref/org/apache/mina/statemachine/event/Event.html#Event>>
  event) {
 >> 136
 >>

<https://nightlies.apache.org/mina/mina/2.0.24/xref/org/apache/mina/statemachine/StateMachine.html#L136
 
<https://nightlies.apache.org/mina/mina/2.0.24/xref/org/apache/mina/statemachine/StateMachine.html#L136>>
  StateContext  
<https://nightlies.apache.org/mina/mina/2.0.24/xref/org/apache/mina/statemachine/context/StateContext.html#StateContext
 
<https://nightlies.apache.org/mina/mina/2.0.24/xref/org/apache/mina/statemachine/context/StateContext.html#StateContext>>
  context = event.getContext();
 >> 137
 >>

<https://nightlies.apache.org/mina/mina/2.0.24/xref/org/apache/mina/statemachine/StateMachine.html#L137
 
<https://nightlies.apache.org/mina/mina/2.0.24/xref/org/apache/mina/statemachine/StateMachine.html#L137>>
 138  
<https://nightlies.apache.org/mina/mina/2.0.24/xref/org/apache/mina/statemachine/StateMachine.html#L138
 
<https://nightlies.apache.org/mina/mina/2.0.24/xref/org/apache/mina/statemachine/StateMachine.html#L138>>
  *synchronized (context) {*
 >> 139
 >>

<https://nightlies.apache.org/mina/mi

Re: Deadlock in Apache mina version 2.2.1

[Emmanuel Lécharny]

Can you provide the code you use that is related to the StateMachine usage?

On 24/12/2023 03:22, Emmanuel Lécharny wrote:

Hi,

the problem is most certainly in the StateMachine part. I have to see 
what it does.


On 22/12/2023 17:13, Kishore Mokkarala wrote:

*Hi Emmanuel,*
*
*
*Deadlock is happening in the 3rd party jars,not within the code,which 
is out of the scope of the business logic. When large data is being 
transferred between two entities with parallel TCP ip connections 
**over SSL connection.** This is happening *
*Could you please provide a work around this problem,we are kind of 
stuck now in the production.*

*Currently we are using mina version 2.2.1.*
*
*
*StateMachine.java:138*

*public*  *void*  handle(Event  
<https://nightlies.apache.org/mina/mina/2.0.24/xref/org/apache/mina/statemachine/event/Event.html#Event>  event) {
136  
<https://nightlies.apache.org/mina/mina/2.0.24/xref/org/apache/mina/statemachine/StateMachine.html#L136>  StateContext  <https://nightlies.apache.org/mina/mina/2.0.24/xref/org/apache/mina/statemachine/context/StateContext.html#StateContext>  context = event.getContext();
137  
<https://nightlies.apache.org/mina/mina/2.0.24/xref/org/apache/mina/statemachine/StateMachine.html#L137> 138  <https://nightlies.apache.org/mina/mina/2.0.24/xref/org/apache/mina/statemachine/StateMachine.html#L138>  *synchronized (context) {*
139  
<https://nightlies.apache.org/mina/mina/2.0.24/xref/org/apache/mina/statemachine/StateMachine.html#L139>  LinkedList eventQueue = eventQueueThreadLocal.get();
140  
<https://nightlies.apache.org/mina/mina/2.0.24/xref/org/apache/mina/statemachine/StateMachine.html#L140>  eventQueue.addLast(event);
141  
<https://nightlies.apache.org/mina/mina/2.0.24/xref/org/apache/mina/statemachine/StateMachine.html#L141> 142  <https://nightlies.apache.org/mina/mina/2.0.24/xref/org/apache/mina/statemachine/StateMachine.html#L142>  *if*  (processingThreadLocal.get()) {
143  
<https://nightlies.apache.org/mina/mina/2.0.24/xref/org/apache/mina/statemachine/StateMachine.html#L143>  //*/
144  
<https://nightlies.apache.org/mina/mina/2.0.24/xref/org/apache/mina/statemachine/StateMachine.html#L144>  /* This thread is already processing an event. Queue this /
145  
<https://nightlies.apache.org/mina/mina/2.0.24/xref/org/apache/mina/statemachine/StateMachine.html#L145>  /* event./
146  
<https://nightlies.apache.org/mina/mina/2.0.24/xref/org/apache/mina/statemachine/StateMachine.html#L146>  /*//
147  
<https://nightlies.apache.org/mina/mina/2.0.24/xref/org/apache/mina/statemachine/StateMachine.html#L147>  *if*  (LOGGER.isDebugEnabled()) {
148  
<https://nightlies.apache.org/mina/mina/2.0.24/xref/org/apache/mina/statemachine/StateMachine.html#L148>  LOGGER.debug("State machine called recursively. Queuing event k{} for later processing.", event);
149  
<https://nightlies.apache.org/mina/mina/2.0.24/xref/org/apache/mina/statemachine/StateMachine.html#L149>  }
150  
<https://nightlies.apache.org/mina/mina/2.0.24/xref/org/apache/mina/statemachine/StateMachine.html#L150>  }*else*  {
151  
<https://nightlies.apache.org/mina/mina/2.0.24/xref/org/apache/mina/statemachine/StateMachine.html#L151>  processingThreadLocal.set(*true*);
152  
<https://nightlies.apache.org/mina/mina/2.0.24/xref/org/apache/mina/statemachine/StateMachine.html#L152> 153  <https://nightlies.apache.org/mina/mina/2.0.24/xref/org/apache/mina/statemachine/StateMachine.html#L153>  *try*  {
154  
<https://nightlies.apache.org/mina/mina/2.0.24/xref/org/apache/mina/statemachine/StateMachine.html#L154>  *if*  (context.getCurrentState() ==*null*) {
155  
<https://nightlies.apache.org/mina/mina/2.0.24/xref/org/apache/mina/statemachine/StateMachine.html#L155>  context.setCurrentState(startState);
156  
<https://nightlies.apache.org/mina/mina/2.0.24/xref/org/apache/mina/statemachine/StateMachine.html#L156>  }
157  
<https://nightlies.apache.org/mina/mina/2.0.24/xref/org/apache/mina/statemachine/StateMachine.html#L157> 158  <https://nightlies.apache.org/mina/mina/2.0.24/xref/org/apache/mina/statemachine/StateMachine.html#L158>  processEvents(eventQueue);
159  
<https://nightlies.apache.org/mina/mina/2.0.24/xref/org/apache/mina/statemachine/StateMachine.html#L159>  }*finally*  {
160  
<https://nightlies.apache.org/mina/mina/2.0.24/xref/org/apache/mina/statemachine/StateMachine.html#L160>  processingThreadLocal.set(false);
161  
<https://nightlies.apache.org/mina/mina/2.0.24/xref/org/apache/mina/statemachine/StateMachine.html#L161>  }
162  
<https:

Re: Deadlock in Apache mina version 2.2.1

[Emmanuel Lécharny]

ef/org/apache/mina/statemachine/StateMachine.html#L162>
  }
163  
<https://nightlies.apache.org/mina/mina/2.0.24/xref/org/apache/mina/statemachine/StateMachine.html#L163>
  }
164  
<https://nightlies.apache.org/mina/mina/2.0.24/xref/org/apache/mina/statemachine/StateMachine.html#L164>
  }

*
*
* at org.apache.mina.filter.ssl.SSLHandlerG0.write(SSLHandlerG0.java:312)*
*
*
*SSLHandlerG0.java:*
synchronized public void write(NextFilter next, WriteRequest request) 
throws SSLException, WriteRejectedException {

         if (LOGGER.isDebugEnabled()) {
             LOGGER.debug("{} write() - source {}", toString(), request);
         }*
*

..
}



--
M.V.S.Kishore
Lead Dev Engineer
NetScout S/w Pvt. Ltd.
91-9886412814


On Fri, 22 Dec 2023 at 20:10, Kishore Mokkarala <mailto:kishore@gmail.com>> wrote:


 1.
Is the below issue fixed ?
 1. DIRMINA-604 <https://issues.apache.org/jira/browse/DIRMINA-604>
Deadlock occurs when implementing two mina StateMachine

--
M.V.S.Kishore
Lead Dev Engineer
NetScout S/w Pvt. Ltd.
91-9886412814


On Fri, 22 Dec 2023 at 13:04, Emmanuel Lécharny mailto:elecha...@gmail.com>> wrote:

Hi,

you have a deadlock on 0x7f5c9f001408, which is in
com.netscout.nsaapp.geo.minaG10Proto.server.G10StateContext.



On 22/12/2023 08:10, Kishore Mokkarala wrote:
 > Hi Emmanuel,
 >
 > We are facing deadlock in production with mina 2.2.1
version,earlier it
 > was on 2.0.21, After upgrade only we are seeing this
issue,kindly please
 > provide an update any similar kind issue is fixed in 2.2.3 or
not ?
 >
 >
 > Thread pool-123-thread-3 is in deadlock with thread
NioProcessor-37
 >
 >
 >     pool-123-thread-3
 >
 > PRIORITY : 5
 >
 > THREAD ID : 0X7F5978002870
 >
 > NATIVE ID : 0X7C15
 >
 > NATIVE ID (DECIMAL) : 31765
 >
 > STATE : BLOCKED
 >
 >
 > stackTrace:
 > java.lang.Thread.State: BLOCKED (on object monitor)
 > at
org.apache.mina.filter.ssl.SSLHandlerG0.write(SSLHandlerG0.java:312)
 > - waiting to lock <0x7f5c9f001168> (a
 > org.apache.mina.filter.ssl.SSLHandlerG0)
 > at
org.apache.mina.filter.ssl.SslFilter.filterWrite(SslFilter.java:380)
 > at
 >

org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:753)
 > at
 >

org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1500(DefaultIoFilterChain.java:49)
 > at
 >

org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.filterWrite(DefaultIoFilterChain.java:1146)
 > at
 >

org.apache.mina.core.filterchain.IoFilterAdapter.filterWrite(IoFilterAdapter.java:138)
 > at
 >

org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:753)
 > at
 >

org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1500(DefaultIoFilterChain.java:49)
 > at
 >

org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.filterWrite(DefaultIoFilterChain.java:1146)
 > at
 >

org.apache.mina.filter.codec.ProtocolCodecFilter.filterWrite(ProtocolCodecFilter.java:332)
 > at
 >

org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:753)
 > at
 >

org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1500(DefaultIoFilterChain.java:49)
 > at
 >

org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.filterWrite(DefaultIoFilterChain.java:1146)
 > at
 >

org.apache.mina.filter.executor.ExecutorFilter.filterWrite(ExecutorFilter.java:595)
 > at
 >

org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:753)
 > at
 >

org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1500(DefaultIoFilterChain.java:49)
 > at
 >

org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.filterWrite(DefaultIoFilterChain.java:1146)
 > at
 >

com.netscout.nsaapp.geo.minaG10Proto.server.G10GPBMessageIoFilter.filterWrite

Re: Fwd: Deadlock in Apache mina version 2.2.1

[Emmanuel Lécharny]

The thread dump is not readable from a HD analysys tool (bad HPROF format)

On 22/12/2023 17:21, Kishore Mokkarala wrote:

Attached thread dump too.
--
M.V.S.Kishore
Lead Dev Engineer
NetScout S/w Pvt. Ltd.
91-9886412814


-- Forwarded message -
From: *Kishore Mokkarala* <mailto:kishore@gmail.com>>

Date: Fri, 22 Dec 2023 at 21:43
Subject: Re: Deadlock in Apache mina version 2.2.1
To: Emmanuel Lécharny <mailto:elecha...@gmail.com>>, <mailto:j...@apache.org>>, <mailto:users@mina.apache.org>>



*Hi Emmanuel,*
*
*
*Deadlock is happening in the 3rd party jars,not within the code,which 
is out of the scope of the business logic. When large data is being 
transferred between two entities with parallel TCP ip connections **over 
SSL connection.** This is happening *
*Could you please provide a work around this problem,we are kind of 
stuck now in the production.*

*Currently we are using mina version 2.2.1.*
*
*
*StateMachine.java:138*

*public*  *void*  handle(Event  
<https://nightlies.apache.org/mina/mina/2.0.24/xref/org/apache/mina/statemachine/event/Event.html#Event>
  event) {
136  
<https://nightlies.apache.org/mina/mina/2.0.24/xref/org/apache/mina/statemachine/StateMachine.html#L136>
  StateContext  
<https://nightlies.apache.org/mina/mina/2.0.24/xref/org/apache/mina/statemachine/context/StateContext.html#StateContext>
  context = event.getContext();
137  <https://nightlies.apache.org/mina/mina/2.0.24/xref/org/apache/mina/statemachine/StateMachine.html#L137>  
138  <https://nightlies.apache.org/mina/mina/2.0.24/xref/org/apache/mina/statemachine/StateMachine.html#L138>  *synchronized (context) {*

139  
<https://nightlies.apache.org/mina/mina/2.0.24/xref/org/apache/mina/statemachine/StateMachine.html#L139>
  LinkedList eventQueue = eventQueueThreadLocal.get();
140  
<https://nightlies.apache.org/mina/mina/2.0.24/xref/org/apache/mina/statemachine/StateMachine.html#L140>
  eventQueue.addLast(event);
141  <https://nightlies.apache.org/mina/mina/2.0.24/xref/org/apache/mina/statemachine/StateMachine.html#L141>  
142  <https://nightlies.apache.org/mina/mina/2.0.24/xref/org/apache/mina/statemachine/StateMachine.html#L142>  *if*  (processingThreadLocal.get()) {

143  
<https://nightlies.apache.org/mina/mina/2.0.24/xref/org/apache/mina/statemachine/StateMachine.html#L143>
  //*/
144  
<https://nightlies.apache.org/mina/mina/2.0.24/xref/org/apache/mina/statemachine/StateMachine.html#L144>
  /* This thread is already processing an event. Queue this /
145  
<https://nightlies.apache.org/mina/mina/2.0.24/xref/org/apache/mina/statemachine/StateMachine.html#L145>
  /* event./
146  
<https://nightlies.apache.org/mina/mina/2.0.24/xref/org/apache/mina/statemachine/StateMachine.html#L146>
  /*//
147  
<https://nightlies.apache.org/mina/mina/2.0.24/xref/org/apache/mina/statemachine/StateMachine.html#L147>
  *if*  (LOGGER.isDebugEnabled()) {
148  
<https://nightlies.apache.org/mina/mina/2.0.24/xref/org/apache/mina/statemachine/StateMachine.html#L148>
  LOGGER.debug("State machine called recursively. Queuing event k{} 
for later processing.", event);
149  
<https://nightlies.apache.org/mina/mina/2.0.24/xref/org/apache/mina/statemachine/StateMachine.html#L149>
  }
150  
<https://nightlies.apache.org/mina/mina/2.0.24/xref/org/apache/mina/statemachine/StateMachine.html#L150>
  }*else*  {
151  
<https://nightlies.apache.org/mina/mina/2.0.24/xref/org/apache/mina/statemachine/StateMachine.html#L151>
  processingThreadLocal.set(*true*);
152  <https://nightlies.apache.org/mina/mina/2.0.24/xref/org/apache/mina/statemachine/StateMachine.html#L152>  
153  <https://nightlies.apache.org/mina/mina/2.0.24/xref/org/apache/mina/statemachine/StateMachine.html#L153>  *try*  {

154  
<https://nightlies.apache.org/mina/mina/2.0.24/xref/org/apache/mina/statemachine/StateMachine.html#L154>
  *if*  (context.getCurrentState() ==*null*) {
155  
<https://nightlies.apache.org/mina/mina/2.0.24/xref/org/apache/mina/statemachine/StateMachine.html#L155>
  context.setCurrentState(startState);
156  
<https://nightlies.apache.org/mina/mina/2.0.24/xref/org/apache/mina/statemachine/StateMachine.html#L156>
  }
157  <https://nightlies.apache.org/mina/mina/2.0.24/xref/org/apache/mina/statemachine/StateMachine.html#L157>  
158  <https://nightlies.apache.org/mina/mina/2.0.24/xref/org/apache/mina/statemachine/StateMachine.html#L158>  processEvents(eventQueue);

159  
<https://nightlies.apache.org/mina/mina/2.0.24/

Re: install Apache Mina SSHD 2.9.2 on windows 11

[Emmanuel Lécharny]

Hi,

there is no install doc. SSHd is a library, not an installable package.

On 26/10/2023 09:03, chandan kumar wrote:

Hi Team,

Could you please share the steps to install Apache Mina SSHD 2.9.2 on
windows 11.

Thanks
Chandan



--
*Emmanuel Lécharny* P. +33 (0)6 08 33 32 61
elecha...@apache.org

-
To unsubscribe, e-mail: users-unsubscr...@mina.apache.org
For additional commands, e-mail: users-h...@mina.apache.org

Re: Azure servers flagged with vulnerability regarding Apache MINA

[Emmanuel Lécharny]

Hi Christopher,

First, sorry for the late answer

Apache MINA SSHD is a library providing SSH support in Java. It's more 
likely that one of the Java applications running on your server is using 
a version of this library that is subject to this CVE. FTR, an Apache 
MINA SSHd release (2.9.2) has been issued that fix this specific CVE.


I suggest you check what Java application is running on your servers, 
and that you check either with your internal developers or with your 
software vendors to get to know which software is embedding Apache MINA 
SSHd.


It may be complex because it may be a third party dependency (ie a lib 
that is used by a lib (and you can iterate) that is used by an 
application...)


I hope you'll find the root cause if this issue...


On 23/06/2023 18:53, MCCOY, CHRISTOPHER wrote:

Hello. Recently inside my organization some of my group's servers have been 
flagged with a vulnerability regarding Apache MINA. Here is a clip from the 
email that was brought to our attention:

CVE-2022-45047

Summary: Class org.apache.sshd.server.keyprovider.SimpleGeneratorHostKeyProvider 
in Apache MINA SSHD <= 2.9.1 uses Java deserialization to load a serialized 
java.security.PrivateKey. The class is one of several implementations that an 
implementor using Apache MINA SSHD can choose for loading the host keys of an SSH 
server.

CVSS Score: 0

CVSS V3 Score: 9.8

CWE ID: CWE-502

Vulnerable Packages: cpe:2.3:a:apache:sshd:*:*:*:*:*:*:*:*

Published: November 16, 2022

Last Modified: November 18, 2022

References:

https://www.mail-archive.com/dev@mina.apache.org/msg39312.html
I am unaware of specifically what Apache MINA is, or how it relates to any 
project or service that currently runs on our servers. I would like to identify 
where this service is on our servers so that it can either be removed (if not 
used) or updated so that we are no longer flagged for this vulnerability.

Could someone please explain to me how I can locate this application or service 
on our MS Azure server, and possibly identify if it is something that we 
actually need, and how it can be removed or updated? Thanks!

--
Christopher McCoy




--
*Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
T. +33 (0)4 89 97 36 50
P. +33 (0)6 08 33 32 61
emmanuel.lecha...@busit.com https://www.busit.com/

-
To unsubscribe, e-mail: users-unsubscr...@mina.apache.org
For additional commands, e-mail: users-h...@mina.apache.org

Apache MINA Mastodon account is on!

[Emmanuel Lécharny]

Hi!

we just have created a Mastodon account to inform the world abouut the 
Apache MINA project evolution.


Feel free to follow @apachem...@fosstodon.org  !
--
*Emmanuel Lécharny*

-
To unsubscribe, e-mail: users-unsubscr...@mina.apache.org
For additional commands, e-mail: users-h...@mina.apache.org

Re: Apache mina 2.2.1 thread blocking issue.

[Emmanuel Lécharny]

On 26/04/2023 09:06, Kishore Mokkarala wrote:

Hi All,
I don't know how to create a JIRA, Please share me the link if any. 


First go there, selecting MINA project:

https://selfserve.apache.org/jira-account.html

then I'll validate your account creation. We can then have a technical 
discussion tehre, with attached thread dump.


I

can't share the working code with you.


At some point, as MINA is just a framework that is used by ten of 
thousands of project, there are two possibilities:

- you have been hit by a new bug
- or you are somehow misuing MINA

TRhe general rule of thumb is to assume (1) to be very unlikely, so (2) 
is probably where lies your problem. If we can't access your code to 
understand what's wrong, then it will be *very* hartd for us to point 
you in any solution.


I can share the thread dump.PFA

Thread dump.



Our application gets data from Sniffers. For communicating

with sniffers we use async communication, we use apache mina here.
This is happening only with one type of sniffer. 


Ok, then we need to know what's the difference between this sniffer and 
the others. This might be relevent to analyse what's wrong.



It is working fine on

other sniffers.
--
M.V.S. Kishore
91-9886412814


On Wed, 26 Apr 2023 at 03:42, Emmanuel Lécharny <mailto:elecha...@gmail.com>> wrote:


Hi Kishire,

the fact it's working with 2.0.21 is pure luck, IMHO.

Two things:
- we need a full thread dump in order to see if there is a deadlock
somewhere
- The info you are providing are super limited. Without the whole code,
and a way to reproduce the problem, there is no way we can understand
what your code is doing (beside the intention you explain, ie getting a
list of IPs and testing them all).

So, as Jonathan already said: open a JIRA (you'll have to request an
account creation that we will validate), and provide a working exemple
we can run.

Thanks!

On 25/04/2023 12:35, Kishore Mokkarala wrote:
 > Hi,
 > I have migrated from 2.0.21 to 2.023 for solving CVE, i have seen
thread
 > blocking issue, So used latest mina verstion 2.2.1 but still
threads were
 > blocked here is the sample code.Thread hungs at
awaitUninterruptibly.  Once
 > this issue comes  in sub sequest launches nothing will work all
threads
 > will be blocked forever,i have to restart the process to make it
work. For
 > single thread working fine,if i start 50-100 threads this thread
blocking
 > issue will surface.
 >
 > *Here is the sample thread dump:*
 > "pool-118-thread-6" #508 prio=5 os_prio=0 cpu=345.84ms
elapsed=*1929.48s*
 > tid=0x7ec6fc001800 nid=0x4b5d4 in Object.wait() 
[0x7ec7792d4000]

 >     java.lang.Thread.State: TIMED_WAITING (on object monitor)
 >          at java.lang.Object.wait(java.base@11.0.14.1/Native
<http://java.base@11.0.14.1/Native> Method)
 >          - waiting on 
 >          at
 >
org.apache.mina.core.future.DefaultIoFuture.await0(DefaultIoFuture.java:218)
 >          - waiting to re-lock in wait() <0x7ed90d1b2c40> (a
 >
org.apache.mina.core.polling.AbstractPollingIoConnector$ConnectionRequest)
 >          at
 >

org.apache.mina.core.future.DefaultIoFuture.awaitUninterruptibly(DefaultIoFuture.java:148)
 >          at
 >

org.apache.mina.core.future.DefaultConnectFuture.awaitUninterruptibly(DefaultConnectFuture.java:149)
 >          at
 >

com.netscout.nsaapp.geo.g10Plugin.g10.service.G10CaptureService.startRecordCapture(G10CaptureService.java:622)
 >          at
 >

com.netscout.nsaapp.geo.g10Plugin.geoblade.service.GeoBladeCaptureService.startRecordCapture(GeoBladeCaptureService.java:67)
 >          at
 >

com.netscout.nsaapp.geo.g10Plugin.g10.processor.G10PluginCaptureProcessor.processGatewaySrQueryResponseSuccess(G10PluginCaptureProcessor.java:2156)
 >          at
 >

com.netscout.nsaapp.geo.minaG10Proto.server.G10MinaClient.doHandleGatewaySrQueryResponse(G10MinaClient.java:283)
 >          at
 >

com.netscout.nsaapp.geo.minaG10Proto.server.G10MinaClient.handleGatewaySrQueryResponse(G10MinaClient.java:268)
 >          at
jdk.internal.reflect.GeneratedMethodAccessor201.invoke(Unknown
 > Source)
 >          at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(
 > java.base@11.0.14.1/DelegatingMethodAccessorImpl.java:43
<http://java.base@11.0.14.1/DelegatingMethodAccessorImpl.java:43>)
 >          at java.lang.reflect.Method.invoke(
 > java.base@11.0.14.1/Method.java:566
<http://java.base@11.0.14.1/Method.java:566>)
 >          at
 >

org.apache.mina.statemachine

Re: Apache mina 2.2.1 thread blocking issue.

[Emmanuel Lécharny]

in.IoFilterEvent.fire(IoFilterEvent.java:106)
 at org.apache.mina.core.session.IoEvent.run(IoEvent.java:89)
 at
org.apache.mina.filter.executor.OrderedThreadPoolExecutor$Worker.runTask(OrderedThreadPoolExecutor.java:763)

*This code is working fine with 2.0.21.*

*Here is the code snippet.*

  private static final ExecutorFilter executorFilter = *new
ExecutorFilter(16,32);*

 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());
 return stateContext;
 }
 })).create(IoHandler.class, stateMachine);

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);
 connector.setHandler(ioHandler);
  connectionLock.lock(); // connectionLock is private variable.
try{
ConnectFuture primaryConnectFuture = connector.connect(primaryAddress,
initializer);
primaryConnectFuture.awaitUninterruptibly(); // no timeout specified.

if (!primaryConnectFuture.isConnected())
{

 if (handleIOException(searchExpression,
captureHandler)) {
 return;
 }
 LOG.info("{} Apache mina connection setup time out
happend.",
 handleConnectionFailed(primaryAddress, captureHandler,
"Primary IP connection timeout");
 return;
}
}
finally
{
connectionLock.unLock();
}

--
M.V.S.Kishore
91-9886412814



--
*Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
T. +33 (0)4 89 97 36 50
P. +33 (0)6 08 33 32 61
emmanuel.lecha...@busit.com https://www.busit.com/

-
To unsubscribe, e-mail: users-unsubscr...@mina.apache.org
For additional commands, e-mail: users-h...@mina.apache.org

Re: Fwd: migration from apache mina 2.0.21 to 2.0.23 issue

[Emmanuel Lécharny]

st name for creating SSLEngine?

*Here is the new implementation changed as per new Mina 2.2.10 API:*
try{
sslContext = javax.net.ssl.SSLContext.getDefault();
SNIServerName sniHostName = new SNIHostName("*eid.17.cid.0*");
List sniHostNames = new ArrayList<>();
sniHostNames.add(sniHostName);
SSLParameters sslParams = sslContext.getDefaultSSLParameters();
sslParams.setServerNames(sniHostNames);
sslFilter = new SslFilter(sslContext);
//sslFilter.setUseClientMode(true); //This is not required in 2.2.1 hence
commented.
connector.getFilterChain().addFirst("sslFilter", sslFilter);
} catch (Exception e) {
e.printStackTrace();
LOG.error("Exception during creating SSL context..." +
XError.getStackTrace(e));
}
connector.setHandler(ioHandler);

Here is the Apache mina 2.0.21 with PEER_ADDRESS in SslHandler.java code

:


  /* no qualifier */void init() throws SSLException {
 if (sslEngine != null) {
 // We already have a SSL engine created, no need to create a
new one
 return;
 }
 if (LOGGER.isDebugEnabled()) {
 LOGGER.debug("{} Initializing the SSL Handler",
sslFilter.getSessionInfo(session));
 }
 InetSocketAddress peer = (InetSocketAddress)
session.getAttribute(SslFilter.PEER_ADDRESS);
 // Create the SSL engine here
 if (peer == null) {
 sslEngine = sslFilter.sslContext.createSSLEngine();
 } else {
 sslEngine =
sslFilter.sslContext.createSSLEngine(peer.getHostName(), peer.getPort());
 }
 // Initialize the engine in client mode if necessary
 sslEngine.setUseClientMode(sslFilter.isUseClientMode());


Regards,
--
M.V.S.Kishore
91-9886412814


On Wed, 12 Apr 2023 at 23:08, Emmanuel Lécharny 
wrote:


Hi,

On 12/04/2023 18:00, Kishore Mokkarala wrote:

Thanks  Emmanuel for the quick response.I have few more questions on

the

upgrade.Please do the needful.
If i want to upgrade from Apache mina 2.0.21 to mina 2.2.1 what all

steps

do i need to follow ?


There are two pages that explains the diffence between 2.0 and 2.1, and
2. and 2.2:
* https://mina.apache.org/mina-project/2.1-vs-2.0.html
* https://mina.apache.org/mina-project/2.2-vs-2.1.html

The 2.1 vs 2.0 difference is mainly about the way we detect a secured
session. It's pretty trivial.

The 2.2. vs 2.1 migration is a bit more complicated, *if* you were

using

startTLS.

Otherwise, it's pretty straightforward.

ALso note that teh SSL handler has been completeley reworked in 2.2.


Is it  just a jar file  change in the classpath or do i need to do

any

more

changes ?


It should be just about changing the jar.



Also we are also using https for communication ? in this case what

all

changes are needed ?


Nothing, AFAICT.


I have seen there is a change the way we pass the SNI host name in

2.0.21

vs  2.2.1 ?


Hmmm, not that I remeber. Do you have any pointer?


First of all is it recommended to migrate from  2.0.21 to mina 2.2.1

?


Oh yes! Simply because the SSL rewrite was necessary, also because 2.2
branch is clearly the one we maintain.


will the state machine work without doing any changes ?


It should not have changed.

Hope it helps.



Regards,
------
M.V.S.Kishore


On Mon, 10 Apr 2023 at 18:42, Emmanuel Lécharny 


wrote:



Hi,

Mina 2.0 branch is pretty old (5 years) and we have made significant
changes in the 2.1 and more important the 2.2 branches. You should
seriously consider migrating to 2.2. That  being said:

- 40 seconds to do whatever that was taking a few milliseconds

snounds

like a major regression, aka bug.
- If you weren't using the HTTP part of MINA, migrating to 2.0.23

makes

little sense. The CVE only impacts the HTTP decoder. In other words,

if

it's working, don't break it...
- We don't have enough context to tell you what could go wrong in

your

code. If you provide some piece of code we can run, we can

investigate,

otherwise it's like shouting in the dark... Typically, we have no

clue

about what the gpbMessageFilter does.

On 10/04/2023 13:37, Kishore Mokkarala wrote:

Hi,
There was a security vulnerability in mina 2.0.21,So we were

migrated

from apache mina 2.0.21 to 2.0.23,locally in the dev environment

everything

looks good, but in production we are facing connection timeout

issue

with

the mina version 2.0.23.
For connection set up it was taking 10-20 milliseconds (less than a

second)

with the old version (2.0.21).
With the new version even after 40 seconds connection was timed

out.


We use the same NioSocketConnector  instance for opening 100
parallel connections.

*Question:*
*My query is why it is taking more time more than 40 seconds for

opening

the socket with the new version ?*

We are not using https communication.

*Could you please suggest a work around.*

What's happening in the below code is mina is time out after 40

seconds

and

a

Re: Fwd: migration from apache mina 2.0.21 to 2.0.23 issue

[Emmanuel Lécharny]

Hi,

On 12/04/2023 18:00, Kishore Mokkarala wrote:

Thanks  Emmanuel for the quick response.I have few more questions on the
upgrade.Please do the needful.
If i want to upgrade from Apache mina 2.0.21 to mina 2.2.1 what all steps
do i need to follow ?


There are two pages that explains the diffence between 2.0 and 2.1, and 
2. and 2.2:

* https://mina.apache.org/mina-project/2.1-vs-2.0.html
* https://mina.apache.org/mina-project/2.2-vs-2.1.html

The 2.1 vs 2.0 difference is mainly about the way we detect a secured 
session. It's pretty trivial.


The 2.2. vs 2.1 migration is a bit more complicated, *if* you were using 
startTLS.


Otherwise, it's pretty straightforward.

ALso note that teh SSL handler has been completeley reworked in 2.2.


Is it  just a jar file  change in the classpath or do i need to do any more
changes ?


It should be just about changing the jar.



Also we are also using https for communication ? in this case what all
changes are needed ?


Nothing, AFAICT.


I have seen there is a change the way we pass the SNI host name in 2.0.21
vs  2.2.1 ?


Hmmm, not that I remeber. Do you have any pointer?


First of all is it recommended to migrate from  2.0.21 to mina 2.2.1 ?


Oh yes! Simply because the SSL rewrite was necessary, also because 2.2 
branch is clearly the one we maintain.



will the state machine work without doing any changes ?


It should not have changed.

Hope it helps.



Regards,
--
M.V.S.Kishore


On Mon, 10 Apr 2023 at 18:42, Emmanuel Lécharny  wrote:


Hi,

Mina 2.0 branch is pretty old (5 years) and we have made significant
changes in the 2.1 and more important the 2.2 branches. You should
seriously consider migrating to 2.2. That  being said:

- 40 seconds to do whatever that was taking a few milliseconds snounds
like a major regression, aka bug.
- If you weren't using the HTTP part of MINA, migrating to 2.0.23 makes
little sense. The CVE only impacts the HTTP decoder. In other words, if
it's working, don't break it...
- We don't have enough context to tell you what could go wrong in your
code. If you provide some piece of code we can run, we can investigate,
otherwise it's like shouting in the dark... Typically, we have no clue
about what the gpbMessageFilter does.

On 10/04/2023 13:37, Kishore Mokkarala wrote:

Hi,
There was a security vulnerability in mina 2.0.21,So we were migrated
from apache mina 2.0.21 to 2.0.23,locally in the dev environment

everything

looks good, but in production we are facing connection timeout issue with
the mina version 2.0.23.
For connection set up it was taking 10-20 milliseconds (less than a

second)

with the old version (2.0.21).
With the new version even after 40 seconds connection was timed out.

We use the same NioSocketConnector  instance for opening 100
parallel connections.

*Question:*
*My query is why it is taking more time more than 40 seconds for opening
the socket with the new version ?*

We are not using https communication.

*Could you please suggest a work around.*

What's happening in the below code is mina is time out after 40 seconds

and

also IO session has been created using state machine in separate
threads,both are running in two parallel threads,This issue is not seen
with the mina 2.0.21 version.

*Here is the code snippet.*

   private static final ExecutorFilter executorFilter = new
ExecutorFilter(16,32);

  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());
  return stateContext;
  }
  })).create(IoHandler.class, stateMachine);

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);
  connector.setHandler(ioHandler);
ConnectFuture primaryConnectFuture = connector.connect(primaryAddress,
initializer);
if (!primaryConnectFuture.awaitUninterruptibly(MINA_CLOSE_TIMEOUT))
//MINA_CLOSE_TIMEOUT is 40 seconds
{

  if (

Re: Upgrading from mina-core ( 1.7.1 ) to Mina-core 2.2.1

[Emmanuel Lécharny]

Mina 1.1 is defunct for now 15 years...

On 10/04/2023 15:22, Chandan Singh wrote:

Thanks for the response  , Do we have  any page to refer to migrate  to 1.x
to  2.x  ?

Regards
Chandan

On Sun, Apr 9, 2023 at 7:26 PM Jonathan Valliere  wrote:


We also likely broke some things between 2.1 and 2.2 (some debate about
whether we should be at 3.0 despite it already exists in a very old branch)

On Sun, Apr 9, 2023 at 9:54 AM Isaac M  wrote:


A lot has changed since the old version and likely refactored to a
different package. See ProxyTcpSessionConfig.java
<
https://github.com/apache/mina/blob/trunk/core/src/main/java/org/apache/mina/transport/tcp/ProxyTcpSessionConfig.java




On Sat, Apr 8, 2023 at 11:48 AM Chandan Singh <
mailbox.chandansi...@gmail.com> wrote:


Hi All ,

I am looking to upgrade  from mina-core  1.7.1  version to  2.2.1  but
getting compilation issue stating packages not found as shown below ,
Please let me know how to resolve these

*package org.apache.mina.common does not exist*



* cannot find symbol[ERROR]   symbol:   class SocketSessionConfig[ERROR]
location: package org.apache.mina.transport.socket.nio*


*Regards*
*Chandan*









--
*Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
T. +33 (0)4 89 97 36 50
P. +33 (0)6 08 33 32 61
emmanuel.lecha...@busit.com https://www.busit.com/

-
To unsubscribe, e-mail: users-unsubscr...@mina.apache.org
For additional commands, e-mail: users-h...@mina.apache.org

Re: migration from apache mina 2.0.21 to 2.0.23 issue

[Emmanuel Lécharny]

Hi,

Mina 2.0 branch is pretty old (5 years) and we have made significant 
changes in the 2.1 and more important the 2.2 branches. You should 
seriously consider migrating to 2.2. That  being said:


- 40 seconds to do whatever that was taking a few milliseconds snounds 
like a major regression, aka bug.
- If you weren't using the HTTP part of MINA, migrating to 2.0.23 makes 
little sense. The CVE only impacts the HTTP decoder. In other words, if 
it's working, don't break it...
- We don't have enough context to tell you what could go wrong in your 
code. If you provide some piece of code we can run, we can investigate, 
otherwise it's like shouting in the dark... Typically, we have no clue 
about what the gpbMessageFilter does.


On 10/04/2023 13:37, Kishore Mokkarala wrote:

Hi,
There was a security vulnerability in mina 2.0.21,So we were migrated
from apache mina 2.0.21 to 2.0.23,locally in the dev environment everything
looks good, but in production we are facing connection timeout issue with
the mina version 2.0.23.
For connection set up it was taking 10-20 milliseconds (less than a second)
with the old version (2.0.21).
With the new version even after 40 seconds connection was timed out.

We use the same NioSocketConnector  instance for opening 100
parallel connections.

*Question:*
*My query is why it is taking more time more than 40 seconds for opening
the socket with the new version ?*

We are not using https communication.

*Could you please suggest a work around.*

What's happening in the below code is mina is time out after 40 seconds and
also IO session has been created using state machine in separate
threads,both are running in two parallel threads,This issue is not seen
with the mina 2.0.21 version.

*Here is the code snippet.*

  private static final ExecutorFilter executorFilter = new
ExecutorFilter(16,32);

 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());
 return stateContext;
 }
 })).create(IoHandler.class, stateMachine);

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);
 connector.setHandler(ioHandler);
ConnectFuture primaryConnectFuture = connector.connect(primaryAddress,
initializer);
if (!primaryConnectFuture.awaitUninterruptibly(MINA_CLOSE_TIMEOUT))
//MINA_CLOSE_TIMEOUT is 40 seconds
{

 if (handleIOException(searchExpression,
captureHandler)) {
 return;
 }
 LOG.info("{} Apache mina connection setup time out
happend.",
 handleConnectionFailed(primaryAddress, captureHandler,
"Primary IP connection timeout");
     return;
}

Regards,
M.V.S.Kishore
91-9886412814



--
*Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
T. +33 (0)4 89 97 36 50
P. +33 (0)6 08 33 32 61
emmanuel.lecha...@busit.com https://www.busit.com/

-
To unsubscribe, e-mail: users-unsubscr...@mina.apache.org
For additional commands, e-mail: users-h...@mina.apache.org

Re: MINA maintaining order of incoming requests

[Emmanuel Lécharny]

Hi,

you should probably use an OrderedThreadPoolExecutor:

https://nightlies.apache.org/mina/mina/2.0.21/apidocs/org/apache/mina/filter/executor/OrderedThreadPoolExecutor.html

On 18/01/2023 10:00, Sebastian Götz wrote:
 From the documentation I interpret this, that the first executor is in 
charge accepting new connection on the ServerSocketChannel and the 
second is in charge of running the Processor of the queued IOSessions. 
Unfortunately this solution does not work. I have setup a stress test 
monitoring the network traffic with WireShark. From there I see, that 
packages arrive at the server in correct order. But nearly immediately 
after start of the test the packages get out of order. I must also 
mention, that the processing time of a single request is significant 
with around 500ms up to several seconds.


--
*Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
T. +33 (0)4 89 97 36 50
P. +33 (0)6 08 33 32 61
emmanuel.lecha...@busit.com https://www.busit.com/

-
To unsubscribe, e-mail: users-unsubscr...@mina.apache.org
For additional commands, e-mail: users-h...@mina.apache.org

Re: New deadlock potential in MINA 2.2's SSLHandler

[Emmanuel Lécharny]

Hi Guus,

indeed, this is what I was looking for.

So this thread (TaskEngine-pool-3) is locking the StreamManager class 
(the synchrinized on streamManager) and the global StreamManager class 
lock done by thread socket_c2s_ssl-thread-2 in the StreamManager.java 
class, function validateClientAcknowledgement


private synchronized boolean validateClientAcknowledgement(long h) {
return h <= ( unacknowledgedServerStanzas.isEmpty() ? 
clientProcessedStanzas.get() : unacknowledgedServerStanzas.getLast().x );

}

The stack trace is:

"socket_c2s_ssl-thread-2" #78 daemon prio=5 waiting on lock
   java.lang.Thread.State: BLOCKED
	- blocked on 
org.jivesoftware.openfire.streammanagement.StreamManager@7e024771 (owned 
by TaskEngine-pool-3 id=40)
	at 
org.jivesoftware.openfire.streammanagement.StreamManager.processClientAcknowledgement(StreamManager.java:493)
	at 
org.jivesoftware.openfire.streammanagement.StreamManager.process(StreamManager.java:185)
	at 
org.jivesoftware.openfire.net.StanzaHandler.process(StanzaHandler.java:223)
	at 
org.jivesoftware.openfire.nio.ConnectionHandler.messageReceived(ConnectionHandler.java:178)
	at 
org.apache.mina.core.filterchain.DefaultIoFilterChain$TailFilter.messageReceived(DefaultIoFilterChain.java:1015)
	at 
org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:650)
	at 
org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1300(DefaultIoFilterChain.java:49)
	at 
org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:1128)
	at 
org.apache.mina.core.filterchain.IoFilterAdapter.messageReceived(IoFilterAdapter.java:122)
	at 
org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:650)
	at 
org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1300(DefaultIoFilterChain.java:49)
	at 
org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:1128)
	at 
org.apache.mina.filter.codec.AbstractProtocolDecoderOutput.flush(AbstractProtocolDecoderOutput.java:64)
	at 
org.apache.mina.filter.codec.ProtocolCodecFilter.messageReceived(ProtocolCodecFilter.java:249)
	at 
org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:650)
	at 
org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1300(DefaultIoFilterChain.java:49)
	at 
org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:1128)
	at 
org.apache.mina.filter.ssl.SSLHandlerG0.receive_loop(SSLHandlerG0.java:236)

at 
org.apache.mina.filter.ssl.SSLHandlerG0.receive(SSLHandlerG0.java:162)
- locked org.apache.mina.filter.ssl.SSLHandlerG0@99f49e2



Sothe deadlock in your code is on the StreamManager class.



On 20/12/2022 14:09, Guus der Kinderen wrote:

Hi Emmanuel,

I'm not sure if I understand what you're saying or asking. My email 
client doesn't do a great job of formatting all that code in the email 
either, which might add to the confusion.


The code that you seem to refer to is here: 
https://github.com/igniterealtime/Openfire/blob/cd28f39c411a0faede6d04454caf865d1695928f/xmppserver/src/main/java/org/jivesoftware/openfire/session/LocalClientSession.java#L923-L932 <https://github.com/igniterealtime/Openfire/blob/cd28f39c411a0faede6d04454caf865d1695928f/xmppserver/src/main/java/org/jivesoftware/openfire/session/LocalClientSession.java#L923-L932>


There is a lock that intends to ensure that the 'streammanager' (which 
keeps statistics on data sent, received and acknowledged) is not used 
while data is being sent over the outbound connection.


Does that make sense and answer your question?

Kind regards,

   Guus

On Mon, Dec 19, 2022 at 4:00 AM Emmanuel Lécharny <mailto:elecha...@gmail.com>> wrote:


Hi Guus,

thanks for teh full stack trace.

I've some concern about this blocked thread:
"TaskEngine-pool-3" #40 daemon prio=5 waiting on lock
     java.lang.Thread.State: BLOCKED
         - blocked on
org.apache.mina.filter.ssl.SSLHandlerG0@99f49e2 (owned by
socket_c2s_ssl-thread-2 id=78)
         at
org.apache.mina.filter.ssl.SSLHandlerG0.write(SSLHandlerG0.java:312)
         at
org.apache.mina.filter.ssl.SslFilter.filterWrite(SslFilter.java:380)
         at

org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:753)
         at

org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1500(DefaultIoFilterChain.java:49)
         at

org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.filterWrite(DefaultIoFilterChain.java:1146)
         at

org.apache.mina.filter.codec.ProtocolCodecFilter.filterWrite(ProtocolCodecFilter.java:301)
         at

org.apache.mina.core.filterchain.Defaul

Re: New deadlock potential in MINA 2.2's SSLHandler

[Emmanuel Lécharny]

Hi Guus,

thanks for teh full stack trace.

I've some concern about this blocked thread:
"TaskEngine-pool-3" #40 daemon prio=5 waiting on lock
   java.lang.Thread.State: BLOCKED
	- blocked on org.apache.mina.filter.ssl.SSLHandlerG0@99f49e2 (owned by 
socket_c2s_ssl-thread-2 id=78)

at org.apache.mina.filter.ssl.SSLHandlerG0.write(SSLHandlerG0.java:312)
at org.apache.mina.filter.ssl.SslFilter.filterWrite(SslFilter.java:380)
	at 
org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:753)
	at 
org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1500(DefaultIoFilterChain.java:49)
	at 
org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.filterWrite(DefaultIoFilterChain.java:1146)
	at 
org.apache.mina.filter.codec.ProtocolCodecFilter.filterWrite(ProtocolCodecFilter.java:301)
	at 
org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:753)
	at 
org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1500(DefaultIoFilterChain.java:49)
	at 
org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.filterWrite(DefaultIoFilterChain.java:1146)
	at 
org.apache.mina.core.filterchain.IoFilterAdapter.filterWrite(IoFilterAdapter.java:138)
	at 
org.jivesoftware.openfire.net.StalledSessionsFilter.filterWrite(StalledSessionsFilter.java:61)
	at 
org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:753)
	at 
org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1500(DefaultIoFilterChain.java:49)
	at 
org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.filterWrite(DefaultIoFilterChain.java:1146)
	at 
org.apache.mina.core.filterchain.IoFilterAdapter.filterWrite(IoFilterAdapter.java:138)
	at 
org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:753)
	at 
org.apache.mina.core.filterchain.DefaultIoFilterChain.fireFilterWrite(DefaultIoFilterChain.java:746)
	at 
org.apache.mina.core.session.AbstractIoSession.write(AbstractIoSession.java:575)
	at 
org.apache.mina.core.session.AbstractIoSession.write(AbstractIoSession.java:520)
	at 
org.jivesoftware.openfire.nio.NIOConnection.deliver(NIOConnection.java:349)
	at 
org.jivesoftware.openfire.session.LocalClientSession.deliver(LocalClientSession.java:928)

- locked 
org.jivesoftware.openfire.streammanagement.StreamManager@7e024771
	at 
org.jivesoftware.openfire.session.LocalSession.process(LocalSession.java:407)
	at 
org.jivesoftware.openfire.spi.RoutingTableImpl.routeToLocalDomain(RoutingTableImpl.java:439)
	at 
org.jivesoftware.openfire.spi.RoutingTableImpl.routePacket(RoutingTableImpl.java:350)

...


As you can see, there is a lock on a StreamManager instance following a 
call to org.jivesoftware.openfire.session.La ocalSession.process:


public void process(Packet packet) {
// Check that the requested packet can be processed
if (canProcess(packet)) {
// Perform the actual processing of the packet. This 
usually implies sending

// the packet to the entity
try {
// Invoke the interceptors before we send the packet

InterceptorManager.getInstance().invokeInterceptors(packet, this, false, 
false);
deliver(packet); 
<<<-Here


but I don't see why a lock is taken, unless I don't have the proper 
source code.


Which version are you using when having this deadlock?


On 14/12/2022 09:37, Guus der Kinderen wrote:

Hi Emmanuel,

I was trying to be helpful by leaving out unimportant details, but I 
seem to have messed up. A third thread is involved. I've now attached 
the full thread dump to this email.


Kind regards,

   Guus


On Mon, Dec 12, 2022 at 9:53 AM Emmanuel Lécharny <mailto:elecha...@gmail.com>> wrote:


Hi Guus,

there is something missing in the stacck trace: the two threads are
blocked on different monitors:
* SSLHandlerG0@99f49e2 owned by socket_c2s_ssl-thread-2
* StreamManager@7e024771 owned by TaskEngine-pool-3

they are not related, they are not blocking each one other.

Can you provide the full stack trace ?

Thanks !


On 09/12/2022 10:02, Guus der Kinderen wrote:
 > Hello,
 >
 > I wonder if MINA 2.2.1 introduces a new potential for deadlock in its
 > SSLHandler implementation. Did something change there, as
compared to MINA
 > 2.1.3?
 >
 > Since this upgrade, we consistently run into a thread deadlock.
One of the
 > threads that is deadlocking is sending data to the peer, while
the other is
 > processing data from the peer. The deadlock involves a MINA-based
lock (in
 > SSLHandler), and a lock in our code (StreamManager), that is
responsible
 > for recording what packets that are exchanged have been
ackno

Re: New deadlock potential in MINA 2.2's SSLHandler

[Emmanuel Lécharny]

treamManager.process(StreamManager.java:185)
   at
org.jivesoftware.openfire.net.StanzaHandler.process(StanzaHandler.java:223)
   at
org.jivesoftware.openfire.nio.ConnectionHandler.messageReceived(ConnectionHandler.java:178)
   at
org.apache.mina.core.filterchain.DefaultIoFilterChain$TailFilter.messageReceived(DefaultIoFilterChain.java:1015)
   at
org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:650)
   at
org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1300(DefaultIoFilterChain.java:49)
   at
org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:1128)
   at
org.apache.mina.core.filterchain.IoFilterAdapter.messageReceived(IoFilterAdapter.java:122)
   at
org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:650)
   at
org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1300(DefaultIoFilterChain.java:49)
   at
org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:1128)
   at
org.apache.mina.filter.codec.AbstractProtocolDecoderOutput.flush(AbstractProtocolDecoderOutput.java:64)
   at
org.apache.mina.filter.codec.ProtocolCodecFilter.messageReceived(ProtocolCodecFilter.java:249)
   at
org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:650)
   at
org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1300(DefaultIoFilterChain.java:49)
   at
org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:1128)
   at
org.apache.mina.filter.ssl.SSLHandlerG0.receive_loop(SSLHandlerG0.java:236)
   at org.apache.mina.filter.ssl.SSLHandlerG0.receive(SSLHandlerG0.java:162)
   - locked org.apache.mina.filter.ssl.SSLHandlerG0@99f49e2
   at
org.apache.mina.filter.ssl.SslFilter.messageReceived(SslFilter.java:342)
   at
org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:650)
   at
org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1300(DefaultIoFilterChain.java:49)
   at
org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:1128)
   at
org.apache.mina.core.filterchain.IoFilterEvent.fire(IoFilterEvent.java:106)
   at org.apache.mina.core.session.IoEvent.run(IoEvent.java:89)
   at
org.apache.mina.filter.executor.OrderedThreadPoolExecutor$Worker.runTask(OrderedThreadPoolExecutor.java:763)
   at
org.apache.mina.filter.executor.OrderedThreadPoolExecutor$Worker.runTasks(OrderedThreadPoolExecutor.java:755)
   at
org.apache.mina.filter.executor.OrderedThreadPoolExecutor$Worker.run(OrderedThreadPoolExecutor.java:695)
   at java.base@11.0.17/java.lang.Thread.run(Thread.java:829)



--
*Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
T. +33 (0)4 89 97 36 50
P. +33 (0)6 08 33 32 61
emmanuel.lecha...@busit.com https://www.busit.com/

-
To unsubscribe, e-mail: users-unsubscr...@mina.apache.org
For additional commands, e-mail: users-h...@mina.apache.org

Re: MINA SSLFilter not sending server_name extension in ClientHello

[Emmanuel Lécharny]

ient, please notify the sender by telephone, fax, or return
email and delete this communication and any attachments thereto, immediately
from your computer. Any dissemination, distribution, or copying of this
communication and the attachments thereto (in whole or part), in any manner,
is strictly prohibited and actionable at law. The recipient acknowledges
that emails are susceptible to alteration and their integrity cannot be
guaranteed and that Company does not guarantee that any e-mail is virus-free
and accept no liability for any damage caused by any virus transmitted by
this email."

  





--
*Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
T. +33 (0)4 89 97 36 50
P. +33 (0)6 08 33 32 61
emmanuel.lecha...@busit.com https://www.busit.com/

-
To unsubscribe, e-mail: users-unsubscr...@mina.apache.org
For additional commands, e-mail: users-h...@mina.apache.org

Re: Configuring idle timeouts on server

[Emmanuel Lécharny]

On 07/03/2022 17:45, Marc Boorshtein wrote:



A better solution would be to modify the Handler to catch the
sessionIdle event and check for how long the session was idling (the
event will be received every second)



When you say "modify the Handler", does that require a change to Mina's 
code?  or is this something I can do  without changing Mina?


This can be done in the LdapProtocolHandler class, because it extends 
DemuxingIoHandler which extends IoHandlerAdapter which exposes :


/**
 * {@inheritDoc}
 */
@Override
public void sessionIdle(IoSession session, IdleStatus status) 
throws Exception {

// Empty handler
}


So just override this method to get the event.


--
*Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
T. +33 (0)4 89 97 36 50
P. +33 (0)6 08 33 32 61
emmanuel.lecha...@busit.com https://www.busit.com/

-
To unsubscribe, e-mail: users-unsubscr...@mina.apache.org
For additional commands, e-mail: users-h...@mina.apache.org

Re: Configuring idle timeouts on server

[Emmanuel Lécharny]

Also note that we can get idling event for
- read
- write
- both

Ie if a session has not written for a specific period of time, an idle 
event will be generated and transmitted for WRITE, and not for READ.


Also note that the event is at least generated once a second, but not 
necessarily transmitted, as the session can be configured to propagate 
the even less frequently:


session.getConfig().setIdleTime(IdleStatus.BOTH_IDLE, 10);
will check the session idle state for READ and WRITE every second *but* 
will propagate an idling event if the session has been idling for at 
least 10 seconds.


On 07/03/2022 17:35, Emmanuel Lécharny wrote:

Hi Marc,

this is probably a bit overkilling, especially if you manage many sessions.

A better solution would be to modify the Handler to catch the 
sessionIdle event and check for how long the session was idling (the 
event will be received every second)



On 07/03/2022 16:28, Marc Boorshtein wrote:
Closing the loop, and hoping for a logic check to make sure my 
thinking is correct.  I was able to make this work by:


1. Creating an IoServiceListener on my acceptor
2. The IoServiceListener creates a Thread that iterates over all of 
the IoSessions in the ManagedSessions map
   if an IoSession.getLastIoTime() is greater then a specified time 
period old, call session.closeNow()
3. in the IoServiceListener, when the service is destroyed, shut down 
the idle check thread.


Experimentally, this solution is working well.  But I wanted to see if 
you had any feedback or something I was missing?


Thanks
Marc

On Fri, Mar 4, 2022 at 3:34 PM Marc Boorshtein <mailto:mboorsht...@gmail.com>> wrote:


    Sounds quite a good feature to me.



    Thanks for the detailed explanation.  Am I able to implement this
    without having to make a feature change to Mina?  If you pointed me
    in the right direction I'm sure I can figure it out but I really
    don't know where to start.

    Thanks
    Marc





--
*Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
T. +33 (0)4 89 97 36 50
P. +33 (0)6 08 33 32 61
emmanuel.lecha...@busit.com https://www.busit.com/

-
To unsubscribe, e-mail: users-unsubscr...@mina.apache.org
For additional commands, e-mail: users-h...@mina.apache.org

Re: Configuring idle timeouts on server

[Emmanuel Lécharny]

Hi Marc,

this is probably a bit overkilling, especially if you manage many sessions.

A better solution would be to modify the Handler to catch the 
sessionIdle event and check for how long the session was idling (the 
event will be received every second)



On 07/03/2022 16:28, Marc Boorshtein wrote:
Closing the loop, and hoping for a logic check to make sure my thinking 
is correct.  I was able to make this work by:


1. Creating an IoServiceListener on my acceptor
2. The IoServiceListener creates a Thread that iterates over all of the 
IoSessions in the ManagedSessions map
   if an IoSession.getLastIoTime() is greater then a specified time 
period old, call session.closeNow()
3. in the IoServiceListener, when the service is destroyed, shut down 
the idle check thread.


Experimentally, this solution is working well.  But I wanted to see if 
you had any feedback or something I was missing?


Thanks
Marc

On Fri, Mar 4, 2022 at 3:34 PM Marc Boorshtein <mailto:mboorsht...@gmail.com>> wrote:


Sounds quite a good feature to me.



Thanks for the detailed explanation.  Am I able to implement this
without having to make a feature change to Mina?  If you pointed me
in the right direction I'm sure I can figure it out but I really
don't know where to start.

Thanks
Marc



--
*Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
T. +33 (0)4 89 97 36 50
P. +33 (0)6 08 33 32 61
emmanuel.lecha...@busit.com https://www.busit.com/

-
To unsubscribe, e-mail: users-unsubscr...@mina.apache.org
For additional commands, e-mail: users-h...@mina.apache.org

Re: Configuring idle timeouts on server

[Emmanuel Lécharny]

Hi,

the idle event is just informative. You have to handle it in your 
Handler. Typically, everytime the idle event is received b-y the 
handler, you increment a counter that is stored in teh IoSession 
attribute. When this counter get higher to the value you have set, then 
you can simple close the IoSession in the handler.


Note that could be a good idea to change this to become a MINA feature, 
like :

- after having idling for more than N seconds, then shutdown the counter.

That would require we keep a track of this counter in the IoSession 
instance, increment it each tile the idle event is generated, and reset 
it when some data are received or sent.


Sounds quite a good feature to me.

On 04/03/2022 20:05, Marc Boorshtein wrote:

Hello,

I'm using mina 2.1.1 from api-ldap-net-mina.  I want connections to close
if idle from more then a specific amount of time.  I
tried 
org.apache.directory.server.protocol.shared.transport.TcpTransport.setBothIdleTime(2)
but after sitting idle for 6 seconds I was able to continue without issue.
Is there something else I need to do to make sure that connections are
closed when idle after a set amount of time?

Thanks
Marc



--
*Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
T. +33 (0)4 89 97 36 50
P. +33 (0)6 08 33 32 61
emmanuel.lecha...@busit.com https://www.busit.com/

-
To unsubscribe, e-mail: users-unsubscr...@mina.apache.org
For additional commands, e-mail: users-h...@mina.apache.org

Re: [ANNOUNCE] Apache MINA 2.0.23 released

[Emmanuel Lécharny]

Hi Leonardo,

I think the web site need to be updated. It definitively requires Java 8 :


  org.apache.maven.plugins
  maven-compiler-plugin
  ${version.compiler.plugin}
  
1.8
1.8


I will update the site.

Thanks !

On 21/02/2022 10:07, Leonardo D'Alimonte wrote:

Hello Emmanuel,
this latest bugfix release does really require Java 8 to be run?

I see on the Apache Mina downloads website that the Java version required
is version 7, maybe it's just a mistake :)

Thanks in advance

*Leonardo D'Alimonte *

[image: Loginet logo]

Diretto : +39 0227071955

Fax : +39 0227071931

Mobile : +39 3930746502

Viale Monza 270

20128 Milan

Italy

leonardo.dalimo...@loginet.it

www.loginet.it

*This message (including any attachments) may contain confidential
information intended for a specific individual and purpose, and is
protected by law. If you are not the intended recipient, you should delete
this message and are hereby notified that any disclosure, copying, or
distribution of this message, or the taking of any action based on it, is
strictly prohibited.*



On Sat, Feb 19, 2022 at 7:12 AM Emmanuel Lecharny 
wrote:


The Apache MINA project is pleased to announce the release of Apache
MINA 2.0.23.

This is a bug fix release. Many fixes made in 2.1.6 and 2.2 were
backported in this version.

We consider this a stable and production ready release.

Java 8 is required to run this version.

We welcome you to try it out.

The latest release is now available here:

https://mina.apache.org/mina-project/downloads_2_0.html

Thanks for the feedback that made this release possible!

The Apache MINA project


--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

-
To unsubscribe, e-mail: users-unsubscr...@mina.apache.org
For additional commands, e-mail: users-h...@mina.apache.org






--
*Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
T. +33 (0)4 89 97 36 50
P. +33 (0)6 08 33 32 61
emmanuel.lecha...@busit.com https://www.busit.com/

-
To unsubscribe, e-mail: users-unsubscr...@mina.apache.org
For additional commands, e-mail: users-h...@mina.apache.org

Re: System become unresponsive. nio socket, server, null => 0.0.0.0/0.0.0.0:13101

[Emmanuel Lécharny]

Hi,


On 18/01/2022 09:17, Chandrasekar, Sampathkumar wrote:

Hi,

We have an application that is built with *apache MINA 2.0.7* as a backbone
for communicating with clients. Primarily used for XML messages over socket
connections.


2.0.7 is almost 10 years old. I would suggest you give MINA 2.0.22 a try.




It is non-reproducible in our staging system. only happened twice at the
production system!

System running the application for many days without any issues. All of a
sudden, the application stopped responding to the incoming messages and
printed the following message

*(0x0143: nio socket, server, null => 0.0.0.0/0.0.0.0:13101
<http://0.0.0.0/0.0.0.0:13101>), remote address is null*

15 mins later, the customer restarted the machine. while shutting down,
the application tries to shutdown ThreadPoolExecutor (
inThreadPoolExecutor.shutdownNow();) and it pours with the following log
entries. Totally 700 entries.

2022-01-14 09:41:06,121 WARN  | main ()  | [Ecn4Util:?] shutting down
thread >[(0x0001: nio socket, server, null => 0.0.0.0/0.0.0.0:13101)]
MESSAGE_RECEIVED: [com.navis.ecn4.xmlrdt.impl.XmlRdtEnvelope@ab11e76]<
before execution
2022-01-14 09:41:06,121 WARN  | main ()  | [Ecn4Util:?] shutting down
thread >[(0x0001: nio socket, server, null => 0.0.0.0/0.0.0.0:13101)]
MESSAGE_RECEIVED: [com.navis.ecn4.xmlrdt.impl.XmlRdtEnvelope@72f91c91]<
before execution
2022-01-14 09:41:06,121 WARN  | main ()  | [Ecn4Util:?] shutting down
thread >[(0x022F: nio socket, server, null => 0.0.0.0/0.0.0.0:13101)]
SESSION_OPENED< before execution
2022-01-14 09:41:06,121 WARN  | main ()  | [Ecn4Util:?] shutting down
thread >[(0x022F: nio socket, server, null => 0.0.0.0/0.0.0.0:13101)]
MESSAGE_RECEIVED: [com.navis.ecn4.xmlrdt.impl.XmlRdtEnvelope@69d6fe75]<
before execution
2022-01-14 09:41:06,121 WARN  | main ()  | [Ecn4Util:?] shutting down
thread >[(0x022F: nio socket, server, null => 0.0.0.0/0.0.0.0:13101)]
SESSION_CLOSED< before execution

Kindly request to you take a look at the above log and let me know what
went wrong and how to address it.

Thanks and Regards,
Sampath



--
*Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
T. +33 (0)4 89 97 36 50
P. +33 (0)6 08 33 32 61
emmanuel.lecha...@busit.com https://www.busit.com/

-
To unsubscribe, e-mail: users-unsubscr...@mina.apache.org
For additional commands, e-mail: users-h...@mina.apache.org

Re: MINA's OrderedThreadPoolExecutor has queued work, but no workers

[Emmanuel Lécharny]

On 12/01/2022 13:47, Guus der Kinderen wrote:

Hi Emmanuel,

Thanks for your speedy reply. I have created an issue as you requested: 
https://igniterealtime.atlassian.net/browse/OF-2367 
<https://igniterealtime.atlassian.net/browse/OF-2367>


In your email, you're writing that the exception seems to be due to some 
TLS handshake. How did you come to that conclusion? You might very well 
be right, but I don't see how I could have given you any data to support 
this hypothesis? :)


Well, you mentionned logs like:

javax.net.ssl.SSLHandshakeException: SSL handshake failed.

and I (quickly) jumped to conclusion that TLS might be a cause.

But it was 4 AM, and I agree it's pulled out of thin air.


A question though: is the SSLFilter before or after the ExecutorFilter 
in your chain ? (I would assume before).


If it's before, then the HS failure would have no impact.



You're also writing:

I suspect that TLS 1.3 is being used on the client side, which is not
currently supported properly by MINA (just an hypothesis).


Is TLS 1.3 support in MINA definitely unsupported, or is that a 
hypothesis? If TLS 1.3 support is lacking, then that is of concern for 
me. That might be something to spin off to a different thread though, to 
not muddy the waters too much.


We definitively have some issue with TLS 1.3, and this is being 
investigated::


https://issues.apache.org/jira/browse/DIRMINA-1132



my bad, if we get an exception during the runTasks execution, we won't
exit the for(;;) loop, so this is plain normal to have an
idleWorkers.incrementAndGet(); in the finally part.


Are you sure? I believe that you were originally correct. 


Well, I kow do think that the exception not being caught will be 
propagated to the next catch, ie the one that remove the worker from the 
pool.


In any case, the finally block should increase the number of idle 
worker, and that is not going to be correct because the idleWorker count 
is now going to be incremented while the worker has been removed.


I'm not sure the finally block is useful at all at this point.

Anyway, I just committed the change.

I've written a
test that throws an Exception during runTasks, and then compares the 
workers size with the idleWorkers count. In my test, the idleWorkers is 
_higher_ than the worker size (which I think is indicative of a bug). An 
important note is that my test generates an Exception in a way that is 
different from how the Executor would normally be used. I think I've 
proven that _when_ an Exception occurs, things go wrong, but that I have 
not yet found _how_ that Exception can occur.


While writing this email, I received what I believe to be conclusive 
evidence of the above. I've asked a user that suffers from the problem 
to run with a slightly modified version of MINA. The modification logs 
(and rethrows) any Throwable in Worker's run(). This caused an Error to 
be logged! The Error was thrown by an IoHandler implementation. Full 
details are available at 
https://igniterealtime.atlassian.net/browse/OF-2367?focusedCommentId=22738 
<https://igniterealtime.atlassian.net/browse/OF-2367?focusedCommentId=22738>


I will modify the IoHandler implementation at our end to prevent this. 
None-the-less, I believe that MINA should guard against this. I suspect 
that removing the 'finally' block that is inside the for (;;) block of 
Worker, and making execution of idleWorkers.incrementAndGet(); happen 
only when no Throwable is thrown, is a huge improvement. In other words, 
replace:


try {
 if (session !=null) {
 runTasks(getSessionTasksQueue(session));
 }
 }finally {
 idleWorkers.incrementAndGet();
 }

with this:

if (session !=null) {
 runTasks(getSessionTasksQueue(session));
 }
idleWorkers.incrementAndGet();

Wez see that we increment the idling workers counter before adding the
worker to the workers set.


I suspect that you are theoretically correct here. Given what I wrote 
earlier, I don't think it is the current cause of the issue at hand. It 
might be good to harden the code like this though.


Kind regards,

   Guus
On Wed, 12 Jan 2022 at 04:49, Emmanuel Lécharny <mailto:elecha...@gmail.com>> wrote:


Hi again,

my bad, if we get an exception during the runTasks execution, we won't
exit the for(;;) loop, so this is plain normal to have an
idleWorkers.incrementAndGet(); in the finally part.

There are two places where we exit the loop:
- if we exceed the number of workers
- when session == EXIT_SIGNAL

and in those cases, the idleWorkers counter has been dully decremented,
so we should be good to go.


If we now have a look at the addWorker() method:

      private void addWorker() {
          synchronized (workers) {
              if (workers.size() >= super.getMaximumPoolSize()) {
                  return;
              }

              // Crea

Re: MINA's OrderedThreadPoolExecutor has queued work, but no workers

[Emmanuel Lécharny]

Hi again,

my bad, if we get an exception during the runTasks execution, we won't 
exit the for(;;) loop, so this is plain normal to have an 
idleWorkers.incrementAndGet(); in the finally part.


There are two places where we exit the loop:
- if we exceed the number of workers
- when session == EXIT_SIGNAL

and in those cases, the idleWorkers counter has been dully decremented, 
so we should be good to go.



If we now have a look at the addWorker() method:

private void addWorker() {
synchronized (workers) {
if (workers.size() >= super.getMaximumPoolSize()) {
return;
}

// Create a new worker, and add it to the thread pool
Worker worker = new Worker();
Thread thread = getThreadFactory().newThread(worker);

// As we have added a new thread, it's considered as idle.
idleWorkers.incrementAndGet();

// Now, we can start it.
thread.start();
workers.add(worker);


Wez see that we increment the idling workers counter before adding the 
worker to the workers set. It might explain why we see 2 idling workers 
when the set has no worker.


May be the sequence should be :

workers.add(worker);

// As we have added a new thread, it's considered as idle.
idleWorkers.incrementAndGet();

// Now, we can start it.
thread.start();

That should be safe because we are in a synchronized section on workers.


On 12/01/2022 04:34, Emmanuel Lécharny wrote:

Hi Guus,

I agree there is some inconsistency, and I need to check why.

Regarding the initial pb, it seems like an exception causes the worker 
to be removed, and this exception seems to be due to some TLS handshake 
failure.


I suspect that TLS 1.3 is being used on the client side, which is not 
currently supported properly by MINA (just an hypothesis).


Regardless, there is something puzzling:

private class Worker implements Runnable {

     public void run() {

     try {
     for (;;) {
     IoSession session = fetchSession();

     idleWorkers.decrementAndGet();

     if (session == null) {
     synchronized (workers) {
     if (workers.size() > getCorePoolSize()) {
     // Remove now to prevent duplicate exit.
     workers.remove(this);   <<<-
     break;
     }
     ...


     } finally {
     synchronized (workers) {
     workers.remove(this); <<


In the case where we reach the max pool size, we try to remove it twice. 
Ok, it's not really critical, because the first call will succeed, and 
the second will do nothing.


And yes, if there is an exception during the runTasks, we will have an 
increment of the idleWorkers despite the fact the worker will be removed.



Bottom line, there is a need to get this fixed.

Can you open a JIRA for tracability?


On 11/01/2022 17:26, Guus der Kinderen wrote:
Although I'm not sure if this is the source of my issue, I can 
reproduce the state by creating a unit test that causes a 
RuntimeException and/or Error to be thrown by a filter that is 
processing an event.


In OrderedThreadPoolExecutor's Worker, this snippet causes the Worker 
to be removed, but the idleWorker count to be increased in such a 
scenario. Should the first try/finally block be removed perhaps 
(causing idleWorkers to be increased only if runTasks didn't throw 
anything?


 try {
 if (session !=null) {
 runTasks(getSessionTasksQueue(session));
 }
 }finally {
 idleWorkers.incrementAndGet();
 }
 }
}finally {
 synchronized (workers) {
 workers.remove(this);
 OrderedThreadPoolExecutor.this.completedTaskCount 
+=completedTaskCount.get();

 workers.notifyAll();
 }
}


On Tue, 11 Jan 2022 at 15:41, Guus der Kinderen 
mailto:guus.der.kinde...@gmail.com>> wrote:


    Hello,

    This was found with MINA 2.1.3. Is this a bug? I stumbled upon this
    while performing analysis of heap dumps of a JVMs that suffered from
    an issue where no user was able to establish a connection to our
    server software anymore.

    Our application uses an ExecutorFilter. The
    OrderedThreadPoolExecutor of the affected server seems to be in an
    inconsistent state:

  * idleWorkers: 2
  * waitingSessions.count: 2293
  * workers.map.size: 0

    I will attempt to include a screenshot of the profiler that holds
    more data (if the mailinglist allows me).

    What strikes me as odd is:

  * No workers, while there are sessions waiting to be processed
  * No workers, but a non-zero idle workers count

    Servers that are unaffected by the issue have an idle wor

Re: MINA's OrderedThreadPoolExecutor has queued work, but no workers

[Emmanuel Lécharny]

Hi Guus,

I agree there is some inconsistency, and I need to check why.

Regarding the initial pb, it seems like an exception causes the worker 
to be removed, and this exception seems to be due to some TLS handshake 
failure.


I suspect that TLS 1.3 is being used on the client side, which is not 
currently supported properly by MINA (just an hypothesis).


Regardless, there is something puzzling:

private class Worker implements Runnable {

public void run() {

try {
for (;;) {
IoSession session = fetchSession();

idleWorkers.decrementAndGet();

if (session == null) {
synchronized (workers) {
if (workers.size() > getCorePoolSize()) {
// Remove now to prevent duplicate exit.
workers.remove(this);   <<<-
break;
}
...


} finally {
synchronized (workers) {
workers.remove(this); <<


In the case where we reach the max pool size, we try to remove it twice. 
Ok, it's not really critical, because the first call will succeed, and 
the second will do nothing.


And yes, if there is an exception during the runTasks, we will have an 
increment of the idleWorkers despite the fact the worker will be removed.



Bottom line, there is a need to get this fixed.

Can you open a JIRA for tracability?


On 11/01/2022 17:26, Guus der Kinderen wrote:
Although I'm not sure if this is the source of my issue, I can reproduce 
the state by creating a unit test that causes a RuntimeException and/or 
Error to be thrown by a filter that is processing an event.


In OrderedThreadPoolExecutor's Worker, this snippet causes the Worker to 
be removed, but the idleWorker count to be increased in such a scenario. 
Should the first try/finally block be removed perhaps (causing 
idleWorkers to be increased only if runTasks didn't throw anything?


 try {
 if (session !=null) {
 runTasks(getSessionTasksQueue(session));
 }
 }finally {
 idleWorkers.incrementAndGet();
 }
 }
}finally {
 synchronized (workers) {
 workers.remove(this);
 OrderedThreadPoolExecutor.this.completedTaskCount 
+=completedTaskCount.get();
 workers.notifyAll();
 }
}


On Tue, 11 Jan 2022 at 15:41, Guus der Kinderen 
mailto:guus.der.kinde...@gmail.com>> wrote:


Hello,

This was found with MINA 2.1.3. Is this a bug? I stumbled upon this
while performing analysis of heap dumps of a JVMs that suffered from
an issue where no user was able to establish a connection to our
server software anymore.

Our application uses an ExecutorFilter. The
OrderedThreadPoolExecutor of the affected server seems to be in an
inconsistent state:

  * idleWorkers: 2
  * waitingSessions.count: 2293
  * workers.map.size: 0

I will attempt to include a screenshot of the profiler that holds
more data (if the mailinglist allows me).

What strikes me as odd is:

  * No workers, while there are sessions waiting to be processed
  * No workers, but a non-zero idle workers count

Servers that are unaffected by the issue have an idle worker count
that is equal to the amount of workers (I assume that the snapshots
were taken when that server was not actively processing data).

For reference: the issue that we are experiencing (possibly caused
by this) is tracked in
https://igniterealtime.atlassian.net/browse/OF-2367
<https://igniterealtime.atlassian.net/browse/OF-2367>. Multiple
people are reporting the issue, but I've been unable to reproduce it
locally.

Kind regards,

   Guus

image.png



--
*Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
T. +33 (0)4 89 97 36 50
P. +33 (0)6 08 33 32 61
emmanuel.lecha...@busit.com https://www.busit.com/

-
To unsubscribe, e-mail: users-unsubscr...@mina.apache.org
For additional commands, e-mail: users-h...@mina.apache.org

Re: MINA and JMX: MemberAccess implementation must be provided

[Emmanuel Lécharny]

Never mindd, found it (3.2.10). And it was a typo in my mail (IGNL 
instead of OGNL. Blame my MAC crappy keyboard...)


From the stack trace, it may be an OGNL bug:

public static Map createDefaultContext(Object root)
{
return addDefaultContext(root, null, null, null, new 
OgnlContext(null, null, null));<--- member access null ???

}

and :

public OgnlContext(ClassResolver classResolver, TypeConverter 
typeConverter, MemberAccess memberAccess)

{
// No 'values' map has been specified, so we create one of the 
default size: 23 entries

this(memberAccess, classResolver, typeConverter, new HashMap(23));
}

and

public OgnlContext(MemberAccess memberAccess, ClassResolver 
classResolver, TypeConverter typeConverter, Map values)

{
super();

...

if (memberAccess != null) { < Obviosuly, memberAccss is null
this._memberAccess = memberAccess;
} else {
throw new RuntimeException("MemberAccess implementation 
must be provided!");

}


I wonder if this piece of code ever worked...

On 06/08/2021 08:16, Guus der Kinderen wrote:

Hi Emmanuel,

I'm not sure that I'm using any? Grepping through my dependency list for 
'ignl' does not yield any results. I've attached the output of mvn 
dependency:list as a dependency for good measure (ANSI warning: use 
'less -r' for proper rendering).


What is this beast anyway? Trying to Google for "ignl" or "ignl mina" 
does not give me any useful hints, and the mvnrepository.com 
<http://mvnrepository.com/> search index does not show any artifacts by 
that name either.


Kind regards,

   Guus

On Fri, 6 Aug 2021 at 06:17, Emmanuel Lécharny <mailto:elecha...@gmail.com>> wrote:


Hi,

which version of the IGNL lib are you using ?

On 04/08/2021 16:48, Guus der Kinderen wrote:
 > I'm trying the register and use the MINA-provided MBeans,
following the
 > guide provided at
 >

https://mina.apache.org/mina-project/userguide/ch16-jmx-support/ch16-jmx-support.html

<https://mina.apache.org/mina-project/userguide/ch16-jmx-support/ch16-jmx-support.html>
 >
 > Compile-time, everything is OK, and runtime, the beans appear to be
 > registered properly. However, whenever someone tries to access
attributes
 > of one of the registered beans, this fails. Server-sided, this
exception is
 > logged.
 >
 > 021.08.04 15:49:41 WARN  [Jetty-QTP-BOSH-95]:
 > org.apache.mina.integration.jmx.ObjectMBean - Unexpected exception.
 > java.lang.RuntimeException: MemberAccess implementation must be
provided!
 >          at ognl.OgnlContext.(OgnlContext.java:140)
 > ~[ognl-3.2.10.jar:?]
 >          at ognl.OgnlContext.(OgnlContext.java:110)
 > ~[ognl-3.2.10.jar:?]
 >          at ognl.Ognl.createDefaultContext(Ognl.java:159)
 > ~[ognl-3.2.10.jar:?]
 >          at
 >

org.apache.mina.integration.jmx.ObjectMBean.getAttribute(ObjectMBean.java:646)
 > ~[mina-integration-jmx-2.1.3.jar:?]
 >          at
 >

org.apache.mina.integration.jmx.ObjectMBean.getAttribute(ObjectMBean.java:186)
 > ~[mina-integration-jmx-2.1.3.jar:?]
 >          at
 >

com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getAttribute(DefaultMBeanServerInterceptor.java:647)
 > ~[?:1.8.0_292]
 >
 > I'm not sure exactly how to interpret this. One possibility that I
 > considered was that I was missing concrete implemenations, so, in
addition
 > to the dependencies:
 >
 > - org.apache.mina:mina-core
 > - org.apache.mina:mina-integration-jmx
 >
 > I experimented with adding:
 >
 > - org.apache.mina:mina-integration-beans
 > - org.apache.mina:mina-integration-ognl
 >
 > Sadly, that didn't make a difference. Do I need another
dependency, or am I
 > looking at this entirely wrong?
 >
 > Kind regards,
 >
 >    Guus
 >

-- 
*Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE

T. +33 (0)4 89 97 36 50
P. +33 (0)6 08 33 32 61
emmanuel.lecha...@busit.com <mailto:emmanuel.lecha...@busit.com>
https://www.busit.com/ <https://www.busit.com/>

-
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>



-
To unsubscribe, e-mail: users-unsubscr...@mina.apache.org
For additional commands, e-mail: users-h...@mina.apache.org



--
*Emmanuel Lécharny - CTO* 2

Re: MINA and JMX: MemberAccess implementation must be provided

[Emmanuel Lécharny]

Hi,

which version of the IGNL lib are you using ?

On 04/08/2021 16:48, Guus der Kinderen wrote:

I'm trying the register and use the MINA-provided MBeans, following the
guide provided at
https://mina.apache.org/mina-project/userguide/ch16-jmx-support/ch16-jmx-support.html

Compile-time, everything is OK, and runtime, the beans appear to be
registered properly. However, whenever someone tries to access attributes
of one of the registered beans, this fails. Server-sided, this exception is
logged.

021.08.04 15:49:41 WARN  [Jetty-QTP-BOSH-95]:
org.apache.mina.integration.jmx.ObjectMBean - Unexpected exception.
java.lang.RuntimeException: MemberAccess implementation must be provided!
 at ognl.OgnlContext.(OgnlContext.java:140)
~[ognl-3.2.10.jar:?]
 at ognl.OgnlContext.(OgnlContext.java:110)
~[ognl-3.2.10.jar:?]
 at ognl.Ognl.createDefaultContext(Ognl.java:159)
~[ognl-3.2.10.jar:?]
 at
org.apache.mina.integration.jmx.ObjectMBean.getAttribute(ObjectMBean.java:646)
~[mina-integration-jmx-2.1.3.jar:?]
 at
org.apache.mina.integration.jmx.ObjectMBean.getAttribute(ObjectMBean.java:186)
~[mina-integration-jmx-2.1.3.jar:?]
 at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getAttribute(DefaultMBeanServerInterceptor.java:647)
~[?:1.8.0_292]

I'm not sure exactly how to interpret this. One possibility that I
considered was that I was missing concrete implemenations, so, in addition
to the dependencies:

- org.apache.mina:mina-core
- org.apache.mina:mina-integration-jmx

I experimented with adding:

- org.apache.mina:mina-integration-beans
- org.apache.mina:mina-integration-ognl

Sadly, that didn't make a difference. Do I need another dependency, or am I
looking at this entirely wrong?

Kind regards,

   Guus



--
*Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
T. +33 (0)4 89 97 36 50
P. +33 (0)6 08 33 32 61
emmanuel.lecha...@busit.com https://www.busit.com/

-
To unsubscribe, e-mail: users-unsubscr...@mina.apache.org
For additional commands, e-mail: users-h...@mina.apache.org

Re: Mina Server losing messages

[Emmanuel Lécharny]

Also provide files that can be tested directly.

I get an exception because the 
"C:\\git\\commserver\\security\\.keystore" is not found (obviously, 
because I'm not on windows).


Same thing for D:\\TCP_Layer_files\\security\\truststore.

That may be totally orthogonal to the problem you get, but if we can't 
run the code because we don't have the full env, we are wasting time we 
don't have.


Lats, not least, which Java version are you using ?



On 27/06/2021 18:20, Jonathan Valliere wrote:

Thanks for the report. Please make an issue in JIRA.

On Sun, Jun 27, 2021 at 12:14 PM Itzhaki, Guy
 wrote:


Hi all,



During our tests we found that in some circumstances Mina server loses
messages.

 From what we understand this happens when client opens connection and then
sends message(s) and the server is still busy processing the sessionOpened
event while the message the client sent went through the server’s
filterChain.



Attached is a simple client and server that will help you reproduce the
problem, before you run it please perform the following steps:

*Configuration:*

1. In order to reproduce the problem SSL filter must be defined
(already implemented in the attached example)
2. Update the keystore and truststore files locations and passwords in
*addSSLFilter()* method in *MinaClient* and *MinaServer*
3. Set server break points at:
   1. MinaServerHandler#sessionOpened
   2. MinaServerHandler#messageReceived
   3.
   org.apache.mina.core.filterchain.IoFilter.NextFilter#messageReceived
4. Set client break points at:
   1. MinaClientHandler#sessionOpened



*Since this is a timing problem you need to run a debugger as described
below:*

1. Start server
2. Start client
3. At the client at *MinaClientHandler#sessionOpened* release the
break point
4. Release all break points *except* server’s
*MinaServerHandler#sessionOpened*
5. After
org.apache.mina.core.filterchain.IoFilter.NextFilter#messageReceived
completed to process all events, you can release
*MinaServerHandler#sessionOpened*



Expected result:

MinaServerHandler#messageReceived will be invoked with the message sent by
the client



Actual result:

MinaServerHandler#messageReceived is not invoked.



To use the example, add the following jars to your class path:

commons-lang3-3.9.jar

log4j-api-2.13.3.jar

log4j-core-2.13.3.jar

log4j-jcl-2.13.3.jar

mina-core-2.1.4.jar

slf4j-api-1.7.26.jar

spring-jcl-5.2.12.RELEASE.jar





We are using mina 2.1.4



Your help is highly appreciated as this prevents us from releasing the
product.



Thanks,

Guy



-
To unsubscribe, e-mail: users-unsubscr...@mina.apache.org
For additional commands, e-mail: users-h...@mina.apache.org




--
*Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
T. +33 (0)4 89 97 36 50
P. +33 (0)6 08 33 32 61
emmanuel.lecha...@busit.com https://www.busit.com/

-
To unsubscribe, e-mail: users-unsubscr...@mina.apache.org
For additional commands, e-mail: users-h...@mina.apache.org

Re: Secure websocket connection fails when browser does a TLS False Start

[Emmanuel Lécharny]

Hi,

MINA does not support the TLS false start extension. When the Handshake 
is initiated, it has to be fulfilled, and any message that is not part 
of the TLS handshake process will be discarded.



On 16/06/2021 18:41, Derek Clayton wrote:

Hello,

I can create a more detailed report but wanted to quickly see if anyone
knows if this is a known issue with MINA or believes it should work and the
problem is with our use of MINA. There was nothing I could find in the
Issue Tracker.

When making a wss (Secure Websocket) connection the connection will fail if
the browser does a TLS False Start by sending the HTTP GET "Connection:
upgrade" request along with the CLIENT FINISH TLS in a single message (ie
before it receives the server finish). The SSLFilter and SSLHandler still
complete the handshake when this happens but the HTTP GET is never passed
to the application for processing. I believe the buffer with the bytes
containing the HTTP GET is simply discarded or reset after the handshake is
complete.

If the browser does not do a TLS False Start and instead waits for the TLS
handshake to complete before sending the websocket connection upgrade
request then the wss connects successfully.

Thanks!



--
*Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
T. +33 (0)4 89 97 36 50
P. +33 (0)6 08 33 32 61
emmanuel.lecha...@busit.com https://www.busit.com/

-
To unsubscribe, e-mail: users-unsubscr...@mina.apache.org
For additional commands, e-mail: users-h...@mina.apache.org

Re: No web page found for SHA hash code, Mina SSHD 2.5.1

[Emmanuel Lécharny]

Hi !

Sorry, this is a glitch on our web site.


The signature can be found here :


https://archive.apache.org/dist/mina/sshd/2.5.1


On 23/02/2021 12:29, Walla, Marcus wrote:

Dear colleagues!

I downloaded the latest release of Apache Mina SSHD 2.5.1 
(https://mina.apache.org/sshd-project/download_2.5.1.html) and wanted to verify the ZIP file 
against the published SHA hash. But it reports "Not Found" 
(https://downloads.apache.org/mina/sshd/2.5.1/apache-sshd-2.5.1.zip.sha1) when I click on the 
"SHA" link. Can you reproduce the behaviour and possible fix it?

Best regards,
Marcus Walla


Marcus Walla   Deutsches Elektronen-Synchrotron MCS1
phone:  +49-40-8998-2628Notkestr. 85
fax:+49-40-8994-4303   22607 Hamburg
e-mail: marcus.wa...@desy.de Germany


-
To unsubscribe, e-mail: users-unsubscr...@mina.apache.org
For additional commands, e-mail: users-h...@mina.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@mina.apache.org
For additional commands, e-mail: users-h...@mina.apache.org

Re: sshd SHA1 link

[Emmanuel Lécharny]

Thanks, we will fix that on the web site.

You can use the SHA256 or SHA512 signatures which are available on those 
links :



https://downloads.apache.org/mina/sshd/2.5.1/apache-sshd-2.5.1.tar.gz.sha256

https://downloads.apache.org/mina/sshd/2.5.1/apache-sshd-2.5.1.tar.gz.sha512


check on https://downloads.apache.org/mina/sshd/2.5.1/


FYI, we will not anymore provide SHA1 signatures, for security reasons.


Hope it helps

On 18/11/2020 17:48, Даниил wrote:

apache mina sshd SHA1 link is not working on download page



-
To unsubscribe, e-mail: users-unsubscr...@mina.apache.org
For additional commands, e-mail: users-h...@mina.apache.org

Re: MINA vs a NIO based protocol stack

[Emmanuel Lécharny]

On 14/04/2020 14:31, Simha N wrote:

Hi,

I am evaluating MINA for development of Java based networking clients based
on protocols such as SNMP and Netconf.

Protocol stacks are available for these protocols. Some of the stacks are
based on Java NIO (example: SNMP4J) and some are not based on Java NIO
(Example: JoeSNMP and JNC).

In order to develop a networking client using MINA, Application developer
shall write a Codec by implementing the interface ProtocolDecoderAdapter
for each protocol. Application developer has to understand chosen protocol
stack API well to write the codec. This needs good amount of protocol
knowledge.

If my protocol stack is based on Java BIO (not a NIO), then I see a valid
reason to move to MINA to get performance gain in spite effort needed to
writing codec.

But, if my protocol stack is based on Java NIO, what is the advantage of
using MINA? Does it bring in any performance gain?


Simplicity. It alleviates you from dealing of all the burden of managing 
the Selector on your own. You just end with dealing with events like 
'messageReceived' or 'messageSent', plus the few session management 
messages (sessionOpened, sessionClosed, etc)


It also deals with fragmentation, which is quite a relief.

It won't bring you any performance, because you are adding a stack on 
top of NIO.


-
To unsubscribe, e-mail: users-unsubscr...@mina.apache.org
For additional commands, e-mail: users-h...@mina.apache.org

Re: MINA: ExecutorFilter on NioSocketConnector

[Emmanuel Lécharny]

On 09/04/2020 16:01, Nitin Phuria wrote:

Dear Jonathan,

  


Anytime we write message to System-B session with session.write method the 
messageSent event has to be generated with it actually gets written on TCP/IP



The messageSent event is only generated when the message has been fully 
written into the socket. A message can be written piece by piece, 
depending on the socket capacity. Also messages can be queued until the 
previous messages have been fully written.



What could happen is that if you have a slow reader on the other side, 
then the socket will not be able to accept any data, because it gets full.





  


org.apache.mina.core.session.IoSession.write(Object)

  


We see that there is time difference of 10-14 seconds between timestamp of 
session.write for particular message and messageSent event getting generated 
for the same message.



So you have a problem in the middle. Check that the reader (ie the other 
server) is processing messages fast enough. Or maybe you have network 
issues, as suggests Jonathan.





  


In non-peak load this time difference is in 10-15 milliseconds and in peak load 
(60-70 messages per second) it goes till 10-14 seconds.



60/70 msg/s is not exceptionally high, except if you are managing big 
messages, or do a lot of processing on each message.




-
To unsubscribe, e-mail: users-unsubscr...@mina.apache.org
For additional commands, e-mail: users-h...@mina.apache.org

Re: MINA: ExecutorFilter on NioSocketConnector

[Emmanuel Lécharny]

On 09/04/2020 15:00, Jonathan Valliere wrote:

The ExecutorFilter only works for the Server receiver side.



Actually, it could be used on the client side too, but it makes little 
sense, as the client is not supposed to receive heavy load from the 
server (of course, there might be use cases where it's happening, but 
it's not frequent).




-
To unsubscribe, e-mail: users-unsubscr...@mina.apache.org
For additional commands, e-mail: users-h...@mina.apache.org

Re: How to get status on transferred files?

[Emmanuel Lécharny]

Happy new year !

On 01/01/2020 18:31, Itzhaki, Guy wrote:

Happy new year team!

I wrote a client (using MINA) that sends files. For that purpose I implemented a 
filter that extends AbstractStreamWriteFilter.
I would like to display the user a real time progress means how many bytes were 
transferred (% of the file size).
My question is, what is the best way of doing that? Is there a built in filter 
I can use or should I implement my own filter? Something else?



You should be able to use the LoggingFilter.messageSent() event to trace 
what is done. OTOH, it only pushes information in a log. You can reuse 
this class and push the info on stdout, I guess.



What I'm not sure about is if the messageSent event is generated for 
each piece of the file being written fully. If it's not the case, then 
you are in trouble because you don't have access to the internal flush 
in AbstractPollingIoProcessor.IoProcessor...



So I would say: give LoggingFilter a try at first.

Hope it helps.


Emmanuel


-
To unsubscribe, e-mail: users-unsubscr...@mina.apache.org
For additional commands, e-mail: users-h...@mina.apache.org

Re: Vysper status?

[Emmanuel Lécharny]

Hi Reda,

the PR has been pushed into the code base.


And, yes, if you wish to revive the project, I'm absolutely +1 for that !


On 24/07/2019 23:26, Réda Housni Alaoui wrote:

Hello,

Here, trying to revive it for 3 days and still counting.
I am still hoping to receive at least a message about
https://github.com/xsf/xmpp.org/pull/592

:)



-
To unsubscribe, e-mail: users-unsubscr...@mina.apache.org
For additional commands, e-mail: users-h...@mina.apache.org

Re: Handling MQTT messages using apache mina library is possible?

[Emmanuel Lécharny]

On 22/07/2019 11:17, Dhananjay Kandari wrote:

Hi,
Is it possible to use apache mina library to handle MQTT messages?



Sure. MQTT is based on TCP/IP, so MINA will be able to process incoming 
and outgoing messages.


However, you will have to implement the MQTT protocol codec.


-
To unsubscribe, e-mail: users-unsubscr...@mina.apache.org
For additional commands, e-mail: users-h...@mina.apache.org

Re: Creating a UDP Broadcast via MINA

[Emmanuel Lécharny]

For some historical reasons MINA does not yet support Multicast.

https://mina.apache.org/mina-project/faq.html#does-mina-support-multicast

This is something we should seriously reconsider nowadays.

On 03/07/2019 15:06, Alex Buechel wrote:

Hello guys,

I want to create a UDP Broadcast program, which send every x seconds a
specific message through a specific UDP-port through the network. For me
UDP is a connectionless protocol, so i should be able to send message
without waiting for an incoming client. This server shouldnt care if any
client has received any message.

I have created a StackOverFlow message (incl a minimal example) here:
https://stackoverflow.com/questions/56834550/udp-broadcaster-via-mina-framework

Is it possible that somebody can take a look to my problem?

Thanks in advance
Alexander Büchel



-
To unsubscribe, e-mail: users-unsubscr...@mina.apache.org
For additional commands, e-mail: users-h...@mina.apache.org

Re: High CPU Utilization because of Mina-core jar

[Emmanuel Lécharny]

On 24/05/2019 15:57, Hrushikesh Agrawal wrote:

Thank Guus. Do you know the expected date the 2.1.3 would be available? I
wanted to try with this jar as well.



Hi,


I was going to cut a release this week-end. This is quite a critical 
issue, and a quick release does not hurt.


Emmanuel

Re: Does mina-core-2.0.7.jar supported by JAva 11 or not

[Emmanuel Lécharny]

On 20/05/2019 10:38, Ravi Verma wrote:

Hi,

We are using mina-core-2.0.7.jar for one of our product.
We need confirmation on - Does above jar supported with JDK 11.



Mina 2.0.7 is 6,5 years old. Two things:

- we haven't yet tested the latest MINA version with Java 11 (this is 
something we should do and will do)


- you certainly have to migrate to a recent version of MINA, tens of 
critical bugs have been fixed since 2.0.7 (the latest version is 
2.0.21and 2.1.2)

Re: NioSocketAcceptor grabbing a number of ports when instantiated

[Emmanuel Lécharny]

On 17/05/2019 16:04, Phil Hudson wrote:


Hi All,

I have 2 questions about the way NioSocketAcceptor allocates and uses 
ports.


Background

We are using a 3^rd party product (QuickFix/J) for client/server 
communication, which in turn uses


MINA for network communication.  For server side communication, 
QuickFix/J is instantiating a


NioSocketAcceptor for listening on a specified port.  We recently 
noticed an issue where a large number


of additional ports are also being allocated when a NioSocketAcceptor 
is instantiated.    We seem to


see around 10 ‘pairs’ of ports allocated (20 total) with each 
instantiation.   As you can see in the sample


below, they seem to be in pairs, where they talk to each other. ??

  Proto  Local Address  Foreign Address    State   PID

  TCP    127.0.0.1:55686 MYSYS:55687 ESTABLISHED 24976

  TCP    127.0.0.1:55687 MYSYS:55686 ESTABLISHED 24976

  TCP    127.0.0.1:55688 MYSYS:55689    ESTABLISHED 24976

  TCP    127.0.0.1:55689 MYSYS:55688    ESTABLISHED 24976

  …

Note that the actual port being listened on is a different port 
altogether… example: port 6073


I have searched for why this is occurring, but can’t find any 
documentation on it.


Questions

1) Why do 20 ports get allocated when a NioSocketAcceptor is instantiated?

1a) What is it using these ports for?



No idea. It all depends on the application using MINA.

2) Is there a way to control this?   (or control the range it 
allocates from?)




You have to ask the QuickFix/J fellows.

MINA is just a framework, it does what you tell it to do...

Quickly browsing their documentation, it seems they allow users to set a 
failover mechanism, by which they start more than one acceptor:


https://www.quickfixj.org/usermanual/2.1.0/usage/acceptor_failover.html

but that might be unrelated. Just ask QuickFix/J people, they are the 
ones who know :-)



And thanks them for using MINA ;-)

Re: IoFilter mark() usage, between 2.0 and 2.1

[Emmanuel Lécharny]

On 04/05/2019 05:40, David Trott wrote:

Hey Jonathan,

I am transitively importing version 2.0.19 of mina-core through the
sshd-core dependency (as I don't think it is safe to upgrade mina-core to
2.1 as I am using the sshd project).

I started with the 2.1 version of the SshFilter as a template for the
filter I am working on, as such it took some time to find the extra .mark()
call which was present in the older version of the SslFilter.

I am afraid my error handling/testing still needs some work, so all I can
really say at the moment is that with the .mark() call in place the code
appears to function correctly, however if the .mark() call is removed the
code fails - specifically I only receive one packet then receive no further
packets - again this is code compiled against mina-core 2.0.


With respect to your specific points:

  1> Some things aren't being back-ported to 2.0.X,
   the SSL improvements are one.

I don't think this issue is specific to Ssl, I think it affects any filter
that processes IoBuffers in the 2.0 code base (note: my test sample here is
one project). Also note I do not use reset() anywhere in my code and the
only mark() call I make is in a similar location to the one in the
SslFilter.


FTR, the changes made in 2.1 where related to the way the messages were 
propagated down the chain after a session.write(). The idea is that each 
filter should never change the incoming data, which was not the case 
when it was a IoBuffer. In order for the messageSent() event to be 
properly handled in 2.0, we were forced to somehow mark it to remember 
where it started.


In 2.1, we have greatly simplified the messageSent() even processing, 
keeping a copy of the initial message and never touching it. We also 
limited the  number of function calls (that should show in the stack 
calls)).


In any case, that made the 2.0 and 2.1 incompatible. Also note that in 
2.0, you weren't able to use the compressionFilter in conjonction with 
the SslFilter, somthing the changes in 2.1 allow you to do.

Re: StreamIoHandler. sessionClosed

[Emmanuel Lécharny]

On 10/02/2019 11:59, Vikram Darsi wrote:

Hi Team

Need small information about the callback StreamIoHandler. sessionClosed?

Will this get invoked only when the remote node terminates/closes the session?


Either when the remote peer closes the session, or if the server can't 
write in the socket for any reasons (likely because the socket has been 
closed), or because your application has closed the session.





We observed sometimes this method is invoked on the tcp server side, even when 
the remote end
has not terminated explicitly

Using Apache Mina Core 2.0.9



You should urgenntly lmigrate to a recent version. 2.0.9 is almost 5 
years old, many bugs have been fixed since then !

Re: How MINA works with lot of socket connections?

[Emmanuel Lécharny]

Hi,

On 19/12/2018 16:28, Krishan Babbar wrote:

Dear All,

I am working on an IoT project. I have created a Java application using MINA 
library. All the devices are connecting to this Java application using TCP 
protocol.



So far, so good.



I have created simulator (to simulate devices) to do our load testing. In 
simulator I have given limit of 3000 threads in thread pool so that one 
instance of simulator can connect 3000 devices at once.



which means your simulator will try to connect 3000 times almost 
simultaneously to your app...



I tried testing for 3 devices by executing 5 instances of simulators in 
parallel.


Well, that's 5 * 3000 = 15 000, not 30 000. Anyway, that is 15000/3 
simultaneous connections for your app, unless you do some ramp up




Each device was sending messages after interval of 30 seconds and I had 10 
messages per device.



Again, that's 15000/3 messages sent simultaneously to your app, 
every 10 seconds.



But my Java Application did not receive all the messages in one go, it is 
processing messages very slow.



It kind of makes sense... First of all, I do think you should try to 
determinate what is the maximum number of connections and messages per 
second your app can support. That mean ramping up the threads up to the 
moment you start losing messages/connections. Your approach is brutal, 
it will not allow you to understand what's going on.





Suppose 5 simulators have sent (3000 devices/threads per instance * 5 instances 
* 5 mins) 15 messages in 5 minutes but Java Application (with MINA) has 
processed about 1 messages only.
And even after sometime my Java Application was closed due to memory issue.

Please help and guide how MINA is working in case of lot of devices/sockets 
connection?



It works pretty much as it does when having few connections/messages.

But I would distinguish between connections and message. A connection 
will be handled by a thread processing the ACCEPT event. MINA allocates 
one single acceptor and N+1 IoProcessor, where N is the number of core 
you have on your server (unless you specified an explicit number).


Which means if all your clients are trying to connect at the very same 
time, your acceptor will be quite overloaded... It's very likely that 
some connection will simply be dropped.




Where is MINA storing messages which are yet to process?


It doesn't. MINA just process messages it was capable of reading from 
the active sockets (ie the sockets for which it has been signaled there 
is some data waiting to be read, or that the socket is ready to be 
written). Each of those messages are processed sequentially, as we only 
use a limited number of threads for that (9 on a 2 CPU quad cores 
machine). If you have 30 000 active sockets at a given time, and 
assuming processing one message takes 10ms, then your server will only 
be capable of absorbing 9 * 100 messages per second (on a 2 CPU quad 
cores machine), ie it will take 33s to process all of them. You can 
immediately see that your scenario where the 30 000 threads are sending 
a message every 10 s will simply not fly.


There are two solutions here :

- pour more CPU/cores on your machine (increasing the number of 
IoProcessor threads above the default lilmit does not make sense, unless 
your app is waiting for most of the 10ms - which ios likely anyway if 
your app is waiting for, say, a remote database response)


- speed up the processing of one message. If it takes 10ms of processing 
(ie, one CPU/core is at 100% during the whole time it takes to process 
your message, the '10ms' I took as an example, for instance, then you 
are pretty much screwed. Fall back to workaround 1, or scale up your 
solution by spreading your app on more than 1 machine...






With 16 GB RAM Linux machine, and giving 4 GB and 6 GB as a heap parameters in 
Java Application (java -Xms4096m -Xmx6144m -Dserver -jar Application.jar),  how 
many devices/sockets MINA library can handle?



No idea. It all depend on what you do when you process a message.



Is MINA using single thread to connect all devices and receive packets from 
them?

No. One Acceptor, as many IoProcessor as your have CPU*cores.

I mean is it possible to receive all messages immediately in my Request Handler?

Yes. But MINA won't be able to process all of them simultaneously.


Below is given my code for MINA configuration and from request handler we are 
starting a new thread for each message for processing.



What's the point in using a NIO framework if you are recreating a system 
where each message is processed by a thread ? This is utter nonsense.



Realize that a thread use 100% of a core resource when it's executing, 
so if you have 8 cores, you won't be able to execute more than 8 threads 
*simultaneously* ! The only leverage you have is the time it takes to 
process one message. It if takes 100ms of pure CPU usage, then your 8 
cores machine will not be able to handle more than 80 

Re: release 2.1.0 on maven central

[Emmanuel Lécharny]

Le 26/09/2018 à 23:50, Matthias Sohn a écrit :
> Hi,
> 
> according to [1] the latest release of org.apache.sshd is 2.1.0.
> When do you plan to deploy this version to maven central ?

The release vote is not closed yet.

-- 
Emmanuel Lecharny

Symas.com
directory.apache.org



pEpkey.asc
Description: application/pgp-keys

Re: current Apache MINA state.

[Emmanuel Lécharny]

Le 13/07/2018 à 03:30, Pablo Caballero a écrit :
> Hi Jonathan. Thanks a lot! I'll consider your suggestion.

Hi Pablo,

we are currently discussing about a change in the version naming scheme.

MINA 3 was started 5 years ago, and the latest release (3.0.0-M2) was
done 4 years ago, and it was a milestone. To be clear, it was an
experiment that never went to its end.

In the mean time, 12 releases of MINA 2 has been done (from 2.0.8 to the
current and recent 2.0.19 - 5 weeks ago -). That is 4 releases a year,
on average.

Now, 2.0 is a maintenance branch. That means we are committed to fix any
bugs that is discovered (and I must tell that it's quite incredible that
after all those years, we still find bugs in the code base! Well, oh
well, we have great users that reports them, and they are better than
we, the developpers ;-)

That being said, if you are using MINA 2.0.x, migration should not be an
issue (except that in 2.0.8 we introduced a minor change in the API [1])

If you are using MINA 1.x, please feel free to ask any question you may
have...


Thaks !


[1]
http://mina.apache.org/mina-project/index.html#mina-208-released-posted-on-september-22-2014

-- 
Emmanuel Lecharny

Symas.com
directory.apache.org



pEpkey.asc
Description: application/pgp-keys

Fwd: [ANNOUNCE] Apache MINA 2.0.18 released

[Emmanuel Lécharny]

The Apache MINA project is pleased to announce MINA 2.0.18 !

This version is a bug fix release.

Apache MINA (http://mina.apache.org) is a network application
framework which helps users develop high performance and high
scalability network applications easily by providing an abstract,
event-driven, asynchronous API over various transports such as TCP/IP
and UDP/IP vis Java NIO.

The Apache MINA project website includes resources such as
introductory presentation slides, tutorials, and examples to help you
learn MINA as soon as possible.

There is nothing critical in this version, no big bug fixes, just a
few annoying ones. Although there is some important addition: The
IoHandler interface now expose a new method :

void event(IoSession session, FilterEvent event) throws Exception; This
can be used by any filter to generate a specific event (which will be
handled on demand by the application). Currently, the only added event
is defined in SslEvent, and it tells if the session has been secured (ie
the Handshake has completed) or isn't anymore. It changes one thing in
your application:
if you were implementing IoHandler, you have to implement this method.

You may also extends IoHandlerAdpater which has a void implementation of
this event() method. The few fixes bugs/added features are:
- Added a flag to tell the Handshake to start immediately or not
- The IoBufferHexDumper implementation now does not modify the IoBuffer
position
- Some missing synchronization have been added in the SslFilter - The
suspendRead call is handled for Datagrams, instead of throwing an exception

We recommend all users to upgrade to this release. We consider this a
stable and production ready release.

Downloads are available at http://mina.apache.org/downloads-mina.html


The Apache MINA PMC


Thanks !



-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com



pEpkey.asc
Description: application/pgp-keys

Re: Maven Plugin Issue FTP Server

[Emmanuel Lécharny]

(the attachement has been dropped. This is standard behaviour of the ASF
mail server)

Le 07/05/2018 à 18:49, Jonathan Valliere a écrit :
> I'm trying to make the security fix for the FTP server but I am seeing an
> issue when building the maven project.
> 
> apache-rat-plugin:0.12:check (5 errors)


Simply ignore those errors ('resolve later')

-- 
Emmanuel Lecharny

Symas.com
directory.apache.org



pEpkey.asc
Description: application/pgp-keys

Re: Apche Vysper

[Emmanuel Lécharny]

Hi,

Le 01/04/2018 à 22:49, David Colmenares a écrit :
> Hello, I would like to know if they will continue updating and / or
> improving Vysper ?


No, unless some volunteer to keep the project running.


, I think I will use it, and I wanted to know if it
> is a good idea, since I do not find an implementation that will adapt,
> and Vysper with what I have seen so far is adacta much to what I need,
> I wonder why they have been 5 years without getting into the code, if
> they know of an implementation that is similar, would be glad to
> notify me, or if they will continue with Vysper, I plan to use it in
> production, I had thought to use Openfire, but I have had many
> problems, the Vysper simple is what I liked.

Feel free to use it, it's open source. Don't expect fixes, beside the
one you are willing to provide. Eventually, if you fell like
participating to the effort, you wi-ould be very welcome.


-- 
Emmanuel Lecharny

Symas.com
directory.apache.org

Re: Detecting non-idle but non-active either sessions

[Emmanuel Lécharny]

Le 26/03/2018 à 01:55, Juan Palacios a écrit :
> Hi
> I was hoping I could get some support analysing a change I'd like to make
> to our MINA integration.
> 
> Our application limits the total number of sessions it will open
> concurrently to keep high load from hurting our performance.
> 
> However we've noticed recently that some of our users are configuring
> ControlPersist + KeepAlive settings for their clients. This keeps sessions
> alive for extended periods of time (we've seen sessions going for days).
> 
> I was wondering if there was a way of detecting sessions which are
> *only* producing
> keep alive traffic and terminating them after a certain period of time. The
> goal is to prevent these users from exhausting the pool of available
> sessions.

You can set a idle timeout that will trigger an event if a session is
idling for more than a given time, in IoSessionConfig :

/**
 * Sets idle time for the specified type of idleness in seconds.
 * @param status The status for which we want to set the idle time
(One of READER_IDLE,
 * WRITER_IDLE or BOTH_IDLE)
 * @param idleTime The time in second to set
 */
void setIdleTime(IdleStatus status, int idleTime);

Then the IoHandler interface has a method allowing you to manage an idle
session :

/**
 * Invoked with the related {@link IdleStatus} when a connection
becomes idle.
 * This method is not invoked if the transport type is UDP; it's a
known bug,
 * and will be fixed in 2.0.
 *
 * @param session The idling session
 * @param status The session's status
 * @throws Exception If we get an exception while processing the
idle event
 */
void sessionIdle(IoSession session, IdleStatus status) throws Exception;


This event is generated when a sessin is idling more than the configured
TIEMOUT you set in the config.

-- 
Emmanuel Lecharny

Symas.com
directory.apache.org

Re: The heartbeat task of client not support keepalive function well,is it a bug?

[Emmanuel Lécharny]

Please, don't cross-post.


Your question is a users question, not a dev one. There is no need to
post it to both the users and dev mailing list.


Thanks.


Le 28/10/2017 à 03:42, Mei a écrit :
>  
> The heartbeat task of client not support keepalive function well，is it a bug?
>
>
>
> The heartbeat request of sshClient is a SSH_MSG_GLOBAL_REQUEST, but 
> the default buffer of heartbeat set false (see 
> ClientConnectService#sendHeartbeat)
>
> buf.putBoolean(false);
>
> The sshServer reponse the heartbeat by the KeepAliveHandler, then 
> AbstractConnectionService #sendGlobalResponse.
>
>  boolean wantReply = buffer.getBoolean();
>
>as the buffer of heartbeat set false, then the sendGlobalResponse will 
> not reponse sshClient because of the wantReply is false .(see 
> [AbstractConnectionService #globalRequest)
>
>   1 、Is it a Bug(set the heartbeat buffer false default)? how the 
> sshClient know the server is available when the server don't response.
>I have test it whth create a client with params (
>HEARTBEAT_INTERAL = 60
>IDLE_TIMEOUT = 300
>NIO_READ_TIMEOUT = 315)and a server, and the client will close 
> seesion after the NIO_READ_TIMEOUT.
>
>  2、If the client reach the NIO_READ_TIMEOUT, then thows a 
> InterruptedByTimeoutException,and close the session.But the task of heratbeat 
> not stoped, it willcontinue to run even though it will not send 
> packet.See the ClientConnectionService #startHeartBeat
>
>
> service.scheduleAtFixedRate(this::sendHeartBeat, interval, interval, 
> TimeUnit.MILLISECONDS);
>
>
> if the sshClient reopen a new session and close it many times,the 
> number of invalid scheduling heartbeat  task will become very large, it's not 
>  equitable.
>
>
>
>
>
>
> 
>
>
>
>
> 【网易自营|30天无忧退货】仅售同款价1/4！MUJI制造商“2017秋冬舒适家居拖鞋系列”限时仅34.9元>>  

-- 
Emmanuel Lecharny

Symas.com
directory.apache.org

Re: MINA3.0 recommended

[Emmanuel Lécharny]

Le 18/08/2017 à 15:54, Jonathan Valliere a écrit :
> I don't have the code in front of me, but are you saying that the
> modification of the Write Queue is no longer concurrent?  Possibly the
> Write Queue is a concurrent data structure and the synchronize mechanism is
> no longer required.  It seems odd that someone would remove concurrency
> from that critical section.

Please check the answer on teh dev@mina.a.o mailing list.

-- 
Emmanuel Lecharny

Symas.com
directory.apache.org

Re: MINA3.0 recommended

[Emmanuel Lécharny]

Replying on dev@mina.a.o. Thanks to avoid cross posting in the future :-)


Le 18/08/2017 à 05:41, 胡阳 a écrit :
> Hi guys:
>  I read the source code of MINA3.0M2. The style of the code is very 
> good, the structure is clear, the design is concise and efficient, especially 
> the use of Selector is unexpected. However, the enqueueWriteRequest method 
> and the processWrite method in the AbstractNioSession are somewhat flawed.
> I see the source code in the enqueueWriteRequest method was originally 
> "synchronized (writeQueue)", but was commented out, personal speculation may 
> be the author feel that this treatment will affect performance.
> My approach is to use CAS to ensure memory visibility and atomic, see I see 
> the startSync, finishSync method, feeling that this may be more secure after 
> some of the performance will not lose too much.
> A little personal humble opinion.

-- 
Emmanuel Lecharny

Symas.com
directory.apache.org

Re: how to use two Apache Mina ProtocolCodecFilters

[Emmanuel Lécharny]

Hi Martin,


sorry, I overlooked your mail, and replied too quickly (ie, before my
morning coffee)... I thought you were talking about both sides (client
*and* server).


So et's go back to your initial question :

Actually, the ProtocolcodecFilter just get IoBuffer as an input :


public void messageReceived(NextFilter nextFilter, IoSession
session, Object message) throws Exception {
LOGGER.debug("Processing a MESSAGE_RECEIVED for session {}",
session.getId());

if (!(message instanceof IoBuffer)) {
nextFilter.messageReceived(session, message);
return;
}

which means if you have already decoded your message and produced a data
structure that is not stored in a IOBuffer, the second instance wont be
called.


So if your WebSocket codec does more than extract data and put them in a
IoBuffer, then yes, your binary codec won't be called. In this case, you
have little choice but designing a Filter that mimic the
ProtocolCodecFilter, but with a different messageReceived() method that
does not pass the message to the next filter.


You can also implement both codec in one single filter, but it's a bit
more ugly, mixing concepts...


Hope it helps !



Le 13/07/2017 à 10:33, Martin Asenov a écrit :
> hi, Emmanuel,
> I don't really understand your proposal. The code I posted is just on the
> server side. The client is Unity-based game.
> How do I actually rearrange things to achieve that?
>
> Thanks,
>
> On 13 July 2017 at 07:33, Emmanuel Lécharny <elecha...@gmail.com> wrote:
>
>>
>> Le 12/07/2017 à 20:00, Martin Asenov a écrit :
>>> When creating my Mina Server, I specify this:
>>>
>>> this.acceptor = new NioSocketAcceptor();
>>>
>>> this.acceptor.getFilterChain().addLast("logger", new
>> LoggingFilter());
>>> this.acceptor.getFilterChain().addLast("webSocketCodec", new
>>> ProtocolCodecFilter(new WebSocketCodecFactory()));
>>> this.acceptor.getFilterChain().addLast("binaryCodec", new
>>> ProtocolCodecFilter(new DefaultCodecFactory()));
>>>
>>> The webSocketCodec is one that handles WebSocket handshake stuff. The
>>> binaryCodec is the one that parses custom binary protocol messages.
>>>
>>> In this setup, I expect the following:
>>>
>>> client sends data -> webSocketCodec.encode -> binaryCodec.encode
>>> server writes data -> binaryCodec.encode -> webSocketCodec.encode
>>>
>>> Unfortunately, only the first step of each flow is called. What am I
>> doing
>>> wrong? Can't I use to Protocol Codec Filters after each other?
>> You can, but you have to add the codecs in the rigth order : on the
>> server side, the binary codec has to be stacked *before* the
>> websocketcodec.O the client, it's the opposite.
>>
>> --
>> Emmanuel Lecharny
>>
>> Symas.com
>> directory.apache.org
>>

-- 
Emmanuel Lecharny

Symas.com
directory.apache.org

Re: 1.5.0 missing in maven central

[Emmanuel Lécharny]

Le 08/06/2017 à 13:29, Oleg Nenashev a écrit :
> I would guess it is about SSHD. It is discussed here:
> http://www.mail-archive.com/users@mina.apache.org/msg06510.html . So 1.5.0
> is burned due to the license issue.

Yes, I was suspecting that.

Regarding 1.5.0, Guillaume stated that the license issue might not be
annoying, being optional. If so - but it needs to be double checked -,
the 1.5.0 vote can be rebooted (ie, no need for another vote, it's
enough for me to switch from a -1 to a +1).


-- 
Emmanuel Lecharny

Symas.com
directory.apache.org

Re: 1.5.0 missing in maven central

[Emmanuel Lécharny]

1.5.0 of what ?


Are you sure you have sent your message to the right mailing list ?


Le 08/06/2017 à 11:23, Stefan Magnus Landrø a écrit :
> Hi guys,
>
> It seems like 1.5.0 is missing in maven central. Any chance it might get
> uploaded in near future?
>
> Cheers,
>
> Stefan
>

-- 
Emmanuel Lecharny

Symas.com
directory.apache.org

Re: non-TLS configuration

[Emmanuel Lécharny]

Le 03/06/2017 à 11:39, gunnar gustavsson a écrit :
> Hi,
>
> I'm looking to use apache vysper in a project of mine. I've been looking at
> is for a while to NOT use TLS so I may easier understand what is sent over
> the wire.
>
> The default spring configuration for it states a bnch of bogus TLS config,
> is the intention of those to NOT actually use TLS under the hood (even
> though they point to certificate files)?
>
> Would be great to know. Thanks in advance.
> //gg

Hi,

the Vysper project is currently dormant, so don't expect a lot of
support for it. In other words, you are pretty much on your own...

-- 
Emmanuel Lecharny

Symas.com
directory.apache.org

Re: Regarding the SSHD 1.5.0 Release ETA

[Emmanuel Lécharny]

Le 11/05/2017 à 09:45, Oleg Nenashev a écrit :
> Hello,
>
> Thanks for the response! Looking forward to get a decision.
>
> I would probably wait till the Jigsaw mess gets resolved somehow ;)

You mean, 2027 ?

-- 
Emmanuel Lecharny

Symas.com
directory.apache.org

Re: re : Server Crash

[Emmanuel Lécharny]

Le 27/04/2017 à 14:43, Jon V. a écrit :
> I retract my previous statement after pulling the source for
> CircularQueue.  Guess I'm used to doing illegal things in Java I forget
> that most code isn't like that.

We ruled out the use of Unsafe in MINA a long time ago...

-- 
Emmanuel Lecharny

Symas.com
directory.apache.org

re : Server Crash

[Emmanuel Lécharny]

Hi !


seems like I have hard time moderating your message to the users
mailinglist... Never mind. here is a copy :


> We have a standalone application. It crashed suddenly. The log contains a
> class which is found in mina-core jar file. I have attached the crash
> report. Please let me know if you could find out any root cause for the
> crash. Thank you. server_crash_report.txt
>
  

First of all, this is a JVM crash, not a MINA crash The fact that the crash 
occurred while the exacution was in a mina call is incidental.

I would strongly to switch to a more recent version of Java, the one you use is 
quite antiquated and not supported anymore (4 years old, the last supported 
Java 6 version from Oracle, which has issued 16 released for Java 6).

Java 8 is the current version, Java 7 has been EOLed 2 years ago. 


-- 
Emmanuel Lecharny

Symas.com
directory.apache.org

Re: [ANNOUNCE] Apache FtpServer 1.1.1 released

[Emmanuel Lécharny]

Correction :


The provided link in teh announce is wrong It's

http://mina.apache.org/ftpserver-project/downloads.html


Thanks !



-- 
Emmanuel Lecharny

Symas.com
directory.apache.org

MIA for a while...

[Emmanuel Lécharny]

Hi !


just for you to know, I may be MIA for a while, or at least way less
responsive : My wife just gave birth to our wonderful daughter today,
and I'm afraid it's going to be our priority number one in the next few
weeks :-)


Thanks !

-- 
Emmanuel Lecharny

Symas.com
directory.apache.org

Re: a mina ssl bug

[Emmanuel Lécharny]

Hi,


until recently, Android implementation of SSLEngine was problematic.
That may be why you had issues with Android 4.x versions, and not
anymore on Android 5.x...



Le 19/01/2017 à 10:05, 时无间 a écrit :
> I created an ssl android client with mina , the android version is 4.2 to 
> 4.4, i found a problem, ConnectFuture.awaitUninterruptibly () always in a 
> wait state, can not create session, but in android5.5 is no problem. This is 
> very likely mina ssl in android 4.xx.
> Thanks

-- 
Emmanuel Lecharny

Symas.com
directory.apache.org

Re: Azure and Mina

[Emmanuel Lécharny]

Hi,


comment inline...


Le 17/01/2017 à 21:21, Antonio Rodriges a écrit :
> Hi,
>
> I have a very specific question. I am not sure whether this question
> is Mina-related or more Azure-related but it has to do with the
> networking.
>
> I hope to get an advice where to dig into.
>
> I have used this Mina application quite long, now I am trying to
> migrate it into the cloud.
> I deploy Linux virtual machines in Azure (each has public IP but does
> this really matter?).
> They connect (using Mina) to a machine outside Azure that also has its
> own public IP. Usual thing:
>
> SocketConnector connector = new NioSocketConnector(numberOfConnectors);
> ConnectFuture connectFuture = connector.connect(new
> InetSocketAddress(remoteHost, remotePort));
> connectFuture.awaitUninterruptibly(connectTimeout);
>
> That Mina machine outside the Azure also runs Mina. Let's call it
> server machine.
> It accepts connections like this:
>
> NioSocketAcceptor acceptor = new NioSocketAcceptor(acceptor_threads);
> org.apache.mina.core.buffer.IoBuffer.setUseDirectBuffer(false);
> acceptor.getSessionConfig().setTcpNoDelay(true);
> acceptor.setReuseAddress(true);
> acceptor.getSessionConfig().setSendBufferSize(buffer_size);
> acceptor.getSessionConfig().setMinReadBufferSize(64000);
> acceptor.getSessionConfig().setReceiveBufferSize(buffer_size);
> acceptor.getSessionConfig().setIdleTime(IdleStatus.BOTH_IDLE, iddle_time);
> acceptor.getFilterChain().addLast("codec", new
> ProtocolCodecFilter(CodecFactory.getInstance()));
> acceptor.setDefaultLocalAddress(new InetSocketAddress(port));
>
> When Azure applications connect to server machine, server saves
> IoSession session
> to asynchronously push messages back in future like this:
> session.write(message);
>
>
> This worked inside a local network (without Azure), but in current
> deployment server sends message
>
> 2017-01-17/15:45:19.823/GMT-00:00 [nioEventLoopGroup-3-3] [...] DEBUG
> Sending message to /13.94.143.139:41790
>
> and an Azure machine does not receive anything. Moreover, after a
> while I get this exception on server machine:
>
> 2017-01-17/16:01:11.419/GMT-00:00 [NioProcessor-4] [...] ERROR
> Exception in IOHandlerConnection timed out
> java.io.IOException: Connection timed out
> at sun.nio.ch.FileDispatcherImpl.read0(Native Method)
> at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:39)
> at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:223)
> at sun.nio.ch.IOUtil.read(IOUtil.java:197)
> at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:380)
> at 
> org.apache.mina.transport.socket.nio.NioProcessor.read(NioProcessor.java:280)
> at 
> org.apache.mina.transport.socket.nio.NioProcessor.read(NioProcessor.java:44)
> at 
> org.apache.mina.core.polling.AbstractPollingIoProcessor.read(AbstractPollingIoProcessor.java:695)
> at 
> org.apache.mina.core.polling.AbstractPollingIoProcessor.process(AbstractPollingIoProcessor.java:668)
> at 
> org.apache.mina.core.polling.AbstractPollingIoProcessor.process(AbstractPollingIoProcessor.java:657)
> at 
> org.apache.mina.core.polling.AbstractPollingIoProcessor.access$600(AbstractPollingIoProcessor.java:68)
> at 
> org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.run(AbstractPollingIoProcessor.java:1141)
> at 
> org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:64)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
>
> 2017-01-17/16:01:11.424/GMT-00:00 [NioProcessor-3] [...] DEBUG sessionClosed
>
> I wonder what reasons may prevent traveling messages from server to
> client machines? (the first message from clients to server did come)
> I hope that above information may contain a clue.

It's clearly a rooting issue. MINA is certainly not the cause of your issue.

-- 
Emmanuel Lecharny

Symas.com
directory.apache.org

Re: Mina stop work cause by exception in OrderedThreadPoolExecutor.Worker.run()

[Emmanuel Lécharny]

Sorry, still stuck with day job :/  Will try to squeeze one hour out of
my busy schedule to review your explaination.


I also have to do a small experiment to reproduce the issue.


Thanks for your patience !


Le 17/01/2017 à 05:32, Xu Congyuan a écrit :
> Dear all, Hope you are doing well.
>
> Please kindly advise if the problem I found is on processing. Any
> informations , please feel free to let me know.
>
>
>
> 2017-01-13 9:12 GMT+08:00 Xu Congyuan <xcongy...@gmail.com>:
>
>> Thanks for reply. Sorry for not clear it.
>> Basically, we will get the number of idleWorkers 0 or more than 0,
>> if idleWorkers = 0, that's meaning no work is idle, we should add workers
>> if it's necessary;
>> if idleWorkers > 0 , that's meaning there are idle works, no necessary to
>> add workers.
>> Do I get the point?
>> Let's back to the original,  while the MINA starting. At this time, the
>> num of idleWorker == 0, therefor we call addWorkerIfNecessary() method when
>> task is coming, because of idleWorker == 0,  we do addWorker and increase
>> the num of idle at line 259 (version 2.0.16). so idleWorker == 1 at this
>> time, the first worker be fired and start running, we enter the infinite
>> loop, and decrease the num of idleWorker to 0 at line 686(version 2.0.16),
>> basically that's we expected, but there is exception throw by runTasks(),
>> the finally code is executed at line 707,  and increase the idleWorker to 1
>> again, the infinite 'for' loop drop out because we don't catch the
>> exception, the outer try...finally code executed at line 712 removed the
>> worker.
>> Let's sort out ideas, by now,  the idleWorker == 1 and there is no worker
>> is running, is right? so the mina fall into fake dead.
>>
>> Please let me know I did the right investigation.
>>
>>
>> 2017-01-13 0:11 GMT+08:00 Emmanuel Lécharny <elecha...@gmail.com>:
>>
>>> Hi !
>>>
>>>
>>> sorry for the delayed response, was busy...
>>>
>>>
>>> I'm not sure I understand : if you get an exception in the runTasks()
>>> call, the 'finally' code is executed, and the number of idle worker is
>>> incremented, no matter what...
>>>
>>>
>>> Can you check that ?
>>>
>>> --
>>>
>>> Emmanuel Lecharny
>>>
>>> Symas.com
>>> directory.apache.org
>>>
>>>

-- 
Emmanuel Lecharny

Symas.com
directory.apache.org

Re: Mina stop work cause by exception in OrderedThreadPoolExecutor.Worker.run()

[Emmanuel Lécharny]

Le 17/01/2017 à 05:32, Xu Congyuan a écrit :
> Dear all, Hope you are doing well.
>
> Please kindly advise if the problem I found is on processing. Any
> informations , please feel free to let me know.

Sorry, was busy.. I will reply today.

-- 
Emmanuel Lecharny

Symas.com
directory.apache.org

Re: Mina stop work cause by exception in OrderedThreadPoolExecutor.Worker.run()

[Emmanuel Lécharny]

Hi !


sorry for the delayed response, was busy...


I'm not sure I understand : if you get an exception in the runTasks()
call, the 'finally' code is executed, and the number of idle worker is
incremented, no matter what...


Can you check that ?

-- 

Emmanuel Lecharny

Symas.com
directory.apache.org

Re: DEAD LOCK: IoFuture.await() was invoked from an I/O processor thread

[Emmanuel Lécharny]

Le 26/12/2016 à 23:53, Richards Peter a écrit :
> Hi,
>
> Thank you for sharing your thoughts regarding this issue. I am using Mina
> to develop a TCP client-server program. I experienced a similar issue while
> I was trying to perform the following operation:
>
> I would like to shutdown the NioSocketAcceptor instance when it receives a
> special message from a client (admin client). Upon receiving the message I
> would like the program to notify all the active IoSessions about the server
> shutdown by broadcasting a SHUTDOWN message and then dispose the
> NioSocketAcceptor instance. I would like to dispose the acceptor instance
> only after the message has been sent successfully.
>
> messageReceived(){
>- write SHUTDOWN message to all managed ioSessions , wait for the write
> operation to complete.
>- close the ioSessions and wait for the close operation to complete.
>- unbind and dispose the acceptor.
> }
>
> What would be the recommended approach to perform this type of a task?

This is not simple.

You need to call session.getService() to get the service instance, and
cast it to IoAcceptor.

Then you can iterate on all the existing sessions. The
IoService.getManagedSessions() will return the map of all the existing
sessions for this service.

Having all the sessions, you can set an Attribute for each of them, and
close the session. The sessionClosed() method in your IoHandler must
check if the Attribute is set, and act accordingly.

At the end, you can dispose the acceptor.

Something like that...

>
> How can I prevent the IO processor thread from DEAD LOCK? Could you also
> explain about the threading model that is recommended in this case? Can
> ExecutorFilter be used to solve this type of problem?

Simply exit the messageReceived() method, settig a current status in the
session context, and manage the idling. Every second, your session will
be waken up (IoHandler.sessionIdle()) and you'll be able to check the
other's session status. Doing so release the IoProcessor that was
processing your admin command, leaving it for other sessions associated
with the IoProcessor.

Again, this is not simple, and this is how I would implement it. But
there may be other ways...

-- 
Emmanuel Lecharny

Symas.com
directory.apache.org

Re: Is there a maven snapshot reporitory for this projet

[Emmanuel Lécharny]

Le 28/11/16 à 12:42, Claude Warren a écrit :
> I get the following error:
>
> git clone http://git-wip-us.apache.org/repos/asf/mina-sshd.git sshd
> Initialized empty Git repository in /home/iei77703/git/sshd/.git/
> error: RPC failed; result=22, HTTP code = 405
Weirdo. It just works fine for me. Can you try with

git clone https://git-wip-us.apache.org/repos/asf/mina-sshd.git sshd 

?

-- 
Emmanuel Lecharny

Symas.com
directory.apache.org

Re: Is there a maven snapshot reporitory for this projet

[Emmanuel Lécharny]

Le 27/11/16 à 10:44, Claude Warren a écrit :
> I was looking for a maven snapshot repository for the sshd modules.  Is
> there one or do I have to build from source?

Building the project from source is as easy as doing :

$ git clone http://git-wip-us.apache.org/repos/asf/mina-sshd.git sshd
$ mvn clean install

It taes a couple of mins, all include, it only requires Java 7 and Maven
3.x.


-- 

Emmanuel Lecharny

Symas.com
directory.apache.org

Re: Thread "stealing" between sessions under high load breaks message order

[Emmanuel Lécharny]

Le 22/11/16 à 21:33, Guillermo Gonzalez a écrit :
> Hi,
>
> Just wanted to share an issue I'm facing for which I can't find any obvious
> solutions.
>
> I have a proxy based on MINA. It has both a NioSocketAcceptor and a
> NioSocketConnector (both TCP). The flow is as follows:
>
> 1. Users arrive through the Acceptor
> 2. Their messages are processed by a filter chain and modified slightly
> (takes 5 - 10 millseconds)
> 3. The messages are forwarded to their destination through the Connector.
>
> The Connector session for a user is created immediately after the
> Acceptor's (with very high probability, the Connector's sessionId = the
> Acceptor's sessionId + 1)
>
> I use the default constructor for both Acceptor and Connector. If I've read
> the source correctly, this means that each of them has a
> SimpleIoProcessorPool as their processor. This pool creates as many threads
> as CPUs you have + 1 and assigns one of these threads to each session. The
> thread a new session gets depends on a calculation done on its sessionId.
Actually, it's a round-robin algorithm, from teh top of my head (ie, if
you have 3 IoProcessor, sessions will be attributed to thread 1, then 
2, then 3, then 1, then...)
>
> Under normal load everything works as expected. The logs show clearly that
> NioProcessor-1 (an example for the thread assigned to the Acceptor's
> session) is always the one processing every message from the user, and
> NioProcessor-2 from the Connector's session does the same with every
> response. Message order is maintained.
>
> However, when activity picks up on the Acceptor's side and messages should
> start queuing up, the Connector's session's processor will "switch sides"
> and start processing messages from the user. NioProcessor-1 and
> NioProcessor-2 will share the load, with the inevitable consequence that at
> some point the message order will be lost.

What seems to happen is that the incoming messages for a specific
session, processed by a specific thread (and thsi thread might process
many sessions), might be associated with a connector that is itself
managing many sessions. If you don't manage to keep a relation between
the incoming messages and teh outging messages, yes, teh whole system
might be fooled.

Did you have a look at the ProxyConnector class ?

Also I *strongly* suggest you switch to Mina 2.0.16. Mina 2.0.2 is 6
years old !

-- 
Emmanuel Lecharny

Symas.com
directory.apache.org

Re: ProtocolEncoder not getting used in the response path

[Emmanuel Lécharny]

Le 25/10/16 à 16:54, Murty Devarakonda a écrit :
> We could identify what the problem is at last.  While sending the response
> back to the client, we created a IoBuffer and added the bytes to the same
> and did a session.write().  And we identified that if the response is of
> type IoBuffer, Mina filter chain won't act on invoke the filters based on
> this line:
>
> ProtocolCodecFilter:filterWrite():
>
> // Bypass the encoding if the message is contained in a IoBuffer,
> // as it has already been encoded before
> if ((message instanceof IoBuffer) || (message instanceof
> FileRegion)) {
> nextFilter.filterWrite(session, writeRequest);
> return;
> }
>
> Somehow I missed that check and was scrambling why the filter is not getting
> used.  May be it might be helpful for future developers if this is
> documented properly.

Glad to see that you have found the origin of your trouble :-)

Yes, we can add some documentation that says that using an IoBuffer or a
FileRehion will result in the encoder to not been call. That would be
teh smart thing to do...


Thanks for the feedback !

Re: ProtocolEncoder not getting used in the response path

[Emmanuel Lécharny]

Le 24/10/16 à 19:24, Murty Devarakonda a écrit :
> I did read that section to see where things may be going wrong and didn't see
> anything that's different than what we are doing.
>
> Now, to explain a bit about our project, so far the MINA server is listening
> on one port and protocol encoder and decoder seems to be working fine.
>
> Recently we changed this model so that our MINA server will start listening
> on two ports one for the old way or reading client requests and the new one
> for parsing the client data (using the protocol decoder and storing the same
> in the MINA session) before the client request is handed over to the MINA
> server.  
>
> In this new flow, I see that the ProtocolDecoder where I introduced the
> parsing of the client request to store few pieces of data in the MINA
> session is working fine.  And I could see that the request is successfully
> being processed and required response being generated. 
>
> The problem is, I don't see that the data that's getting written into the
> MINA write queue is being handed over to the ProtocolEncoder and the
> response reached the client successfully.
>
> One question to you is, is starting MINA to accept client connections on two
> ports wrong?  
No, it should work fine.

> So I don't think that's anything wrong after going through the
> MINA documentation.  So currently I have two of the independent:
>
> 1)  NioSocketAcceptors binding to two different ports
> 2) Two independent filter chains to support rules on the two different
> accepting ports
> 3) As part of the filters, two independent ProtocolCodecFactories that have
> their own ProtocolEncoder and ProtocolDecoder implementations.
>
> Do you think MINA server will not be able to process sessions that are bound
> to two different ports?

A session is created when a new client connect to the server. It's
unrelated to the fact they are bound to different port.

What is puzling is that the decoder is bing called, but not the encoder.
You should go through the codec filter when doing asession.write, but
again, I don't have yoru code under my eyes, so I can't teel you what
you are doing wrong...

-- 
Emmanuel Lecharny

Symas.com
directory.apache.org

Re: ProtocolEncoder not getting used in the response path

[Emmanuel Lécharny]

Le 24/10/16 à 20:59, Murty Devarakonda a écrit :
> Thank you for the tip.  I looked into the NioSocketSession.filterChain and I
> could see my protocolcodecfactory object there.  Here is how I am adding the
> filters:
>
> protected static void addFilters(Properties props, NioSocketAcceptor
> acceptor, ProtocolCodecFactory factory)
> {
> DefaultIoFilterChainBuilder chain = acceptor.getFilterChain();
> String threadCountStr = props.getProperty("threads");
> int threadCount = threadCountStr == null ? s_threadCount :
> Integer.parseInt(threadCountStr.trim());
> chain.addLast("protocol", new ProtocolCodecFilter(factory));
> if (threadCount > 0) {
> ExecutorFilter filter = new ExecutorFilter(0, threadCount,
> s_timeout, TimeUnit.SECONDS);
> chain.addLast("limiter", filter);
> }
> }
>
> The above method is being shared to create filter chains for the old port as
> well as new port.  Do you think the name "protocol" is causing some
> conflicts?  As the same name "protocol" is being used to add the code filter
> factory for both instances of the acceptors?

The 'protocol' name is not a problem at all.

Re: ProtocolEncoder not getting used in the response path

[Emmanuel Lécharny]

Le 24/10/16 à 19:12, Murty Devarakonda a écrit :
> Thanks for the reply.  I set the logging at the debug level for all the code
> in org.apache and didn't see any exceptions being thrown or any error
> messages.  I tried to debug the MINA code, but didn't get much clues from it
> in terms of any eye popping error flows.
The simplest way to debug MINA is, as suggested by Qingsong, is to put a
breakpoint in your IoHandler messageReceived() method, and step in where
you have a session.write(). You are going to step through some classes
that are just wrappers, but at some point, you should jump into your
encoder. If not, then that means your filter chain is not constructed
correctly.

You can check the session filterChain field, that contains the filter
list, to see if the codec filter is present.

Otherwise, without your code, it's hard to tell what is wrong...

Re: ProtocolEncoder not getting used in the response path

[Emmanuel Lécharny]

Le 23/10/16 à 19:45, Murty Devarakonda a écrit :
> I wrote a custom Protocol Encoder implementing the ProtocolEncoder interface
> and I am using MINA 2.0.5 version.
Mina 2.0.5 is 4 years old. 2.0.16 is currently being release, I strongly
suggest you switch to this version taht will be out next week.
>
> But during testing, I am observing that the IoSession.write() call is not
> hitting the ProtocolEncoder at all.  What could be the reason for this?  I
> followed the creation of the ProtocolCodecFactory class correctly and my
> ProtocolDecoder is working correctly on the request path.  I am able to
> store some attributes in the IoSession and am able to make use of them in my
> request processing code.  
>
> While sending back the response, I would like to see my breakpoint in the
> debug session reaching the ProtocolEncoder and make the appropriate changes
> to the response before writing out the response.  
>
> Here is how my filter chain code is looking like:
>
> protected static void addFilters(Properties props, NioSocketAcceptor
> acceptor, ProtocolCodecFactory factory)
> {
> DefaultIoFilterChainBuilder chain = acceptor.getFilterChain();
> String threadCountStr = props.getProperty("threads");
> int threadCount = threadCountStr == null ? s_threadCount :
> Integer.parseInt(threadCountStr.trim());
> chain.addLast("protocol", new ProtocolCodecFilter(factory));
> if (threadCount > 0) {
> ExecutorFilter filter = new ExecutorFilter(0, threadCount,
> s_timeout, TimeUnit.SECONDS);
> chain.addLast("limiter", filter);
> }
> }
>
> Any help with this would be greatly appreciated.  I even tried logging the
> MINA related log lines at the debug level to see if there is an exception
> during response flow within MINA.  But there is no exceptions too.
The piece of code that you show does not tell a lot.

Hav you followed the
http://mina.apache.org/mina-project/userguide/ch9-codec-filter/ch9-codec-filter.html
page ?
>
>
>
> --
> View this message in context: 
> http://apache-mina.10907.n7.nabble.com/ProtocolEncoder-not-getting-used-in-the-response-path-tp51558.html
> Sent from the Apache MINA User Forum mailing list archive at Nabble.com.

-- 
Emmanuel Lecharny

Symas.com
directory.apache.org

Re: Address already in use when restarting server

[Emmanuel Lécharny]

Le 19/10/16 à 11:27, Michał Gałuszka a écrit :
> Dear MINA users.
>
> I’m using MINA server acceptor in my Java application that needs to be 
> restarted from time to time.
> When I stop and start that application „too fast” I always get an exception 
> when starting and trying to bind:
>
> java.io.IOException: Error while binding on 0.0.0.0/0.0.0.0:8245
> original message : Address already in use
>
> It must mean that I’m not closing all connections correctly upon application 
> termination.
> I have tried many things but nothing helped.
>
> When terminating application I’m closing all sessions (most often there is 
> only one session open), wait for the session to close gracefully and then I 
> fire 
>
> acceptor.dispose(true);
>
> I’m not calling acceptor.unbind() because it is already called inside 
> dispose(). Right?
>
> After few minutes I can always start my application and then
> acceptor.bind(new InetSocketAddress(port));
> will work correctly not throwing any Exception.
This is inherent to the way TCP works. You can have a look at
http://hea-www.harvard.edu/~fine/Tech/addrinuse.html.

You can try to setup the SO_REUSEADRESS flag to mitigate the problem,
using the setReuseAddress( true ) method on your service.

Re: Apache Mina sharing sessions in UDP

[Emmanuel Lécharny]

Le 28/09/16 à 15:15, rafrl a écrit :
> Dears,
>
> I have a problem using apache mina UDP server. I receive two connections are
> two sources with different ip but leaving the same port. The mina it is not
> creat a new sessions for each connection and is differentiating sessions and
> mixing the defined attributes. Someone passed a similar problem ?
No. Sessions are created on the fly when we get a new message, based on
the remote address :

private IoSession newSessionWithoutLock(SocketAddress remoteAddress,
SocketAddress localAddress) throws Exception {
DatagramChannel handle = boundHandles.get(localAddress);

if (handle == null) {
throw new IllegalArgumentException("Unknown local address: "
+ localAddress);
}

IoSession session;

synchronized (sessionRecycler) {
session = sessionRecycler.recycle(remoteAddress);

if (session != null) {
return session;
}

// If a new session needs to be created.
NioSession newSession = newSession(this, handle, remoteAddress);
getSessionRecycler().put(newSession);
session = newSession;
}
...

You probably have something wrong in your code, or you are using an
antiquated version of mina.

Re: verbose logs in mina 2.0.13

[Emmanuel Lécharny]

Le 20/09/16 à 19:55, Guy Itzhaki a écrit :
> Hi all,
> I've upgraded mina from 2.0.9 to 2.0.13 and since then I keep getting this 
> entry  in the log
> 20/09/16 20:20:00 WARN  [NioProcessor-2] IoProcessor - Create a new selector. 
> Selected is 0, delta = 0
>
> Is it a code left over or on purpose?

Yes, and it's a Warning, so you can get rid of it by setting the log
level to ERROR.

Now, if you switch to 2.0.14 which has been released 2 weeks ago, the
issue will be less frequent (actually, it should not happen at all),
because we have fixed a bug in this area (beside other few annying bugs).

I would also wait one more week, when 2.0.15 will be out, as it fixes
some other serious issue.


Side note : this log is dumped because there is a bug in NIO, that makes
the select() method returns immediately even if there is no active
selectionKey, leading in some very specific use cases to an infinite
loop, eating 100% of your CPU. In this case, we simply delete the
Selector and recreate a new one registring all the selectionKeys to this
new Selector. Pretty technical...

Re: Ensure sequential execution

[Emmanuel Lécharny]

Le 16/08/16 à 11:15, Simo Chiegang, Boris Arthur a écrit :
> I guys, I have the following Problem:
>
>
> -  I defined a Server to handle some Json Strings.
>
> Acceptor a = new NioSocketAcceptor();
>
>
>
> -  I had some filters so:
>
> a.getFilterChain().clear(); // I removed all filters
>
> a.getFilterChain().addLast("jsonString", new ProtocolCodecFilter(...));
>
> a.setHandler(myHandler);
>
> I want to know, if in my case the newer event is not processed if the event 
> handler method for the older event for the same session hasn't returned yet?

Not sure I understand...

Let me try to give an answer that might fit your question :

as soon as one session is created, and as soon as you don't have an
executor in the chian, then any message send by the client will be
processed in the exact order it has been sent. Ie, if a client sends 2
messages A and B, they will be preocessed in teh same order, A then B.
> Or I always need an Executor Filter?
No, you rarely need an executor filter.
>
> In my requirement, I don't need parallel processing. I must wait that the 
> event handler complete executes before start to handle the new event.

That is what will happen, always.

Re: issue with broken stream data

[Emmanuel Lécharny]

Le 14/07/16 à 10:47, Alexander Christian a écrit :
> Continued the search. Had a intensive look at my encoder class
> de.root1.simon.codec.base.AbstractMessageEncoder.
>
> You recommended checking the buffer and to ensure it is cleared... The
> used buffer is created every time from scratch. So it's a new buffer,
> everytime.
>
> I observed the buffer which is beeing sent. Looks like the data which
> is sent is always okay.
>
> On receiving side (exception complains about decoding...) it seems
> that the begin of a message is somewhen not correctly determined, but
> only if
>
> a) cpu ist fast enough (I'm not able to reproduce it on my rather slow
> home server (AMD 2x1,6Ghz)
> b) logging does not slow down too much
>
> The "no appropriate message decoder" message show a big amount of
> bytes. When analyzing them, it seems that it contains multiple
> messages, but beginning somewhere in the middle of a message.
>
> Feels like I'm getting closer.

The decoder wil try to decode as many messages as there ae in the buffer
(ie, you ay have more than one message in the read buffer - and of
course you can have less than one message, but in this case, the
isDecodable() will return false, and the buffer will be completed later -.

For every read, the decoder will try to decode a message, and if it
succeed, a messageReceived event will be propagated up to the IoHandler.
It will then iterate until it can't decode a message, processing the
buffer forward. At some point, the decoder can prefectly be in the
middle of the buffer, but still at the correct position, ie at the
beginnig of a second message. Here, this seems not to be the case.

Re: issue with broken stream data

[Emmanuel Lécharny]

Le 13/07/16 à 15:04, Alexander Christian a écrit :
> I tried to convert the bytes from the broken message to string:
>
>
> 00 -> ??
> 00 -> ??
> 00 -> ??
> 02 -> ??
> 00 -> ??
> 00 -> ??
> 00 -> ??
> 36 -> 6
> AC -> ¬
> ED -> í



This is clearly some serialized java class. I also looked at the buffer,
and I saw the class names in it.

Nothing bad here.

Re: Query about TLS compression

[Emmanuel Lécharny]

Le 12/07/16 à 16:36, Ashwini Mandhare a écrit :
> Thanks Emmanuel for quick response.
>
> Yes We are trying to achieve same thing by using Bouncy castle API along with 
> mina. We are unable to integrate that. Could u help us with some sample code 
> how to go about it.

Basically, what you need to do folds into two parts :
- reimplement the handshake protocol
- deal with the encyrption/decryption of the data flow once the HS is
completed (and also deal with teh SSL renegotiation).

I'm pretty sur BC is already handling both part correctly, but in a
syncrhone context (ie, in a blocking mode). I would have to check what
BC has to offer in a non-blocking mode.

In order to do that, the best would be to create a new Filter, which
will handle the HS part and the encryption/decryption part. Most of it
will be done in the messageReceived() method (which deals with incoming
bytes) and filterWrite() method (for the outgoing data).

Note that the SslFilter (which might be a good start if you want to have
a look at how we process data with the JRE SslEngine) is fairly complex,
and delegates most of the work to a SslHandler. I'm not sure that is
necessarily teh best idea to follow teh same architecture. Sadly one
would expect that the SslHandler class would be a perfect facade,
masking the complexity of the SSL processing, but no, it's not that
easy, because we expose and use teh SSLContext class, which is a JSSE
class. That also mean you will have to deal with the Filter
initialization. (see
http://comments.gmane.org/gmane.comp.encryption.bouncy-castle.devel/12708,
for instance)

In any case, would you be successful in implementing TLS with
compression on top of MINA, we would really appreciate a contribution of
such a code to the project !

Thanks !

Re: Query about TLS compression

[Emmanuel Lécharny]

Le 12/07/16 à 12:31, Ashwini Mandhare a écrit :
> Hi,
>
> We have a use case where we want to support TLS  compression. In one of the 
> client that we use , TLS compression is done on the protocol level . So 
> unless both the sides advertise compression when doing the TLS handshake, it 
> will not do compression.
> We have our TCP server implementation using Apace mina. We have following 
> questions regarding this
>
> 1.   Is there a provision/ API that we can advertise the compression 
> method used during the handshake from the server side in Mina implementation ?
>
> 2.   We tried to use the Bouncy castle library to advertise compression 
> during handshake however finding it difficult to integrate mina and bouncy 
> castle. Can we integrate this library in the Apache mina  TLS server 
> implementation?
>
> 3.   Could you please provide any code sample to do so.
>
> Please suggest.

AFAICT, this is not supported by Java JSSE, whcih is internally used by
MINA.

I'm afraid you have to implement your own SSL handling on top of MINA.