|
I'm no guru, but I like to dabble. I think something is wrong somewhere, but this might help: Change TCP/IP Attributes (CHGTCPA) TCP receive buffer size (TCPRCVBUF) - Help Specifies what to allocate for the default receive buffer size. The TCP receive window size is based on this value. Decreasing this value decreases the amount of data that the remote system can send before being read by the local application. Decreasing this value may improve performance in situations where many retransmissions occur due to the overrunning of a network adapter. I fear that the network trace could just be showing a symptom of the problem. The problem might be on the AS/400 side, something causing it not to receive the buffers and backing them up. It is apparently normal for the sender to "wait forever" after receiving a Zero Window, as long as the host continues to respond to "probes" from the sender. The AS/400's problem though could be something that is being sent in the data (or something totally unrelated) that causes the server to choke. Increasing the receive window may allow more data to be received and possibly buffer the entire e-mail, but that won't make the host process it (ala, "you can lead a horse to water but you can't make him drink"). ==================================== Tom Kreimer Information Alternatives Any iSeries IP gurus available? Analyzing the network capture for the latest problem message arriving on my server, the sending server (our mail filter) is sending three Message Body packets for every acknowledgement that Domino sends back. Eventually, the sending server sends a "TCP Window Full" followed by the receiving Domino server sending "TCP ZeroWindow" in return. After that, there are a high number of retransmit packets and ZeroWindow packets until the sending server finally gives up and disconnects. I presume that this corresponds to the period of time when my users cannot connect to the server. My understanding of these packets is that they essentially indicate that the Domino can't keep up with the flood of incoming packets, that the buffer is full. Since the older, slower server didn't seem to have this issue, I'm led to wonder if there is a configuration difference between the two servers. Is there a setting somewhere that would affect the TCP buffer? Grasping at straws waiting for IBM to call me back... Patrick "Patrick Trapp" <ptrapp@xxxxxxxxxxxx> Sent by: domino400-bounces+ptrapp=nex-tech.com@xxxxxxxxxxxx 02/10/2006 09:57 AM Please respond to Lotus Domino on the iSeries / AS400 <domino400@xxxxxxxxxxxx> To Lotus Domino on the iSeries / AS400 <domino400@xxxxxxxxxxxx> cc Subject Re: Normal CPU? Well, my server timeout issues are continuing to occur, but they've been pretty intermittent. A little experiment last night, however, may have given us something for IBM to gnaw on. We had noticed early on that every time one of these timeouts would occur, there would be an associated message that had experienced delivery issues. Analysis showed that those delivery issues were consistently a failure of the Domino server to respond to the sending server in a timely manner. The sending server (our mail filter) has a 90-second timeout. We have documented a few cases where the Domino server took over five minutes to return an ACK to the sending server, by which time the sending server had long given up. Last night, I took the text of one of these suspected problem messages and manually sent it to the Domino server via telnet. The intent was to see if we could get the server to timeout on demand. This was successful (or there was an amazing coincidence), so it definitely appears that there is something in the message itself that caused the problem. We have looked at many, many of these messages and have yet to find anything in common between them. Some were HTML messages, but the vast majority of them were text messages. In fact, messages from another mailing list I subscribe to have been the culprit on several occasions, and it doesn't support HTML of any kind. Does anyone have any ideas of what I should be looking for in the messages that might be causing this? Thanks, Patrick
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.