SSL in Play and strange errors in application.log

[AMT_EB]

Hi all

I've set up an instance of my application and configured SSL in the
application.conf:

%prod.https.port=443
%prod.certificate.key.file=conf/local_domain_tld.key
%prod.certificate.file=conf/local_domain_tld.crt

This seems to work fine, the page is displayed, SSL encryption does
work.

When I now try to connect from a Windows 2008 machine with Internet
Explorer I get the following error messages in my application.log
about 100 times (after the crash the file is 1000 rows long).
The memory that instance consumes grows constantly until the
application does not react anymore and needs to be shut down
manually.

--\\
04 May 2011 17:48:52,718 INFO ~ Starting /srv/instance_prod
04 May 2011 17:48:52,727 WARN ~ Declaring modules in application.conf
is deprecated. Use dependencies.yml instead (module.secure)
04 May 2011 17:48:52,727 INFO ~ Module secure is available (/srv/play/
modules/secure)
04 May 2011 17:48:52,727 WARN ~ Declaring modules in application.conf
is deprecated. Use dependencies.yml instead (module.ivy)
04 May 2011 17:48:52,728 INFO ~ Module ivy is available (/srv/play/
modules/ivy-1.0.1)
04 May 2011 17:48:53,016 INFO ~ Precompiling ...
04 May 2011 17:49:09,591 INFO ~ Connected to jdbc:mysql://localhost:
3306/instance_prod?
autoReconnect=true&useUnicode=true&characterEncoding=UTF-8
04 May 2011 17:49:13,463 INFO ~ Application 'instance_prod' is now
started !
04 May 2011 17:49:13,802 INFO ~ Migrate Datasource:
com.mchange.v2.c3p0.ComboPooledDataSource [ acquireIncrement -> 3,
acquireRetryAttempts -> 10, acquireRetryDelay -> 1000,
autoCommitOnClose -> false, automaticTestTable -> null,
breakAfterAcquireFailure -> false, checkoutTimeout -> 5000,
connectionCustomizerClassName -> null, connectionTesterClassName ->
com.mchange.v2.c3p0.impl.DefaultConnectionTester, dataSourceName ->
mypz828f1g6v971obhhnh|7860e590, debugUnreturnedConnectionStackTraces -
> false, description -> null, driverClass -> com.mysql.jdbc.Driver,
factoryClassLocation -> null, forceIgnoreUnresolvedTransactions ->
false, identityToken -> mypz828f1g6v971obhhnh|7860e590,
idleConnectionTestPeriod -> 10, initialPoolSize -> 3, jdbcUrl ->
jdbc:mysql://localhost:3306/instance_prod?
autoReconnect=true&useUnicode=true&characterEncoding=UTF-8,
maxAdministrativeTaskTime -> 0, maxConnectionAge -> 0, maxIdleTime ->
0, maxIdleTimeExcessConnections -> 0, maxPoolSize -> 30, maxStatements
-> 0, maxStatementsPerConnection -> 0, minPoolSize -> 1,
numHelperThreads -> 3, numThreadsAwaitingCheckoutDefaultUser -> 0,
preferredTestQuery -> null, properties -> {user=******,
password=******}, propertyCycle -> 0, testConnectionOnCheckin -> true,
testConnectionOnCheckout -> false, unreturnedConnectionTimeout -> 0,
usesTraditionalReflectiveProxies -> false ]
04 May 2011 17:49:14,119 INFO ~ Current schema version:
20110316123456
04 May 2011 17:49:14,123 INFO ~ Schema is up to date. No migration
necessary.
04 May 2011 17:49:14,123 INFO ~ 0 migrations applied
04 May 2011 17:49:14,259 INFO ~ Listening for HTTPS on port 443 ...
04 May 2011 17:53:14,369 ERROR ~
java.io.IOException: Connection reset by peer
at sun.nio.ch.FileDispatcher.read0(Native Method)
at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:21)
at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:237)
at sun.nio.ch.IOUtil.read(IOUtil.java:204)
at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:236)
at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:
321)
at
org.jboss.netty.channel.socket.nio.NioWorker.processSelectedKeys(NioWorker.java:
280)
at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:
200)
at java.util.concurrent.ThreadPoolExecutor
$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor
$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
04 May 2011 17:53:14,385 ERROR ~
.
.
.
--//

later on the I get additional messages (probably follow up errors):
--\\
04 May 2011 17:53:23,981 ERROR ~
java.io.IOException: Connection reset by peer
at sun.nio.ch.FileDispatcher.write0(Native Method)
at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:29)
at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:100)
at sun.nio.ch.IOUtil.write(IOUtil.java:56)
at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:334)
at org.jboss.netty.channel.socket.nio.SocketSendBufferPool
$PooledSendBuffer.transferTo(SocketSendBufferPool.java:239)
at org.jboss.netty.channel.socket.nio.NioWorker.write0(NioWorker.java:
469)
at
org.jboss.netty.channel.socket.nio.NioWorker.writeFromTaskLoop(NioWorker.java:
392)
at org.jboss.netty.channel.socket.nio.NioSocketChannel
$WriteTask.run(NioSocketChannel.java:276)
at
org.jboss.netty.channel.socket.nio.NioWorker.processWriteTaskQueue(NioWorker.java:
268)
at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:
199)
at java.util.concurrent.ThreadPoolExecutor
$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor
$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
--//

