Followed all instructions for setting up a "Shared Configuration". I have 2 MailEnable instances on 2 servers both pointing to a file share for their configurations, and subsequently both are using the same shared queue folders.
If I send email to the servers via the SMTP protocol, all is well.
I have been looking for a faster and also fault tolerant way of queuing my inbound messages and since my shares storage is already on a cluster, I thought I'd take a stab at using the drop folder.
Drop folder enabled on both servers on the General Tab of SMTP Setup. Both are pointing to the same \\fileshare\...\QUEUES\SMTP\Inbound\Drop location.
I get a ton of these error messages in my SMTP Debug log.
ME-I0074: Failed to find headers in drop folder message \\slfs\email\config\QUEUES\SMTP\Inbound\Drop\04d87bca-4935-4455-84ec-a10b7f6b0fd0.eml. Moving to failure folder.
I've narrowed it down to ME not playing nice in this shared configuration / shared environment.
If I turned off either of the servers and just let one process the inbound queue at any given time, it works fine. Any suggestions for how to make the 2 servers play nice when processing the inbound drop folder? Surely this wasn't an oversight in the shared configuration design? Everything else appears to have been properly accounted for, I'd hate to see this was overlooked as it would be a very nice solution to what I am trying to accomplish.
But, if both of my servers can't both be monitoring this folder, then I lose the "high availability" aspect of having 2 servers running at once and using the drop folder will no longer be an option.
SMTP Drop Folder - Failing to Find Headers Errors
Re: SMTP Drop Folder - Failing to Find Headers Errors
Assuming no one knows the answer to using a drop folder in a shared configuration environment, let's try from a different angle.
Does anyone know how to change the drop folder path since the SMTP properties dialog doesn't allow it to be changed?
Is there a registry entry that can be added to change the location of the drop folder?
When a system is setup using a shared configuration, all of the INBOUND and OUTBOUND queues are on shared storage and the drop folder, by default, appears to inherit this location which is completely unacceptable given that ME can't handle a shared drop folder.
This folder path needs to be changed if it is to work in a shared configuration.
Any suggestions? Ideas?
I know I can write directly into the INBOUND queue with a message and control file, and I've successfully coded this....but I'd prefer not to have to do that directly. There are a lot of reasons I don't want to do this which are specific to my environment that I won't bore you with. I can do it, I would just much prefer to use the drop folder option that's built in to ME to avoid a few complications on my end.
Though it doesn't appear it will work since I can't figure out how to change the drop folder to a local folder and get it off my share.
Does anyone know how to change the drop folder path since the SMTP properties dialog doesn't allow it to be changed?
Is there a registry entry that can be added to change the location of the drop folder?
When a system is setup using a shared configuration, all of the INBOUND and OUTBOUND queues are on shared storage and the drop folder, by default, appears to inherit this location which is completely unacceptable given that ME can't handle a shared drop folder.
This folder path needs to be changed if it is to work in a shared configuration.
Any suggestions? Ideas?
I know I can write directly into the INBOUND queue with a message and control file, and I've successfully coded this....but I'd prefer not to have to do that directly. There are a lot of reasons I don't want to do this which are specific to my environment that I won't bore you with. I can do it, I would just much prefer to use the drop folder option that's built in to ME to avoid a few complications on my end.
Though it doesn't appear it will work since I can't figure out how to change the drop folder to a local folder and get it off my share.
-
Brett Rowbotham
- Posts: 560
- Joined: Mon Nov 03, 2003 7:48 am
- Location: Cape Town
Re: SMTP Drop Folder - Failing to Find Headers Errors
ME Standard was more than likely not designed for a "shared" configuration, seeing as this is the free version.
What you are experiencing is two email servers that expect to be the sole provider of email services clashing with each other.
Why do you not use the Enterprise version with its support for a clustered environment ?
What you are experiencing is two email servers that expect to be the sole provider of email services clashing with each other.
Why do you not use the Enterprise version with its support for a clustered environment ?
Re: SMTP Drop Folder - Failing to Find Headers Errors
I've evaluated Enterprise and it suffers from the same issue. They are apparently the same code base.
Clustering is not the same as load balancing with a shared configuration. Cluster is only for high Availability. I'm going for high performance and high availability.
I finally decided to just go with writing the Message and Control file. My system sends out about 4000 emails in 15 minute intervals. By going this route and bypassing the SMTP protocol, I've cut my sends from 10-15 seconds down to 1-2 seconds. Of course, that's just the portion where it gets the messages into the inbound queue. ME still has to do the actual outbound send. But, in any event, this is a huge win for us.
I would have preferred to be able to just write one file to the drop folder, but writing 2 isn't that much more of an issue. It's all multi threaded and blasts thru the files rather quickly.
Clustering is not the same as load balancing with a shared configuration. Cluster is only for high Availability. I'm going for high performance and high availability.
I finally decided to just go with writing the Message and Control file. My system sends out about 4000 emails in 15 minute intervals. By going this route and bypassing the SMTP protocol, I've cut my sends from 10-15 seconds down to 1-2 seconds. Of course, that's just the portion where it gets the messages into the inbound queue. ME still has to do the actual outbound send. But, in any event, this is a huge win for us.
I would have preferred to be able to just write one file to the drop folder, but writing 2 isn't that much more of an issue. It's all multi threaded and blasts thru the files rather quickly.
