[PJUG Javamail] Need some advice from a Tomcat expert

[Rob Tanner]

Ken,

I'm looking into possible locking/synchronization issues.  Thanks for
the suggestion.

On the other issue, the extreme length of time (30 seconds or more) for
the https redirect to work still baffles me, and I don't think it's at
all related to any possible locking or synchronization issue.  The
portion of web.xml specifying the security-constraint is correct as far
as I can tell (see below), and I've used the same constraint before.

  <security-constraint>
    <web-resource-collection>
      <web-resource-name>Group Aliases Manager</web-resource-name>
      <url-pattern>/*</url-pattern>
    </web-resource-collection>
    <user-data-constraint>
      <description>Constrain Group Alias Manager to use HTTPS</description>
      <transport-guarantee>CONFIDENTIAL</transport-guarantee>
    </user-data-constraint>
  </security-constraint>


What I'm wondering is:  This instance of Tomcat is using a virtual
address (i.e.; one of the three secondary addresses defined on eth0) and
so both the port 80 and port 443 connectors have an "address=" parameter
specified in the connector definition.  If the browser attempts to
connect to the port 443 connector (using the https scheme) I get an
immediate response.  It is only when the browser initially goes to port
80 (http scheme) and the constraint forces a redirect to 443 that I see
this monstrously long delay.  I've included below both connector
definitions.  Could there be something in the definitions that is
creating the long delay on redirect?

    <Connector port="80" address="10.171.255.103"
        maxHttpHeaderSize="8192" enableLookups="false" tcpNoDelay="true"
        maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
        acceptCount="100" connectionTimeout="20000"
disableUploadTimeout="true"
        scheme="http" redirectPort="443" />

    <Connector port="443" address="10.171.255.103"
        maxHttpHeaderSize="8192" enableLookups="false" tcpNoDelay="true"
        maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
        acceptCount="100" connectionTimeout="20000"
disableUploadTimeout="true"
        keystoreFile="/usr/java/keystore" keystorePass="secret"
        scheme="https" secure="true" clientAuth="false" sslProtocol="TLS" />

Thanks,
Rob




Ken Paulsen said the following on 06/08/2007 01:46 PM:
>
> Hi Rob,
>
> Unfortunately I don't have the answer for you... although due to the
> nature of framesets making concurrent requests, I suspect it has
> something to do with a locking / synchronization issue where it
> doesn't get freed up and times out.  Or something along those lines. 
> Just a guess.
>
> Your post did remind me of a recent blog that I found via TSS
> (http://www.theserverside.com/news/thread.tss?thread_id=45222), here's
> the direct link:
>
>     http://weblogs.java.net/blog/sdo/archive/2007/05/how_to_test_con.html
>
> Good read (w/ the code for the utility) for performance testing.
>
> Ken
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://javac.com/pipermail/javamail/attachments/20070611/03940e76/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3249 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://javac.com/pipermail/javamail/attachments/20070611/03940e76/attachment-0002.bin>