Bernd Fondermann wrote:
Hi,
Finally, I managed to run the same scenario as described below with
2.3.0a1. 80603 mails sent, 0 lost. Performance seems to be basically
identical which is good news.
Good to know!
Which environment did you test? (mysql/derby db? db/file/dbfile
repositories?)
Have you done any comparison of the different dbs?
And I'm looking forward to try and reproduce Stefanos improvements in
big mail handling (20MB) soon after they have been commited.
The patch is more difficult than I though, but I'm working on it, now.
Hope to share something soon. I'm writing new tests because of the
"critical" changes to the core MimeMessageWrapper.
Also, I'd like to encourage people to look at JAMES-442 and comment on
the test tool itself and the test which should be run. Personally, I'd
like to have memory footprint data recorded and
multithreading/scalability/errorhandling improved. But what's more?
It is difficult to check memory footprint in java. The only way is to
limit the JVM resources and see how it works.
(It would be cool to have a switch to say to the VM "try to use less
than X mb of heap" so that it automatically GC at that level but don't
send OutOfMemoryErrors when more memory is needed to complete the operation)
Ralf Hauser suggested to base it on JMeter which sounds like a good idea
to me. Any thoughts on this from someone already familiar with the
JMeter codebase?
Sorry, I just used it once for a web scenario but I don't know anything
about its codebase/architecture.
Stefano
PS: I didn't have the time to check out your postage work, but I think
that is a good add-on to james test suite. Maybe we should create its
own subproject instead of integrating it on the main codebase.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
