james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Noel J. Bergman" <n...@devtech.com>
Subject RE: [DISCUSSION] Include Unit Tests in regular build
Date Sat, 11 Nov 2006 17:53:09 GMT
Stefano Bagnara wrote:

> +1 for the dist: it is where the real check has to be forced.
> In other scenario it won't help forcing something.


> The long-running tests issues is solved using a decent CI environment.

We do have nightly builds.  And the nightly build pointed out the failed

> I have continuum monitoring the james repositories every 5 minutes

I doubt that anyone wants for me to be posting automated results many times
daily, but if that's what people want, I can adjust the cron job
accordingly, although I'd only upload the builds once per day.

> Does ASF provide infrastructure to put there our continuum?

We already have GUMP, remember?  And, yes, there is continuum running
somewhere on the infrastructure.

> >   ant run-unit-test -Dtest=org.apache.james.smtpserver.SMTPServerTest

> I think that generally speaking it is not a good idea to complicate the
> build.xml with unused targets

And why is this bad, as opposed to the `mvn test -Dtest=SMTPServerTest`,
which you just suggested?  And why would it be unused?

> it would be interesting to have an overview of tools every james
> committer use to work on james projects (platform, ide, compilers,
> debuggers, profilers, svn tools and so on).

  ant, emacs, java, javac, svn

> 1) It was not a memory-leak: Wikipedia has a simple "Is it a memory
> leak?" explanation: http://en.wikipedia.org/wiki/Memory_leak

<<sigh>>  From your link:

  a memory leak is a particular kind of unintentional memory
  consumption by a computer program where the program fails
  to release memory when no longer needed

Memory consumed permanently for transient conditions meets that definition.

> We simply said that you had no enough information to say "confirmed
> memory leak in james": facts proved that there was no memory-leak,
> and that the problem was not in james server code.

The FACT is that there was an error (using InetAddress for resolution, which
we already knew that we cannot use) that caused the heap to be consumed
until JAMES crashed due to lack of memory.  I would call that a problem.
:-)  Fortunately, I always keep my own counsel.

As I observed earlier, we could consider configuring JAMES to use a subclass
of the dnsjava resolver for the JRE that is instrumented to log a warning if
it is called.  That would call out offending code, even in third party code.

> 6) If you used a real profiler (netbeans profiler, jprofiler or another
> "real" tool and not a simple heap dump) it would have been much more
> easy to find the problem

The problem was very easy to find once I managed to keep the JVM from
crashing, which ended up just meaning cranking the heap size to 256MB (and
also limiting the dnsjava cache).  And it was necessary to do it in a
production environment, not some toy lab testbench.

	--- Noel

To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

View raw message