James Nichols a écrit :
Here is a purely hypothethical (and in practice unlikely) idea:
Java opens up too many sockets (more than you really request) and the
kernel, for whatever reason, does not deliver packets to programs
which have maxed out their fds. Well it would already help if the
java blob was split into multiple blobs (assuming the problem
persists), as the best testcase is the smallest possible one. So if
it is reproducable without the web blob, great step there.
Right, I don't disagree with you there. FWIW, I can disable entire
parts of the application and have already narrowed down reproduction
of this issue to the 200 threads that make the webservice calls, so it
doesn't have anything to do with any of the GUI or other background
services that my application executes.
You said:
Well you could still blame Java. I am sure that if you program was C,
the problem could be narrowed down much easier.
I'm curious to know how this problem would be easier to narrow down if
it were written in C.
Well... please dont start a flame war :(
Back to your SYN_SENT problem, I suppose the remote IP is known, so you
probably could post here the result of a tcdpump ?
tcpdump -p -n -s 1600 host IP_of_problematic_peer -c 500
Most probably remote peer received too many attempts from you, and a
anti DOS mechanism is droping all SYN packets.
Ah well... I remember now that you mentioned tcp_sack setting had an
effect, so forget the "Most probably..." and give some tcpdump traces :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
