[
https://issues.apache.org/jira/browse/DIRMINA-1173?focusedWorklogId=918946&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-918946
]
ASF GitHub Bot logged work on DIRMINA-1173:
-------------------------------------------
Author: ASF GitHub Bot
Created on: 11/May/24 22:02
Start Date: 11/May/24 22:02
Worklog Time Spent: 10m
Work Description: elecharny commented on code in PR #44:
URL: https://github.com/apache/mina/pull/44#discussion_r1597513323
##########
mina-core/src/main/java/org/apache/mina/transport/socket/DefaultSocketSessionConfig.java:
##########
@@ -37,7 +37,7 @@ public class DefaultSocketSessionConfig extends
AbstractSocketSessionConfig {
private static final int DEFAULT_SO_LINGER = -1;
- private static final boolean DEFAULT_TCP_NO_DELAY = false;
+ private static final boolean DEFAULT_TCP_NO_DELAY = true; // Disable Nagle
algorithm by default
Review Comment:
Not arguing here, I will revert but...
I do think that this flag should be opt-in, ie the Nagle algorithm should be
disabled by default. The use cases were it's useful are not really the most
frequent, and the drawbacks are numerous. If the default sendBuffer size is
set to 64Ko, then you have a delayed for every packet that has a lower number
of bytes to transfert. if you set the sendBuffer size to a lower value, then
you are sending way more packet than needed. In any case, if you are to send
some data that span on more than one packet, and the last packet is not
completed, then you'll pay a 200ms delay every time. Not very cool.
With Gigabits connections, sending a lot of packets is not really an issue
anymore, except on heavily loaded applications that aren't interactive (HTTP
may enter into this category, but with REST application, I would argue that an
immediate sending is a plus).
Regarding LDAP, requests are small there is no interest in differing the
packet sendings, so yes, I'm likely to deactivate the Nagle Algorithm.
Seems like on Linux they have added the TCP_CORK parameter to let the sender
decide when to send the data, bypassing the Nagle's algorithm completely, and
also solving the context switching pb at the same time (somehow it's a way to
say "you're responsability, not teh OS one", and I tend to agree). Sadly, this
is not portable, so currently it's not an option.
Last, not least, for TLS HS, Nagle's Algorithm is delaying the whole
negociation, which is a real PITA...
Issue Time Tracking
-------------------
Worklog Id: (was: 918946)
Time Spent: 1h (was: 50m)
> Apache mina 2.2.1 threads blocking on ConnectFuture.awaitUninterruptibly()
> for ever
> -----------------------------------------------------------------------------------
>
> Key: DIRMINA-1173
> URL: https://issues.apache.org/jira/browse/DIRMINA-1173
> Project: MINA
> Issue Type: Bug
> Components: Core
> Affects Versions: 2.2.1
> Reporter: KMVS
> Priority: Critical
> Attachments: dumpLatest-1.log
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> Hi All,
> I have attached thread dump too for analysis.
> 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.I am using the same NioSocketConnector across the threads.
> Here is an scenario, I have one gate way IP which i connect initially ,this
> gate way will return list of ips.
> now i will close the previous IOsession and will create a nio connection with
> the first ip in the list.if it did n't work then again i will try to
> connect to next ip etc..
> All these are in the critical section. i.e i will acquire a lock and then
> after successful connection i will release the lock.
> But problem i have noticed is with the awaitUninterruptibly().
> I have a state machine too. So connection set up is in one thread and
> response processing is in another thread.
>
> *Thread 1:*
> Public class g10CaptureService
> {
>
> private static final ProtocolCodecFilter probeCodecFilter = new
> ProtocolCodecFilter(new ProbeCodecFactory(G10Message.class));
> *private static final ExecutorFilter executorFilter = new
> ExecutorFilter(16,32);*
> private static final G10GPBMessageIoFilter gpbMessageFilter = new
> G10GPBMessageIoFilter(G10ParserContextFactory.getG10ParsingAndEncodingInstance());
> static
> {
> initConnectors()
> }
> protected static void initConnectors()
> {
> 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);
>
>
> //Global connector across the system, i.e multiple threads uses the same
> connector.
> 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);
> }
>
> public void StartRecordCapture()
> {
> connectionLock.lock();
> try
> {
> ConnectFuture primaryConnectFuture = connector.connect(primaryAddress,
> initializer);
> //hungs forever if the no. of threads are more than 30
> primaryConnectFuture.awaitUninterruptibly();//no time out 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;
> }
> }catch(Exception e)
> {
> }finally
> {
> connectionLock.unLock();
> }
> }
> *Thread 2:*
> public void processGatewaySrQueryResponseSuccess(G10StateContext context,
> IoSession session, GatewaySrQueryResponse response) {
> //get the g10CaptureService from the Thread1 IOsession
> if(response.getIpPortCount() > 0) {
> try {
> List<IpAddrPort> msgIpPorts = response.getIpPortList();
> List<InetSocketAddress> probeIpPorts = new
> ArrayList<InetSocketAddress>();
> for (IpAddrPort ipp : msgIpPorts) {
> InetSocketAddress inetSockAddr = new
> InetSocketAddress(InetAddress.getByAddress(ipp.getIp().toByteArray()),
> ipp.getPort());
> probeIpPorts.add(inetSockAddr);
> }
> g10CaptureService.setProbeIps(probeIpPorts);
> } catch (Exception ex) {
> LOG.error("{} Exception occured while creating probe
> IP/Port.Exception:{}", getLogStr(session), ex);
> }
> context.addGeoBladeGwSession(session);
>
> g10CaptureService.closeConnectionForSession(session); //cose thread1
> io session
> g10CaptureService.setIsGeoBladeIdlSession(true);
> g10CaptureService.startRecordCapture(searchExpression,
> captureHandler, captureId); //connect to the probe again using
> same thread 1 instance with different ip
> }
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
