Performance problems related to the creation of many javax.mail.Session objects

[glassfishrobot]

(Originally submitted to Sun bug system, transferred to Oracle bug system,
and finally here for resolution.
Originally filed by dmindler@telcordia.com on 2005-02-11 19:25:42.)

A DESCRIPTION OF THE REQUEST :
The application being built on JavaMail needs to create many instances of
javax.mail.Session objects to send email via SMTP, each which may have
different properties set programmatically. The getInstance(Properties props)
method is being used which in turn creates a new instance of the Session
object.

When a new instance of the Session object is created, the constructor loads
resources from the mail.jar, which is an expensive operation in itself. This
expense is compounded because the mail.jar is signed. JDB was utilized to
pinpoint when the javax.mail.Session constructor was accessing the mail.jar.
Here is a partial stack trace:

....
[13] javax.mail.SecuritySupport12.getResourceAsStream (SecuritySupport12.java:39)
[14] javax.mail.Session.loadResource (Session.java:1033)
[15] javax.mail.Session.loadAddressMap (Session.java:975)
[16] javax.mail.Session. (Session.java:192)
[17] javax.mail.Session.getInstance (Session.java:213)

JUSTIFICATION :
The primary driver for requesting this enhancement is to increase the
performance capabilities of the JavaMail client library. Though the current
implementation is usable for samples, small testcases and production
applications that only need to create one javax.mail.Session instance, it is
not scalable for the application attempting to use Sun's JavaMail
implementation.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
A performance improvement is requested so that the Session instance only load
resources it needs once from the mail.jar and caches. Subsequent
javax.mail.Session instances should load initial resources from the cache and
not attempt to load from the mail.jar.
ACTUAL -
Two interesting things happened on the AIX platform where this is being used:

1. many JarFile objects and x509 package objects were being created causing a
   negative impact on performance - this is due to the javax.mail.Session object
   obtaining resources from the mail.jar which is signed

2. the JarFile instance was creating SoftReference objects which caused the
   heap to grow - this may be an artificat of IBM's JVM implementation of
   JarFile and resource loading by the classloader.

---------- BEGIN SOURCE ----------
JavaMail samples can be used, but instead of using
Session.getDefaultInstance() or Session.getInstance() in the init() method of
the sample, move the Session.getInstance(Properties props) to a loop of the
application that sends out email via SMTP.
---------- END SOURCE ----------

Affected Versions

1.4.3

Environment

All
All

[glassfishrobot]

@glassfishrobot Commented
Reported by @bshannon

[glassfishrobot]

@glassfishrobot Commented
@bshannon said:
(Original evaluation from Sun bug system:)

It's rarely necessary to create a new Session object for each message
to be sent. Using a combination of the mail.smtp.* properties, the
SMTPMessage class, and the connect(host, user, password) method it's
possible to create a Transport object that's properly configured for
each message to be sent.

Further improvements to cache information as suggested in the Description
are a low priority.

[glassfishrobot]

@glassfishrobot Commented
This issue was imported from Bugzilla JAVAMAIL-6278

[glassfishrobot]

• Issue Imported From: https://github.com/javaee/javamail/issues/101
• Original Issue Raised By:@glassfishrobot
• Original Issue Assigned To: @bshannon