Well, I looked at a bunch of my Queue log files, and found errors in none of them.

However, I did turn up something interesting. I have no idea if it's related to my issue, or even if it's wrong.

On the days when we send out a lot of mail, I'll have between 10 and 13 files named like this:

POST20060907.001
POST20060907.002
POST20060907.003
POST20060907.004

...and so on. They are all the identical size: 10,024 or 10,025 KB. What are these, and can they be safely deleted?

Thanks,
Ben

Ben Mueller wrote:
DK,

Thanks very much for your suggestions. It sounds like the first cause below might actually be a solution, whereas the second one sounds like a symptom. I'll certainly try option 1 and let you know how it goes.

Ben



On Nov 3, 2006, at Friday11/3/06, Dharmendar Kumar wrote:

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:

&ltcfif 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]
==^=======================================================
This list server is Powered by iMS  "The Swiss Army Knife of Mail Servers"
--------------------------------------------------------------------------------------
This list is provided as a free service.  Although we will try to address issues
in a timely manner, support via this list is not guaranteed.  If you require 
expedited
support then a support contract is required.  Support may be purchased from
http://www.coolfusion.com/commerce.  Details regarding support options may be 
reviewed
at: http://www.coolfusion.com/SupportOptions.cfm
--------------------------------------------------------------------------------------
To leave this list please complete the form at 
http://www.coolfusion.com/Support/
Need an iMS Developer license?  Sign up for a free license here:
http://www.coolfusion.com/Developers/
List archives: http://www.coolfusion.com/cfbb/
Note: You are subscribed as archive_jab_org / [email protected]
==^=======================================================


Reply via email to