Re: Switch to Loom 1.0RC3
Does phoenix trunk supports hotdeploy/undeploy/reload of applications? Not sure about hotdeploy, but undeploy and reload are suported. Both can be achieved through the JMX interface. One caveat with James and our standard distribution is that, Phoenix is ran in a mode where it shuts-down when no applications are running, so unloading James shuts-down the Phoenix container. This can be circumvented by using the p (persist) option to phoenix. --Søren -- peter royal Thank you for your help, Stefano - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Søren Hilmer, M.Sc. RD manager Phone: +45 72 30 64 00 TietoEnator IT+ A/S Fax:+45 72 30 64 02 Ved Lunden 12 Direct: +45 72 30 64 57 DK-8230 Åbyhøj Email: soren.hilmer at tietoenator.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Commented: (JAMES-421) MailImpls sharing MimeMessage's!
IMHO the DEFAULT behaviour should be the deep copy. I disagree, what we're trying to do is to manage routing the message. Message can be routed down two different routes to its destination, but is still the same message. The default should be the least resource intensive. In fact I would tend to say that the issue is not technical, but one of documentation. The docs should clearly explain that and any changes should be made only to ensure that there is a simple and consistent method which can be used to branch the message itself. d. *** The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient (or responsible for delivery of the message to the intended recipient) please notify us immediately on 0141 306 2050 and delete the message from your computer. You may not copy or forward it or use or disclose its contents to any other person. As Internet communications are capable of data corruption Student Loans Company Limited does not accept any responsibility for changes made to this message after it was sent. For this reason it may be inappropriate to rely on advice or opinions contained in an e-mail without obtaining written confirmation of it. Neither Student Loans Company Limited or the sender accepts any liability or responsibility for viruses as it is your responsibility to scan attachments (if any). Opinions and views expressed in this e-mail are those of the sender and may not reflect the opinions and views of The Student Loans Company Limit ed. This footnote also confirms that this email message has been swept for the presence of computer viruses. ** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Commented: (JAMES-421) MailImpls sharing MimeMessage's!
IMHO the DEFAULT behaviour should be the deep copy.
I disagree, what we're trying to do is to manage routing the message.
Message can be routed down two different routes to its
destination, but is still the same message.
-1 on that!
James developers already did mistakes due to mimemessage shared and this bug
report is the proof.
Performance can be achieved with copyonwrite proxies or different approach
but we should avoid that mailet writer run a mail.duplicate() and without
the knowledge that it will share the mimemessage.
NOONE will ever understand that running a matcher in a processor will
duplicate the envelope but will share the mimemessage so if you change one
of the 2 mails you don't know wether you will receive 2 identical messages
or 2 different ones!
The default should be the least resource intensive.
The default should be the SAFEST. The unsafe optimization should be applied
understanding possible problems of the optimization.
As I already said we can achieve optimization later or in a different way
but first we should ensure that message handling is consistent and SAFE.
In fact I would tend to say that the issue is not technical,
but one of documentation. The docs should clearly explain
that and any changes should be made only to ensure that there
is a simple and consistent method which can be used to branch
the message itself.
Please reread the bug report and not only the subject.
The issue is REAL and is a critical BUG: if you think that MimeMessage
sharing is good then it is a bug in the LinearProcessor.
I don't care wether the message is shared or not, but the scenario I
submitted should not give that result.
The developer that wrote the LinearProcessor did not consider that the
MailImpl.duplicate was returning a new Mail with the same MimeMessage.
The developer that wrote the AbstractRedirect did the bugfree thing (clone
the mimemessage).
This is the easy code that should be documented to do the right thing:
newMail.setMessage(new MimeMessage(originalMail.getMessage()) {
protected void updateHeaders() throws MessagingException
{
if (getMessageID() == null) super.updateHeaders();
else {
modified = false;
}
}
});
IMHO adding a copyonwrite proxy over the MimeMessageWrapper we can remove
also the deepcopy in the abstractRedirect and achieve better performance
than now, btw I don't care how we decide to fix it. I just want it to be
fixed.
Stefano
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (JAMES-421) MailImpls sharing MimeMessages / LinearProcessor not cloning it after a partial match.
[ http://issues.apache.org/jira/browse/JAMES-421?page=all ] Stefano Bagnara updated JAMES-421: -- Summary: MailImpls sharing MimeMessages / LinearProcessor not cloning it after a partial match. (was: MailImpls sharing MimeMessage's!) MailImpls sharing MimeMessages / LinearProcessor not cloning it after a partial match. -- Key: JAMES-421 URL: http://issues.apache.org/jira/browse/JAMES-421 Project: James Type: Bug Components: James Core Versions: 2.3.0, 2.2.0 Reporter: Stefano Bagnara Assignee: Stefano Bagnara Priority: Critical Fix For: 2.3.0 Attachments: LinearProcessorTest.java LinearProcessor match a single recipient for a 2 recipient mail. it run MailImpl.duplicate. duplicate DOES NOT clone the MimeMessage. The following mailet will handle 2 different MailImpl sharing the same MimeMessage. Attached is the proving test. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: VirtualUserTable during SMTP transport
Out of interest, I have a custom build of James running in production that does exactly this. As I recall, I added a few lines to the doRCPT method of SMTPHandler.java to instantitate JDBCVirtualUserTable and reject the recipient if not found in the table. Bandwidth usage dropped significantly. Obviously, I'm hoping that the in-protocol handler being developed will remove the need for a custom build. Craig Noel J. Bergman wrote: One of the major problems for mail administrators these days is the incredibly high volume of dictionary attacks and spoofed sender addresses. I have seen that you can get into block lists simply for sending DSN responses. Therefore, I believe that we're going to need to support in-protocol virtual user table translation, so that we can NAK the address without needing to send a bounce. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Switch to Loom 1.0RC3
On 9/12/05, Soren Hilmer [EMAIL PROTECTED] wrote: Does phoenix trunk supports hotdeploy/undeploy/reload of applications? Not sure about hotdeploy, but undeploy and reload are suported. Both can be achieved through the JMX interface. One caveat with James and our standard distribution is that, Phoenix is ran in a mode where it shuts-down when no applications are running, so unloading James shuts-down the Phoenix container. This can be circumvented by using the p (persist) option to phoenix. Any downside to not incorporating that right now? Would this prevent a regular shutdown? -- Serge Knystautas Lokitech software . strategy . design http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
