Hi Thanks for the answer. Comments inline.
>Yes. The first delivery happens like the retries. >The only difference is that the first store "notify" a waiting thread >(if available) and this will start the delivery ASAP. Otherwise the >standard behaviour is polling. Yeah, this is what I understand by the comment in the code but I can't find how the store method notify the waiting threads to start the delivery. It's inside the spool objects or something? >In specific a MailImpl contains a MimeMessage, but again, you don't know >what kind of MimeMessage and in this case is probably a >MimeMessageCopyOnWriteProxy that wraps a MimeMessageWrapper. All of them >allocates resources. >Failing to call dispose will result in file descriptors leaks and/or >memory leaks. Understood. regards, Rafael Munoz Stefano Bagnara-2 wrote: > > rafael.munoz ha scritto: >> Hi >> >> I'm trying to refactor all the retry code from the RemoteDelivery mailtet >> (an idea I got from a recent mail from Stefano Bagnara) to a >> GenericRetryMailet easy to extend and use. >> >> To do that I 'm reading and trying to understand the RemoteDelivery code >> but >> I have some doubts and I hope someone can answer them: >> >> - There is a comment that says that the store of the mail on the spool >> triggers a inmediately delivery. How is this done? I can't find anything >> on >> the AvalonMailRepository/AvalonSpoolRepository that indicates how this is >> done ... It seems that the mail is only store in the spool and it will be >> deliver in the same way that the failed mails, when a spool thread read >> it >> and deliver it. >> CODE: >> //Set it to try to deliver (in a separate thread) >> immediately >> (triggered by storage) >> outgoing.store(mail); > > Yes. The first delivery happens like the retries. > The only difference is that the first store "notify" a waiting thread > (if available) and this will start the delivery ASAP. Otherwise the > standard behaviour is polling. > > > > >> - Someone can explain to me the ContainterUtil.dispose(mail) method? The >> dispose method sets the MimeMessage internal field of mail to null and >> call >> ContainerUtil.dispose(MimeMessage), but this second call has no sense, >> doesn't it? The dispose method only has sense with objects that >> implements >> Disposable and MimeMessage doesn't implements this interface. > > you don't know what "mail" is. > In our case mail is a MailImpl message. It requires to be disposed to > disallocate resources. > In specific a MailImpl contains a MimeMessage, but again, you don't know > what kind of MimeMessage and in this case is probably a > MimeMessageCopyOnWriteProxy that wraps a MimeMessageWrapper. All of them > allocates resources. > Failing to call dispose will result in file descriptors leaks and/or > memory leaks. > > Stefano > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- View this message in context: http://www.nabble.com/RemoteDelivery-mailet-questions-tp19088399p19089767.html Sent from the James - Users mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
