Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1swZwf-004eCb-Oe for pgsql-general@arkaria.postgresql.org; Fri, 04 Oct 2024 04:29:38 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1swZwe-00A7dT-SH for pgsql-general@arkaria.postgresql.org; Fri, 04 Oct 2024 04:29:36 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1swZwe-00A7dK-Ef for pgsql-general@lists.postgresql.org; Fri, 04 Oct 2024 04:29:36 +0000 Received: from mail-yw1-x1132.google.com ([2607:f8b0:4864:20::1132]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1swZwc-002OWD-3E for pgsql-general@postgresql.org; Fri, 04 Oct 2024 04:29:35 +0000 Received: by mail-yw1-x1132.google.com with SMTP id 00721157ae682-6e21ac45b70so14711587b3.1 for ; Thu, 03 Oct 2024 21:29:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1728016172; x=1728620972; darn=postgresql.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=40jnephqhFNnSe1YVJTMmAzOMBkfisl/qxqbJRcc3Ks=; b=WOsLIrGn9TJD41WR+7TKk03Qs5PYKKRtBOgwf8BQxLPzMUizI6qf2e8eetYaIQgJ7g j2w8RIzV3zMU1zeHc1MzJhG6ZW/lgAiLbKPfGwBzOS+WobbMb0r4NmdZA39K/dCyesbP kJiLBuAPllLQeLg7iaYoJpMQ2xoYoufYKh6JTcfOVmSYWaYBp65mIkJc4fabRSjsZG0S Mtrx2zmP8QiW2XrHF4LTMj5fgFNO2LFRvT2deykDGSSDtI0apE7M9iDMNb3KaaseKu6X P7cK7sfTvlBaNxUFUALv+rjItGeXajPvQyo1HzZjAqdJwqo2GmWUSI0AqeeU5Q7G3ecR PaZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1728016172; x=1728620972; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=40jnephqhFNnSe1YVJTMmAzOMBkfisl/qxqbJRcc3Ks=; b=oz46CtzjJM3sdFgwghenfYRmhiXemZszLom0IfHY8c+mQ7wVAQ55KBDfx9ZlgumAA7 H9m1s/0zcCk1FJkPxfkDb3SyM9AZyC+lqsHRARzu42rpMuJEIOq1pZa9zcRrOrPWn/hd LaHHHfIX+xTwuaPgksXp63xQ7+CJfkNRNAssM/ZSs+pApI/w260KQAqxGVzrV/qbX9hb bIdhNY4zCPDa88CJjBSABiEaq9Px8n0h3JZeDuzobrPT5sD/0E3Ce76cfZIoOuwf82hz t/IGeUzeULbPF0SHIcy7z0VuKD/kXfLBIyk+QWBEMCCR7KF643vt/xEiFHb8O7QBVCyf luNw== X-Gm-Message-State: AOJu0Yy/cqqaJRCUTWyajENIZWVMyudLnNaTZFFBQ82ykYzpLtyAtp5h wA1/q2ZM4NHQewrwqVtjmuursiF0e57yUXAlxDGPrfRtk/LhU0XWZKk8ZZZtspYNVtP1e28DlIF SI6mA2VTXaH+Le/OgooyrW+DCGKvGEQ== X-Google-Smtp-Source: AGHT+IGH+9N4SmkOiEURP+jkycU8fodfrGLgkOiiYK8YswUpGH1t9prUftSq0R4+G5DgrgBFE4t+fTyl3+fwpLFq6bw= X-Received: by 2002:a05:690c:60c1:b0:6e2:1a41:ebe5 with SMTP id 00721157ae682-6e2c72b07d0mr14943167b3.41.1728016172520; Thu, 03 Oct 2024 21:29:32 -0700 (PDT) MIME-Version: 1.0 From: KK CHN Date: Fri, 4 Oct 2024 09:59:33 +0530 Message-ID: Subject: CLOSE_WAIT pileup and Application Timeout To: pgsql-general Content-Type: multipart/alternative; boundary="000000000000211e1606239f1e80" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000211e1606239f1e80 Content-Type: text/plain; charset="UTF-8" List, I am facing a network (TCP IP connection closing issue) . Running a mobile tablet application, Android application to update the status of vehicles fleet say around 1000 numbers installed with the app on each vehicle along with a vehicle tracking application server solution based on Java and Wildfly with PosrgreSQL16 backend. The mobile tablets are installed with the android based vehicle tracking app which updated every 30 seconds its location fitted inside the vehicle ( lat long coordinates) to the PostgreSQL DB through the java backend application to know the latest location of the vehicle and its movement which will be rendered in a map based front end. The vehicles on the field communicate via 443 to 8080 of the Wildfly (version 27 ) deployed with the vehicle tracking application developed with Java(version 17). * The mobile tablet communicates to the backend application over mobile data (4G/5G SIMS). * The running vehicles may disconnect or be unable to send the location data in between if the mobile data coverage is less or absent in a particular area where data coverage is nil or signal strength less. The server on which the backend application runs most often ( a week's time or so) shows connection timeout and is unable to serve tracking of the vehicles further. When we restart the Wildfly server the application returns to normal. again the issue repeats after a week or two. In the Server machine when this bottleneck occurs I am seeing a lot of TCP/IP CLOSE_WAIT ( 3000 to 5000 ) when the server backend becomes unresponsive. What is the root cause of this issue ? Is it due to the android application unable to send the CLOSE_WAIT ACK due to poor mobile data connectivity ? If so, how do people address this issue ? and what may be a fix ? Any directions / or reference material most welcome. Thank you, Krishane --000000000000211e1606239f1e80 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
List,

I am facing a=C2=A0 network (TCP = IP connection closing issue) .

Running a=C2=A0 mob= ile tablet application, Android application to update the status of vehicle= s fleet say around 1000 numbers installed with the app on each vehicle alon= g=C2=A0 with a=C2=A0 vehicle tracking=C2=A0 application server solution bas= ed on Java and Wildfly with=C2=A0 PosrgreSQL16=C2=A0backend.

=
The mobile tablets are installed with the android=C2=A0based veh= icle tracking=C2=A0app which updated every 30 seconds its location fitted i= nside the vehicle ( lat long coordinates) to the PostgreSQL DB through the = java=C2=A0 backend application to know the latest location of the vehicle a= nd its movement which will be rendered in a map based front end.=C2=A0

The vehicles on the field communicate=C2=A0 via 443 to= =C2=A0 =C2=A08080 of the Wildfly (version 27 ) deployed with the vehicle tr= acking application=C2=A0developed with Java(version 17).


=C2=A0 The mobile tablet communicates to the backe= nd application over mobile data (4G/5G SIMS).=C2=A0

The=C2=A0=C2=A0running vehicles may disconnect=C2=A0 or be unable to = send the location data in between if the mobile data coverage is less or ab= sent in a particular area where data coverage is nil or signal strength=C2= =A0less.=C2=A0

The server on which the backend app= lication runs most often (=C2=A0a week's time=C2=A0 or so) shows connec= tion timeout and is unable to serve tracking=C2=A0 of=C2=A0 the vehicles fu= rther.

When we restart the=C2=A0 Wildfly server=C2= =A0 the application returns to normal.=C2=A0 again the issue repeats=C2=A0 = after a week or two.=C2=A0

In the Server machine w= hen this bottleneck occurs=C2=A0 I am seeing=C2=A0 a lot of=C2=A0 TCP/IP CL= OSE_WAIT=C2=A0 =C2=A0( 3000 to 5000 ) when the server backend becomes unres= ponsive.=C2=A0

What is the root cause of this issu= e ?=C2=A0 =C2=A0Is it due to the android application unable to send the CLO= SE_WAIT ACK due to poor mobile data connectivity ?=C2=A0


=C2=A0If so, how do people=C2=A0 address this issue ?= =C2=A0 and what may be a fix ?=C2=A0=C2=A0

=C2=A0A= ny=C2=A0 directions / or reference material most welcome.=C2=A0
<= br>
Thank you,
Krishane





--000000000000211e1606239f1e80--