Messaging Server Basics: Defragmentation
By Joesciallo-Oracle on Jan 26, 2007
Let's face it, Sun Java System Messaging Server is a complex product. The MTA is a very powerful piece of code, enabling you to do all kinds of email routing/filtering/etc. I won't even pretend to understand it to the extent that I should.
What I can do, as a writer, though, is to try and pass along those aspects of the product, that, if we had the time, would make up the basics, those concepts that seem to come up regularly within our internal aliases and set of questions. One of those examples would be defragmentation.
The MTA in Messaging Server contains a feature that enables automatic defragmentation of messages or partial messages. What does this mean? To quote from the Messaging Server 6 2005Q4 Administration Guide:
"The MIME standard provides the message/partial content type for breaking up messages into smaller parts. This is useful when messages have to traverse networks with size limits, or traverse unreliable networks where message fragmentation can provide a form of “checkpointing,” allowing for less subsequent duplication of effort when network failures occur during message transfer. Information is included in each part so that the message can be automatically reassembled after it arrives at its destination."
You implement defragmentation by using the
defragment channel keyword and the defragmentation channel. Furthermore, the defragment channel only retains messages in the defragment channel queue only for a limited time. When one half of the time before the first nondelivery notice is sent has elapsed, the various parts of a message will be sent on without being reassembled. This choice of time value eliminates the possibility of a nondelivery notification being sent about a message in the defragment channel queue.
Okay, knowing all this, where does that leave us? Well, you might use the
imsimta qm > summarize command to look at what is happening with your MTA message queues, and you might observe that there are x number of messages queued up in the defragmentation channel. Furthermore, in diving into reading the defrag'd files, you see that there are actually y number more parts to the messages. Is this a problem, you begin to wonder, with the defragmentation channel?
The short answer is no. In fact, the MTA and the defragmentation channel are working normally. What has happened is that a message has been fragmented into y parts but you only have x parts in the defragmentation channel queue. Because y is greater than x, no matter what the specifics of the messages in the queue, there are not enough parts present for reassembly to be performed. This situation continues until either all the parts arrive or the time limit for reassembly (noted above) is reached, at which point the message fragments will be sent on unassembled.
A basic, best practice for defragmentation is also to put the
defragment keyword on a channel destined for
a third-party scanner box, since scanners might take the approach of rejecting all fragmented messages (if the scanner cannot assemble the fragments together itself).
I hope to do more of these Messaging Server "basics" pieces over time. Stay tuned for more.