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@aklaver.com
