Highlighted
Anonymous_User Absent Member.
Absent Member.
865 views

TCP Read Error & reasonable resources

I've recently done a multi-site upgrade from GW7 to GW8, and
unfortunately only at the same time turned on the config to have senders
get "delayed" status messages (in the past, they only got the
complete-failure notification.) So I'd have to dig *way* back in logs
to know if I have a problem or not ....

We're receiving more-than-usual, since "usual" in the past was "none",
TCP Read Errors with sending delays. I interpret this as either not
enough threads allocated for sending, or possibly an error on the part
of the ISP in how many connections we can make concurrently (as the GW
docs say that if multiple messages are being processed concurrently,
each uses one connection ... and then we are going through the same
gateway as all the internet users in the office.)

The level is in the range of 30 TCP status (delayed) messages for
perhaps 2000 sent. But it still makes people gripe. They gripe if they
don't know messages are delayed, and they gripe when they do know. They
even gripe when a message is bounced by someone *else's* server because
they've tacked on some humongous attachment and the recipient's server
doesn't allow attachments that large. They're a pretty gripe-y bunch
when it comes to email, in fact, because they have to send large
attachments all the time & they almost always (incorrectly) think the
error is on the sending side ... because, as y'all know, the status info
comes from the sender's server. [I have had to repeat, at least 20
times in past weeks including office-wide emails, that there is no
outbound filtering or size limit imposed.]

Which is to say: do I have a problem at this level of delay? Can I fix
it by allocating more threads? Should I be checking into how many
connections the ISP allows? Should I take it as good fortune that the
level is that low? As far as my users are concerned, 1.5% delayed is
too much!

This is on a Netware 6.5 SP8 server, 4GB memory, dual Xeon, nice & fast,
not doing anything of significance except the various components of
Groupwise and, of course, the tape backup and UPS agents. (Whew, that
UPS agent tends to suck up resources, but that's another gripe altogether.)

Recommendations?

Thanks.

-- DE
Labels (2)
0 Likes
2 Replies
Anonymous_User Absent Member.
Absent Member.

Re: TCP Read Error & reasonable resources

DE,

It appears that in the past few days you have not received a response to your
posting. That concerns us, and has triggered this automated reply.

Has your problem been resolved? If not, you might try one of the following options:

- Visit http://support.novell.com and search the knowledgebase and/or check all
the other self support options and support programs available.
- You could also try posting your message again. Make sure it is posted in the
correct newsgroup. (http://forums.novell.com)

Be sure to read the forum FAQ about what to expect in the way of responses:
http://forums.novell.com/faq.php

If this is a reply to a duplicate posting, please ignore and accept our apologies
and rest assured we will issue a stern reprimand to our posting bot.

Good luck!

Your Novell Product Support Forums Team
http://support.novell.com/forums/

0 Likes
Knowledge Partner
Knowledge Partner

Re: TCP Read Error & reasonable resources

Hi,

DE wrote:
>
> Which is to say: do I have a problem at this level of delay?


Yes. +1% of al mails being delayed like this strongly points to a
problem.

> Can I fix
> it by allocating more threads?


No. A TCP read error occurs *during* the transfer of an email to the
next hop. At that point, all threads have been allocated and are
underway. A TCP read error is literally always a TCP/IP level problem,
except in some very rare cases where the receiving server simply dies
underway.

> Should I be checking into how many
> connections the ISP allows?


No.

> Should I take it as good fortune that the
> level is that low? As far as my users are concerned, 1.5% delayed is
> too much!


Your users are absolutely right.

>
> Recommendations?


If all else fails, run a LAN Trace, and wait for it to happen. The check
the trace why the TCP connection between your GWIA and the next SMTP
server failed.

CU,
--
Massimo Rosen
Novell Product Support Forum Sysop
No emails please!
http://www.cfc-it.de
CU,
--
Massimo Rosen
Micro Focus Knowledge Partner
No emails please!
http://www.cfc-it.de
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.