Re: Normal CPU? -- DOMINO400

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