[jira] Commented: (JAMES-414) Add more flexibility to LocalDelivery
[ http://issues.apache.org/jira/browse/JAMES-414?page=comments#action_12322582 ] Stefano Bagnara commented on JAMES-414: --- I ran a performance test to know how much userinbox caching improve performance over a direct store.select (already caching). I done the test against 1 user inboxes running a random get 1 million times. The differences between mailServer.getUserInbox (with local caching ReferenceMap) and the manual store.select (Configuration) (store already cache its results) is really small: 9 seconds for the full run for getUserInbox 12 seconds for the store.select. We could probably remove the getUserInbox method and leave to the store system and to its caching the whole handling. By now I think I will add configurability to the new ToMultiRepository in order to be able to specify a destinationUrl prefix and a type (MAIL/SPOOL). Eventually, in a second step, we could even add a strategy for repository naming (file://var/mail/#DOMAIN#/#LOCALPART#) or something similar. The same startegy could be added to pop3 configuration. Add more flexibility to LocalDelivery - Key: JAMES-414 URL: http://issues.apache.org/jira/browse/JAMES-414 Project: James Type: Improvement Components: Matchers/Mailets (bundled) Versions: 2.3.0 Reporter: Stefano Bagnara Assignee: Stefano Bagnara Priority: Minor While removing the storeMail method from James (JAMES-392) and moving its logic in the LocalDelivery we could try to improve the configurability of the LocalDelivery. Here is a discussion on the mailinglist: 1) Should I move the enableAliases/enableForward directly to the LocalDelivery? Yes. I'm +1 for anything that allows configurations which were limited to being set once in James but used many times to being refactored to many to many, which means moving them nearer the point of use. Of course it also makes sense sometimes to retain a global default. And we've always applied the principle of least surprise when considering config questions, try to think through the questions that will arise when people upgrade, and take that into account when you make config file format changes. This usually means make it work by default like it did before unless the users choose to change it. I'm not sure that trying to achieve backward compatibility in the config.xml is a good idea (we would need a lot of junk in the code and in the config to do that). I understand that. But work through what would be needed to break this, documentation etc is part of this consideration. Please note that I already changed the place where you have to declare mailetpackages/matcherpackages and the place you declare the main spool repository. Yeah I noticed, you will have to be prepared to document this and support it on the users list when the questions flood in. 2) IgnoreCase is instead used more than once and by more clients (Not only LocalDelivery) and so I was thinking that we should move this configuration to the UserRepository interface. Should I do that? It is a global setting, the rfc (I forget) makes user parts case sensitive, we offer the choice to ignore this globally, anything else would (IMO) just be confusing. What benefit would the chnage bring? 3) Should I remove the deprecated method storeMail from MailetContext now? We also have a few other deprecated methods ... previous release IMHO we can safely remove all of them: do you agree? Only if the next release is going to be a Major one (i.e. 3.x not 2.x) 4) With this change I could split the LocalDelivery in 2 different new mailets (leave LocalDelivery for backward compatibility) and create a LocalUsersAliasingForwarding mailet that just apply aliasing and forwarding for the mails processed and a LocalDelivery that simply deliver the message to a repository named like the destination of the message being processed (with no lookup on users). This would allow much more flexible Configurations. +1 This is good, and paves the way for richer v'hosting. 5) I can add configurations to the LocalDelivery (or the 2 new mailets) in order to be able to use a different UserRepository (different from the LocalUsers) or a different inboxes repositories by allowing local overriding configurations: what do you think? +1 Yes, this also is good, and also supports richer v'hosting support. (The third thing is to modify pop3 imap handlers to implement combinations of IP address reverse dns and username naming convention to fudge that part.) -- 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
Re: svn commit: r265559 (ATTN: Vincenzo)
In the BayesianAnalysis mailet the instantiation of JDBCBayesianAnalyzer
is as follows:
private JDBCBayesianAnalyzer analyzer = new JDBCBayesianAnalyzer() {
protected void delegatedLog(String logString) {
log(BayesianAnalysis: + logString);
}
};
May it be that a jdk change has changed the behaviour of this.getClass()
in this case? If true, it frightens me a little bit. What is your jdk?
Mine is 1.4.2_07.
Anyway, your fix makes it safer, so let's keep it.
Vincenzo
Stefano Bagnara wrote:
Vincenzo,
Please review this fix: I don't understand why/how it was working before !?!
I used your mailet since your commit and they worked but it was no more
working and I have not found what is changed (maybe the jdk?).
Stefano
Author: bago
Date: Wed Aug 31 12:33:11 2005
New Revision: 265559
URL: http://svn.apache.org/viewcvs?rev=265559view=rev
Log:
Fixed a bug compiling this mailet with latest jdks. The
bayesian mailet does extend this class with its own anonymous
inner class and the this.getClass() was returning the name of
the anonymous class (e.g: ClassName$2).
Modified:
james/server/trunk/src/java/org/apache/james/util/JDBCBayesian
Analyzer.java
[...]
-sqlQueries.init(this.sqlFile,
this.getClass().getName(), conn, getSqlParameters());
+sqlQueries.init(this.sqlFile,
+ JDBCBayesianAnalyzer.class.getName() , conn, getSqlParameters());
-
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: svn commit: r265559 (ATTN: Vincenzo)
In the BayesianAnalysis mailet the instantiation of
JDBCBayesianAnalyzer is as follows:
private JDBCBayesianAnalyzer analyzer = new
JDBCBayesianAnalyzer() {
protected void delegatedLog(String logString) {
log(BayesianAnalysis: + logString);
}
};
May it be that a jdk change has changed the behaviour of
this.getClass() in this case? If true, it frightens me a
little bit. What is your jdk?
Mine is 1.4.2_07.
Anyway, your fix makes it safer, so let's keep it.
Vincenzo
I don't know how/when it happened: now the this.getClass call the getClass
of the innerclass and it find BayesianAnalysis$2 instead of
JDBCBayesianAnalyzer.
I'm using 1.4.2_07 too. I've tested with 1.5 and I keep getting the same
result.
Can you try running this code?
public class Test {
public Class test() {
return(this.getClass());
}
public static void main(String[] args) {
Test t = new Test() {
};
System.out.println(t.test().equals(Test.class));
}
}
It returns false in all my tests.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (JAMES-419) NPE during 8bit conversion of non-mime messages
NPE during 8bit conversion of non-mime messages --- Key: JAMES-419 URL: http://issues.apache.org/jira/browse/JAMES-419 Project: James Type: Bug Components: Remote Delivery Versions: 2.3.0 Reporter: Stefano Bagnara Assigned to: Soren Hilmer Just sending a message with no mime informations: --- Received: from localhost ([127.0.0.1]) by BAGOMIPS (JAMES SMTP Server 2.3-dev) with SMTP ID 254; Sat, 3 Sep 2005 18:23:04 +0200 (CEST) Subject: test Date: Sat, 3 Sep 2005 18:23:04 +0200 (CEST) From: [EMAIL PROTECTED] test . --- 03/09/05 18:23:07 INFO James.Mailet: RemoteDelivery: Exception caught in RemoteDelivery.run() java.lang.NullPointerException at com.sun.mail.smtp.SMTPTransport.convertTo8Bit(SMTPTransport.java:702) at com.sun.mail.smtp.SMTPTransport.sendMessage(SMTPTransport.java:521) at org.apache.james.transport.mailets.RemoteDelivery.deliver(RemoteDelivery.java:521) at org.apache.james.transport.mailets.RemoteDelivery.run(RemoteDelivery.java:1050) at java.lang.Thread.run(Thread.java:534) --- -- 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]
[jira] Commented: (JAMES-387) Exception in BayesianAnalysis
[ http://issues.apache.org/jira/browse/JAMES-387?page=comments#action_12322588 ] Vincenzo Gianferrari Pini commented on JAMES-387: - I gave a careful look to the code and couldn't find anything wrong. I have a spam table with more than 258000 rows and everything works fine for me. IMHO a possible explanation of Stefano's exceptions is the following: The ham/spam corpus hashmaps may take a lot of memory. Accordingly, I gave a lot of -Xmx memory to the JVM. I remember some time ago, in a java (non James) application, an unpredictable JVM behaviour (strange exceptions thrown) when the available heap was just about the needed heap. Decreasing a little bit the -Xmx size I was getting OutOfMemoryError, and increasing it everything was fine. Stefano, can you try with more memory? Exception in BayesianAnalysis - Key: JAMES-387 URL: http://issues.apache.org/jira/browse/JAMES-387 Project: James Type: Bug Components: Matchers/Mailets (bundled) Versions: 3.0 Environment: James from svn-trunk 2005-08-01. MySQL 4.0 Reporter: Stefano Bagnara Assignee: Vincenzo Gianferrari Pini Priority: Minor Got this exception for every incoming mail: 02/08/05 00:39:25 INFO James.Mailet: BayesianAnalysis: Exception: java.lang.Integer java.lang.ClassCastException: java.lang.Integer at org.apache.james.util.BayesianAnalyzer.getTokenProbabilityStrengths(BayesianAnalyzer.java:591) at org.apache.james.util.BayesianAnalyzer.computeSpamProbability(BayesianAnalyzer.java:340) at org.apache.james.transport.mailets.BayesianAnalysis.service(BayesianAnalysis.java:289) at org.apache.james.transport.LinearProcessor.service(LinearProcessor.java:407) at org.apache.james.transport.JamesSpoolManager.process(JamesSpoolManager.java:460) at org.apache.james.transport.JamesSpoolManager.run(JamesSpoolManager.java:369) at java.lang.Thread.run(Unknown Source) If I clean my spam/ham db the exceptions disappears but they start again when the spam/ham db become large. My bayesiananalysis_spam contains 20 rows. The following are the spam tokens with higher occurrences. +---+-+ | token | occurrences | +---+-+ | 3D| 82151 | | a | 59953 | | the | 45295 | | FONT | 42771 | | Content-Type | 39058 | | to| 36626 | | com | 32902 | | http | 32886 | | of| 32504 | | font | 31803 | | and | 31577 | | Content-Transfer-Encoding | 31576 | | p | 29746 | | text | 29482 | | in| 29418 | | it| 28498 | | br| 28037 | | DIV | 27431 | -- 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: svn commit: r265559 (ATTN: Vincenzo)
Stefano Bagnara wrote:
In the BayesianAnalysis mailet the instantiation of
JDBCBayesianAnalyzer is as follows:
private JDBCBayesianAnalyzer analyzer = new
JDBCBayesianAnalyzer() {
protected void delegatedLog(String logString) {
log(BayesianAnalysis: + logString);
}
};
May it be that a jdk change has changed the behaviour of
this.getClass() in this case? If true, it frightens me a
little bit. What is your jdk?
Mine is 1.4.2_07.
Anyway, your fix makes it safer, so let's keep it.
Vincenzo
I don't know how/when it happened: now the this.getClass call the getClass
of the innerclass and it find BayesianAnalysis$2 instead of
JDBCBayesianAnalyzer.
I'm using 1.4.2_07 too. I've tested with 1.5 and I keep getting the same
result.
Can you try running this code?
public class Test {
public Class test() {
return(this.getClass());
}
public static void main(String[] args) {
Test t = new Test() {
};
System.out.println(t.test().equals(Test.class));
}
}
It returns false in all my tests.
It returns false also to me, using Sunn jdk 1.4.2_06 under windows. I
can't try it under my Sun jdk 1.4.2_07 under linux in production...
Vincenzo
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
