You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by Bernd Fondermann <bf...@brainlounge.de> on 2006/05/18 15:37:01 UTC
Postage Development Status
Hi,
I uploaded the current code into JIRA JAMES-442
(http://issues.apache.org/jira/browse/JAMES-442)
Current feature + workflow summary:
The tool generates many mails in different sizes from/to random users
based on a very flexibel configuration.
It tracks what happened to these mails and when.
It tracks errors (e.g. connection failures).
It tracks the memory and thread consumption (under Java 5).
It uses the standard APIs POP3 & SMTP.
It writes the recorded data into CSV files.
There is much more which comes to my mind as possible future developments:
+ codebase: where should the whole application be placed (own
subproject, sandbox?)
+ libraries: Remove dependency on Ristretto
+ architecture: integrate with maven2
+ architecture: look into scalability and threading topics
+ feature: add option to make the load adaptive, so that we can get
to the limits of James
+ feature: do more functional testing, not just pure end-to-end
tests, by parsing the received mail and check if, for example, a footer
had been added.
+ infra: use it as an Continuous Integration tool which
automatically executes on Daily Builds
+ reporting: draw fancy graphs
+ integration: look into JMeter integration
+ development: have a review of the whole stuff, take it apart, improve
it and put it together again ;-)
What do you think?
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Postage Development Status
Posted by Stefano Bagnara <ap...@bago.org>.
Bernd Fondermann wrote:
>>> + feature: add option to make the load adaptive, so that we can
>>> get to the limits of James
>
>> +1 My preferred feature ;-) I would like to use it to test
>> optimizations and be sure we don't introduce bottlenecks with changes.
>
> how do we implement that? there is more than one wheel which can be tuned.
> a canonical first solution would be to constantly increase the number of
> mails sent.
IIRC we already discussed a similar scenario:
Just define a "queue size": posta will send new mails until it reaches
the queue size, then every time it receive (read) a message it send a
new one. This way you know that the server is always busy handling a
"queue size" number of messages.
It will be interesting to know how many messages can be sent this way by
different James releases.
Maybe this would also help tuning the spool threads number.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Postage Development Status
Posted by Bernd Fondermann <bf...@brainlounge.de>.
Stefano Bagnara wrote:
> Bernd Fondermann wrote:
>
>> Hi,
>>
>> I uploaded the current code into JIRA JAMES-442
>> (http://issues.apache.org/jira/browse/JAMES-442)
>
>
> I looked around in the code when you uploaded them: I saw you left the
> old source folder, too (that should be removed, it is confusing).
ooops! yeah, should have been removed.
>> + feature: add option to make the load adaptive, so that we can
>> get to the limits of James
> +1 My preferred feature ;-) I would like to use it to test optimizations
> and be sure we don't introduce bottlenecks with changes.
how do we implement that? there is more than one wheel which can be tuned.
a canonical first solution would be to constantly increase the number of
mails sent.
>> + feature: do more functional testing, not just pure end-to-end
>> tests, by parsing the received mail and check if, for example, a
>> footer had been added.
>
> Maybe this is much more a functional test that could be added to the
> default unit tests.
agreed, all which can be covered by unit tests should be covered there.
what I am proposing here is a feature to test more complex mail flows.
>> + integration: look into JMeter integration
>
> Yes, maybe this could help creating custom scenario, and maybe the best
> feature would be an SMTP proxy to log an SMTP session and add it as a
> template of the load test (JMeter do that for the HTTP tests).
I see. would not be my top priority.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Postage Development Status
Posted by Stefano Bagnara <ap...@bago.org>.
Bernd Fondermann wrote:
> Hi,
>
> I uploaded the current code into JIRA JAMES-442
> (http://issues.apache.org/jira/browse/JAMES-442)
I looked around in the code when you uploaded them: I saw you left the
old source folder, too (that should be removed, it is confusing).
> There is much more which comes to my mind as possible future developments:
>
> + codebase: where should the whole application be placed (own
> subproject, sandbox?)
I think in its own subproject.
> + libraries: Remove dependency on Ristretto
+1
> + architecture: integrate with maven2
+1: jSPF is maven2, I would like to have a common way for all
subprojects. (Maybe we can convert Mime4J and Jsieve, also, in future)
> + feature: add option to make the load adaptive, so that we can get
> to the limits of James
+1 My preferred feature ;-) I would like to use it to test optimizations
and be sure we don't introduce bottlenecks with changes.
> + feature: do more functional testing, not just pure end-to-end
> tests, by parsing the received mail and check if, for example, a footer
> had been added.
Maybe this is much more a functional test that could be added to the
default unit tests.
> + infra: use it as an Continuous Integration tool which
> automatically executes on Daily Builds
That would also be cool.
> + reporting: draw fancy graphs
Not important at all, even if people like fancy graphs.
> + integration: look into JMeter integration
Yes, maybe this could help creating custom scenario, and maybe the best
feature would be an SMTP proxy to log an SMTP session and add it as a
template of the load test (JMeter do that for the HTTP tests).
> + development: have a review of the whole stuff, take it apart, improve
> it and put it together again ;-)
I'll be heppy to help in this!
> What do you think?
>
> Bernd
Thank you again for your efforts in creating tests and load tools to
increase James reliability!
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org