RE: Status, Release Candidates and Derby
Daniel John Debrunner wrote:
> I'm looking at how James uses Derby
Your observations aside, JAMES can be far more efficient in its management
of data than it is at present. Too much copying. dbfile is more efficient,
and I'd like to see us separate mail (associates state, attributes and
recipients with a message) from message, so that we have fewer copies and
don't need to move the message when mail switches between processors.
Back to your comments ...
> I'm curious about the recipients and {message_body, message_attributes}
> fields.
> recipients long varchar - In Derby LONG VARCHAR has a limit of 32,700
> characters. Does this limit James in any way?
As per RFC 2821, an e-mail address is limited to 320 characters, so we'd be
good for 100 addresses, which is the minimum permitted by the RFC.
Practically, we would be good for far more than the minimum.
> A better datatype would be CLOB, then you could have up to 2Gb character
limit.
> I don't believe this would require any application changes (moving to a
CLOB).
We've seen some odd behavior dealing with CLOBs with some drivers, hence the
useBlob vs useBytes attibute in sqlResources. Would that apply here?
> message_body, message_attributes are defined as BLOB, this means
> BLOB(1M), a one megabyte blob. Is this a concern for James?
> (http://db.apache.org/derby/docs/10.1/ref/rrefblob.html)
Possibly, yes, thanks. Other databases have similar limits. Personally,
I'd suggest that until the aforementioned changes are made, anyone accepting
large e-mail (a maximum message size can be configured in the SMTP handler)
be using dbfile, rather than db.
--- Noel
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Status, Release Candidates and Derby
Noel J. Bergman wrote:
> I have spent much of ApacheCon working on testing JAMES. Ran into some
> little bits, but generally OK. Ran with Derby for about 48 hours stably,
I'm looking at how James uses Derby and I see for the message repository
the create table statement is:
CREATE TABLE ${table} (
message_name varchar (200) NOT NULL,
repository_name varchar (255) NOT NULL,
message_state varchar (30) NOT NULL ,
error_message varchar (200) ,
sender varchar (255) ,
recipients long varchar NOT NULL ,
remote_host varchar (255) NOT NULL ,
remote_addr varchar (20) NOT NULL ,
message_body blob NOT NULL ,
message_attributes blob ,
last_updated timestamp NOT NULL,
PRIMARY KEY (repository_name, message_name)
)
I'm curious about the recipients and {message_body, message_attributes}
fields.
recipients long varchar - In Derby LONG VARCHAR has a limit of 32,700
characters. Does this limit James in any way? A better datatype would be
CLOB, then you could have up to 2Gb character limit.
(http://db.apache.org/derby/docs/10.1/ref/rrefsqlj15147.html)
(http://db.apache.org/derby/docs/10.1/ref/rrefclob.html)
I don't believe this would require any application changes (moving to a
CLOB).
message_body, message_attributes are defined as BLOB, this means
BLOB(1M), a one megabyte blob. Is this a concern for James? If you want
to have the maximum size of a BLOB then you would need to define the
type using BLOB(2G).
(http://db.apache.org/derby/docs/10.1/ref/rrefblob.html)
I'm not sure what your intended limits are in these cases, but wanted to
ensure that you are not suprised by them.
DB2 will also have the same limits.
Dan.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Status, Release Candidates and Derby
Whoa, guys. I didn't say that there were bugs in Derby. I always look for any memory leaks, and was more concerned about finding them (and other bugs) in *our* code. :-) I did a test that pushed over 32K incoming messages (total messages would be over 64k, due to SMTP relay and POP3) through JAMES with Derby and heapdump enabled, and am not seeing any memory leak. I have tar'd up the heapdump (multiple snapshots during the run), SAR-INF/ and logs/ for review. It is available as memleak-test.tar.gz from people.apache.org/~noel. I'll delete it within the next week or so. As an aside to Danny: I'd like to encourage you to follow up your comment "I'm not going into the whole world of memory tuning here (that would be a half-day tutorial I could give!)" with a response to the next ApacheCon CFP. :-) We can post the next drop as a beta. That's fine. I'd already made Derby the default repository, to get it tested. Hopefully those of you who use Bayesian will consider testing against Derby for that, too, even if you change to your current database for mail repositories. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Bayesian antispam mailets
Vincenzo Gianferrari Pini wrote: > Stefano, did you have time to test the BayesianAnalyzer mailets after my > recent fix to JAMES-387? Not yet, unfortunately. I hope to be able to recompile and redeploy my own server in this Christmas holidays (hopefully installing the 2.3b1 :-) ). Stefano - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Status, Release Candidates and Derby
> I'm quite neutral about Derby, but I don't remember the reasons not to > continue to keep file repositories as the default. By definition it is > the simplest and safest. The reason is that there are known bugs in lock management of file repositories. I reported one few months ago, and in stress test I'm able to make them fails every time. Never had this problems with db repositories. Here is one: http://issues.apache.org/jira/browse/JAMES-397 Stefano - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Bayesian antispam mailets
Stefano, did you have time to test the BayesianAnalyzer mailets after my recent fix to JAMES-387? Vincenzo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Status, Release Candidates and Derby
I'm quite neutral about Derby, but I don't remember the reasons not to continue to keep file repositories as the default. By definition it is the simplest and safest. Vincenzo Stefano Bagnara wrote: If we're unsure that we can shake out the Derby bugs quickly we should pull this feature so that we can cycle through releases quickly to get to a final release soon. It would be better to add Derby in a subsequent 2.4.0 release in the not too distant future than hold up this release. I think we could release a 2.3.0b1 with default derby repositories. If the test reveal any REAL problem we can decide to remove it and to move it to 2.4.0. Stefano - 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: Status, Release Candidates and Derby
> If we're unsure that we can shake out the Derby bugs quickly we should pull > this feature so that we can cycle through releases quickly to get to a final > release soon. It would be better to add Derby in a subsequent 2.4.0 release > in the not too distant future than hold up this release. I think we could release a 2.3.0b1 with default derby repositories. If the test reveal any REAL problem we can decide to remove it and to move it to 2.4.0. Stefano - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Status, Release Candidates and Derby
+1 for 2.3.0, +1 for Beta, +1 for Derby support in 2.4.0 if the alternative is a delay. Vincenzo Steve Brewin wrote: Hi All, I would prefer 2.3.0 for this release for the reasons stated by Stefano and Søren. Beta or RC# I don't much care about, they mean different things to different people. Its more important to make our intent clear - a feature stable release, just shaking out the bugs. If we're unsure that we can shake out the Derby bugs quickly we should pull this feature so that we can cycle through releases quickly to get to a final release soon. It would be better to add Derby in a subsequent 2.4.0 release in the not too distant future than hold up this release. I'ld say just my 2 cents, but as I've contibuted so little to this release, maybe 1 cent. Cheers and seasonal greetings to you all, -- Steve -Original Message- From: Søren Hilmer [mailto:[EMAIL PROTECTED] Sent: 15 December 2005 11:05 To: James Developers List Subject: Re: Status, Release Candidates and Derby I am on par with Stefano regarding the number scheme, and also on a beta release before a RC release. IMO we should save 3.0 for the more drastic upcomming changes, and continue with 2.3.0 for this release. --Søren -- Søren Hilmer, M.Sc., M.Crypt. wideTrailPhone: +45 25481225 Pilevænget 41Email: [EMAIL PROTECTED] DK-8961 Allingåbro Web: www.widetrail.dk On Thu, December 15, 2005 11:20, Stefano Bagnara wrote: Noel J. Bergman wrote: Would people take a look at the current code and see if they feel comfortable with a release candidate? Unless I encounter a definitive memory leak or other problem, I'd like to call a vote on a release candidate. And since there are both configuration and functional changes, I'd suggest that v3 is perhaps the more appropriate designation than v2.3. I would better like a a 2.3b1 or 3.0b1 (beta release) before the 3.0rc1. I'm not sure James is ready for release candidate: changes I've done in the past months need to be tested by a wider audience to understand wether the users understand them or we need to change some behaviour. Furthermore, I think that we could change our opinion (I hope it doesn't happen but i'm not sure) about the "default" configuration (for mail stores, or anything else) after a beta cycle and I would not be happy to change similar thing in release candidate cycles. Anyway I'm +1 for the release, soon! About the version numbers I'm +1 for a 2.3.0 and +0 for 3.0. We didn't publish a numbering rule, so it's a personal feeling. I like the 2.3.0 because current trunk has less changes than the 2.1 to 2.2 step and it's not a "revolution". I would prefer to keep the 3.0 for the "next generation" (pojo, different container, different configuration style, much different behaviours). My preference is for an early 2.3.0 release and a fast move to the 3.0. 2.3.0 (current trunk) fixes a lot of bugs from 2.2.0 and is a due upgrade. Stefano - 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] - 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]
[jira] Commented: (JAMES-429) error: Unable to provide DataSourceComponent for maildb
[ http://issues.apache.org/jira/browse/JAMES-429?page=comments#action_12360563 ] Stefano Bagnara commented on JAMES-429: --- Please provide more informations: you config.xml file, your environment. > error: Unable to provide DataSourceComponent for maildb > --- > > Key: JAMES-429 > URL: http://issues.apache.org/jira/browse/JAMES-429 > Project: James > Type: Bug > Reporter: x > > thank you!can u help me!!! > C:\Downloads\james-2.2.0-src\dist\james-2.2.0\bin>run.bat > Using PHOENIX_HOME: C:\Downloads\james-2.2.0-src\dist\james-2.2.0 > Using PHOENIX_TMPDIR: C:\Downloads\james-2.2.0-src\dist\james-2.2.0\temp > Using JAVA_HOME: > Phoenix 4.0.1 > org.apache.excalibur.containerkit.lifecycle.LifecycleException: Component > named > "users-store" failed to pass through the Initialization stage. (Reason: > org.apac > he.avalon.framework.component.ComponentException: Unable to provide > DataSourceCo > mponent for maildb). > at > org.apache.excalibur.containerkit.lifecycle.LifecycleHelper.fail(Life > cycleHelper.java:289) > at > org.apache.excalibur.containerkit.lifecycle.LifecycleHelper.startup(L > ifecycleHelper.java:159) > at > org.apache.avalon.phoenix.components.application.DefaultApplication.s > tartup(DefaultApplication.java:480) > at > org.apache.avalon.phoenix.components.application.DefaultApplication.d > oRunPhase(DefaultApplication.java:428) > at > org.apache.avalon.phoenix.components.application.DefaultApplication.r > unPhase(DefaultApplication.java:364) > at > org.apache.avalon.phoenix.components.application.DefaultApplication.s > tart(DefaultApplication.java:138) > at > org.apache.avalon.framework.container.ContainerUtil.start(ContainerUt > il.java:251) > at > org.apache.avalon.phoenix.components.kernel.DefaultKernel.startup(Def > aultKernel.java:178) > at > org.apache.avalon.phoenix.components.kernel.DefaultKernel.addApplicat > ion(DefaultKernel.java:254) > at > org.apache.avalon.phoenix.components.deployer.DefaultDeployer.deploy( > DefaultDeployer.java:353) > at > org.apache.avalon.phoenix.components.embeddor.DefaultEmbeddor.deployF > ile(DefaultEmbeddor.java:498) > at > org.apache.avalon.phoenix.components.embeddor.DefaultEmbeddor.deployF > ile(DefaultEmbeddor.java:491) > at > org.apache.avalon.phoenix.components.embeddor.DefaultEmbeddor.deployF > iles(DefaultEmbeddor.java:476) > at > org.apache.avalon.phoenix.components.embeddor.DefaultEmbeddor.deployD > efaultApplications(DefaultEmbeddor.java:466) > at > org.apache.avalon.phoenix.components.embeddor.DefaultEmbeddor.execute > (DefaultEmbeddor.java:224) > at org.apache.avalon.phoenix.frontends.CLIMain.run(CLIMain.java:158) > at > org.apache.avalon.phoenix.frontends.CLIMain.execute(CLIMain.java:144) > at org.apache.avalon.phoenix.frontends.CLIMain.main(CLIMain.java:102) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) > at java.lang.reflect.Method.invoke(Unknown Source) > at org.apache.avalon.phoenix.launcher.Main.startup(Main.java:94) > at org.apache.avalon.phoenix.launcher.Main.main(Main.java:46) > Caused by: org.apache.avalon.framework.component.ComponentException: Unable > to p > rovide DataSourceComponent for maildb > at > org.apache.avalon.cornerstone.blocks.datasource.DefaultDataSourceSele > ctor.select(DefaultDataSourceSelector.java:140) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) > at java.lang.reflect.Method.invoke(Unknown Source) > at > org.apache.avalon.phoenix.components.application.BlockInvocationHandl > er.invoke(BlockInvocationHandler.java:92) > at $Proxy2.select(Unknown Source) > at > org.apache.james.userrepository.AbstractJdbcUsersRepository.initializ > e(AbstractJdbcUsersRepository.java:248) > at > org.apache.james.core.AvalonUsersStore.initialize(AvalonUsersStore.ja > va:130) > at > org.apache.avalon.framework.container.ContainerUtil.initialize(Contai > nerUtil.java:235) > at > org.apache.excalibur.containerkit.lifecycle.LifecycleHelper.startup(L > ifecycleHelper.java:144) > ... 22 more > There was an uncaught exception: > - > --- Message --- > Failed to start application james. > --- Stack Trace --- > org.apache.avalon.phoenix.interfaces.DeploymentException: Failed to start > applic > ation james. > at > org.apache.avalon.p