--\\
04 May 2011 17:53:23,982 ERROR ~
java.nio.channels.ClosedChannelException
at
org.jboss.netty.channel.socket.nio.NioWorker.cleanUpWriteBuffer(NioWorker.java:
636)
at
org.jboss.netty.channel.socket.nio.NioWorker.writeFromUserCode(NioWorker.java:
369)
at
org.jboss.netty.channel.socket.nio.NioServerSocketPipelineSink.handleAcceptedSocket(NioServerSocketPipelineSink.java:
137)
at
org.jboss.netty.channel.socket.nio.NioServerSocketPipelineSink.eventSunk(NioServerSocketPipelineSink.java:
76)
at
org.jboss.netty.handler.ssl.SslHandler.flushPendingEncryptedWrites(SslHandler.java:
767)
at org.jboss.netty.handler.ssl.SslHandler.wrap(SslHandler.java:711)
at
org.jboss.netty.handler.ssl.SslHandler.handleDownstream(SslHandler.java:
446)
at
org.jboss.netty.handler.codec.oneone.OneToOneEncoder.handleDownstream(OneToOneEncoder.java:
68)
at org.jboss.netty.channel.Channels.write(Channels.java:632)
at
org.jboss.netty.handler.stream.ChunkedWriteHandler.discard(ChunkedWriteHandler.java:
169)
at
org.jboss.netty.handler.stream.ChunkedWriteHandler.handleUpstream(ChunkedWriteHandler.java:
143)
at
org.jboss.netty.handler.codec.replay.ReplayingDecoder.cleanup(ReplayingDecoder.java:
554)
at
org.jboss.netty.handler.codec.replay.ReplayingDecoder.channelClosed(ReplayingDecoder.java:
455)
at
org.jboss.netty.handler.codec.frame.FrameDecoder.cleanup(FrameDecoder.java:
344)
at
org.jboss.netty.handler.codec.frame.FrameDecoder.channelClosed(FrameDecoder.java:
232)
at org.jboss.netty.channel.Channels.fireChannelClosed(Channels.java:
404)
at org.jboss.netty.channel.socket.nio.NioWorker.close(NioWorker.java:
593)
at org.jboss.netty.channel.socket.nio.NioWorker.write0(NioWorker.java:
512)
at
org.jboss.netty.channel.socket.nio.NioWorker.writeFromTaskLoop(NioWorker.java:
392)
at org.jboss.netty.channel.socket.nio.NioSocketChannel
$WriteTask.run(NioSocketChannel.java:276)
at
org.jboss.netty.channel.socket.nio.NioWorker.processWriteTaskQueue(NioWorker.java:
268)
at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:
199)
at java.util.concurrent.ThreadPoolExecutor
$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor
$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
--//

Interestingly this can be reproduced with the Internet Explorer
mentioned above but not that easy with Internet Explorer on other
machines or using Firefox.
However the Play! should never produce such exceptions...

Does anybody has an idea what the problem could be? Is it maybe a bug
in the newly introduced SSL support?

Thanks
AMT_EB

[Nicolas Leroux]

Hi,

Can you report a bug in lighthouse please?

Thanks,

Nicolas

> --
> You received this message because you are subscribed to the Google Groups "play-framework" group.
> To post to this group, send email to play-fr...@googlegroups.com.
> To unsubscribe from this group, send email to play-framewor...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/play-framework?hl=en.
>

[AMT_EB]

Hi Nicolas

I did create a bug report.

Before SSL support was introduced in Play you had (as far as I know)
to create a java keystore file for Apache.
Would that solve my problem? As there are no guarantees when bugs are
fixed I need to check for alternatives.

Thanks
AMT_EB

[Nicolas Leroux]

Hi,

You can still use a java keystore as well. However, I am not so sure it will solves you problem, because I think it is a low level problem (Netty). An alternative solution will be to use a front end proxy (apache/nginx) that forward receive HTTPS and then having play working in HTTP. You can check the play documentation for an example.

Nicolas

[AMT_EB]

Hi Nicolas

I like your idea of encrypting the way to the server and handling the
internal communication over http.

Unfortunately I couldn't find that example in the documentation. All I
could find was "Put your application in production" and there the
article about using Apache as a front-end http server is not very
detailed (for my knowledge level).

Could you please give me a hint where I can find the necessary
information to set this up correctly?
Alternatively could you please let me know if my assumption of the
setup is correct:

- I use Apache as proxy server
- I define a virtual host for port 443
- I install the SSL certificate for that virutal host
- I configure the virtual host to redirect the traffic to port 9000
- I configure my play application to run on port 9000

Thanks a lot!
AMT_EB