Hi Ben,
We have had the same issue for quite some time now (POST server coming
to a
crawl). There are 2 causes that we have identified:
1. Corrupt iMS index files - you can see if this is the cause by opening
your "Qeng20060605.log" log giles. If you see an error message related to
index, then you know your index is corrupt. You can resolve this by
stoppig
POST and then deleting the ims\out\database\Queue.IDX file. Next time
when
you restart POST, IMS will build the index file again.
2. Sometimes we see that RPS is hogging all the ColdFusion threads. We
use
FusionReactor to minitor the CF threads and we do find that when POST
is at
a crawl the number of CF threads that RPS is using has maxed out. Some
RPS
threads just sit there (we have seen RPS threads running for almost 30
minutes). Our RPS also just dups out an XML file and does nothing
else. Once
we kill these long running RPS threads, CF comes back to normal and
the POST
server also comes back. Sometimes, we have to restart CF and POST
comes back
to speed.
Hope this throws some light on the issue.
Let me know if the v 3.0 is any better. We are currently on v 2.8.1 r2.
Thanks
DK
-----Original Message-----
From: Ben Mueller [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 02, 2006 11:10 AM
To: inFusion Support List
Subject: [iMS] Severe memory problems with ReportPostStatus.cfm
Oops...opening post didn't take. Let's try this again...
We've had iMS installed and running as our primary mail software for
nearly
a year now, and are able to send out a very high volume of mail. We
use it
to send out large-scale mailings and handling bounces only--we do not use
POP, Relaying or Scheduling. By and large, it has performed very well
(after
several configuration headaches on my part).
However, there is one issue that, despite repeated efforts by me and
Howie,
I have not been able to resolve. Any time I have the ReportPostStatus.cfm
template enabled, the iMS POST engine will, after a few minutes of
processing post status, shoot up to nearly 100% CPU usage and will
*never*
let it go until I kill the POST thread in the task manager. The effect of
this is that mail delivery slows to a crawl, and the mail server
itself is
brought to its knees. My only recourse is to simply disable the RPS
template
altogether.
I have seen this behavior on two separate machines that share the same
configuration (detailed below). Howie has never seen nor heard of this
problem before, and so is at a total loss; and frankly, I'm pretty
sure he's
sick of hearing from me on this issue. But, I have found no solution
yet, so
I have to keep asking. (-;
I don't really care about getting notification for success or temporary
failure, but there is no other way to pull emails with bogus domains
(e.g.
[EMAIL PROTECTED]) from my recipient list other than invoking RPS and
parsing over the perm failed XML. So, my list is surely riddled with bad
domains.
I've had a number of theories as to why this might be happening,
including
the following:
* using application.cfm and application score variables in my iMS
templates.
Removing app.cfm and any application-scope variables has no effect
* Actually parsing XML in the RPS template. Initially, my RPS template
parsed out the XML, but now all it does is write out an XML file that
I then
parse later (full code below), so that's not the answer.
* bad version of POST engine. The jury's still out here, but I'm running
2.8.5, same as lots of other folks.
* Conflict between Norton AV on the mail server. I have Norton
configured to
completely ignore the entire iMS folder, so I don't think that's the
problem, either.
* Some software conflict between CFMX, iMS and Windows. I find this
hard to
believe, but I cannot rule it out. A complete data dump of what I'm
running
is below.
* Some kind of issue with the ISAPI connection between iMS and CFMX. I
don't
really understand how all of that works, but iMS is using the "wildcard"
connection, which is the only one that actually seems to work at all.
I continue to be completely stumped on this issue, so any help would be
greatly appreciated.
Thanks,
Ben Mueller
My RPS code:
<cfif len(form.permfailedlist) AND
isDefined("form.permFailedResponseList") AND findNoCase("No MX for
domain",form.permFailedResponseList) AND isDefined("form.tokenXml")>
<cffile action="write"
file="#mybasedirectory#permFailed_#createUUID()#.xml"
output=#form.tokenXml#>
</cfif>
Configuration Information
CFMX 7 (7,0,2,142559) -- older versions of CFMX 7 had the same issue Java
version 1.4.2_09 -- older Java versions had the same issue Windows Server
2003, SP1
PrismAV is installed and running (PrismAV enabled, ClamD disabled,
sandbox
disabled)
Complete iMS data dump:
inFusion SMTP Server version 2.8.4
inFusion POST Server version 2.8.5
inFusion POP Server version 2.8.4**
inFusion Scheduler version 2.8.4**
inFusion Relay Server version 2.8.4**
** unused
Support DLLs
CFX_BoogieBounce (CFX_BoogieBounce.dll) version 1.0
CFX_iMSMail (CFX_iMSMail.DLL) version 4.7
CFX_ODSMIME (CFX_ODSMIME.dll) version 2.9.1
CFX_ServiceControl (cfx_servicecontrol.dll) version 2.0
iMS COM Automation Object (iMSMail.dll) version 4.1
iMSMail_dotnetproxy.dll
version 4.1.0.0 iMSVScan.dll version 1, 1, 0, 0 MIME COM Automation
Object
(ODSMIME.dll) version 2.9.1 ODSMIME_dotnetproxy.dll version 1.0.0.0
Support
DLL (ODSSupport.dll) version 1.5
Software key is valid.
Licensed up to version 2.8
POST Server 255 threads
SMTP Server 100 threads
POP Server 100 threads
Antivirus option enabled
No PrismAS option
Subscription expires Feb 07, 2007
Support expires Mar 24, 2006
Support options:
Installation support
[Software\On-Line Data\inFusionMailServer\Common\] AdminEmail=postmaster
ISAPIExtension=.cfm CFTimeout=0
NameServers=199.231.150.176,199.231.150.177
RDNSTimeout=5
LogTimeStamp=mm/dd/yyyy hh:nn:ss ampm
[EMAIL PROTECTED]
AppSrvretries=0
AppSrvInterval=500
BMODelTimer=0
LogDirectory=D:\iMS\Logs\
TemplateDirectory=D:\iMS\Domains\
StatsDirectory=D:\iMS\Stats\
EnableStats=1
ShowTrayIcons=1
MaxLogSize=10024
[Software\On-Line Data\inFusionMailServer\Executive\]
RestartServices=1
LogArchiveDays=7
ArchiveRetentionDays=0
ArchiveFolder=D:\iMS\Archive\
ArchiveFrequency=2
[Software\On-Line Data\inFusionMailServer\POP\]
ServerPort=110
Timeout=600
MaxThreads=40
SkipUser=0
ReverseLookup=1
ProtocolLog=0
BoundIP
MaxAppServerConnects=0
StripCtrl=0
Strip8Bit=0
APOPAuthentication=0
MaxRemoteConnects=0
OrphanAction=0
PoolBufferPct=0
[Software\On-Line Data\inFusionMailServer\POST\]
MaxThreads=255
MaxDeliveryTime=12
DeliveryRetryTime=30
ProtocolLog=0
MXCacheEntries=5000
DNSServers=199.231.150.176,199.231.150.177
MXTimeout=30
OutDir=D:\iMS\Out\
MaxQueuedInRAM=0
PostOutDir
OutgoingServers
DefaultFromDomain=mydomain.com
POSTWarnTemplate=0
POSTFailTemplate=0
MxFromAddress=0
MxFromAddressFailAction=0
MultiFolder=1
MaxAppServerConnects=3
TerminateAbortTimer=0
SendingIP=216.248.192.67
AddTracking=0
InitialDeliveryWarningTime=-1
InitialDeliveryWarningType=0
[EMAIL PROTECTED]
StatsLog=0
StatsLogFmt=%rip %td - [%date]