On 12/20/24 07:02, Enrico Schenone wrote:
Hi, Adrian.
Today I have collected a tcpdump at client side with communications
between application server and db server while the issue was occurring
one time per second on another program.
I send you two files.
The first one is a zipped tarball (.tgz) containing a text
representation of the tcpdump starting at point where it reports the
declaration of the failing cursor ("cu4" as you can see in the first
line of the file) and subsequent fetch. Consider that the client
application log detected the XX001 error on the first FETCH of the
cursor at 2024-12-20 12:17:35.175
The second file (zipped tarball .tgz) is too big to be sent as
attachment, so I provide a link where it can be downloaded. It is the
fraction of tcpdump recorded during the program failure (occurred
several times). It is in .pcap format so it is possible to open it with
Wireshark or tcpdump -A -r
Anyone interested can download it at
https://cleislabs.cleistech.it/downloads/tcpdump_out009.pcap.tgz
Consider that during the dump several different cursor was declared with
the name "cu4", but the one failing is the one of the first line.
Maybe an expert (I'm not so expert) can see if the disconnection is
really made by the client and/or if the data returned by the server are
really corrupted as per XX001 SQLSTATE.
This is beyond me, someone else will need to chime in.
Best regards.
Enrico
Il 19/12/24 22:47, Adrian Klaver ha scritto:
--
Adrian Klaver
adrian.klaver@xxxxxxxxxxx
