Re: [OT] is tomcat monitoring the keystore file?

2017-10-30 Thread Christopher Schultz 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mark,

On 10/26/17 4:55 PM, Mark Thomas wrote:
> On 26/10/17 20:17, Christopher Schultz wrote:
> 
> 
> 
>> So this is relying on the OpenSSLContext.finalize() method to
>> clean-up after the native SSL context?
> 
> Correct.
> 
>> It's been "recommended" to not rely on finalizers for quite a
>> long time. Is that advice no longer correct?
> 
> Like most general rules there are exceptions. Arguably, this is one
> of them. The alternative would require an awful lot of code to
> replicate what the JVM is already doing.

Yes. When we spoke in person, we were both a little concerned about
doing things like reference-counting to make sure that long-lived
connections such as Websockets didn't get cut-off at the knees while
also avoiding memory leaks.

I think use of a finalizer is the correct solution.

> I believe there are better options available in Java 9.

Such as? I haven't looked at Java 9 very closely at all.

>> I'm particularly concerned about native memory leaks.
> 
> The argument against finalizers is that they might never run as the
> JVM could shutdown before they are called. In this case, that
> doesn't present a problem.

+1

> We'd have a problem if an object could be GC'd without the
> finializer running. I'm not aware of any scenarios where that
> happens.

Okay, good.

My biggest concern is that the GC will take the laziest route and
simply NEVER call the finalizer -- and also not GC the object. I can't
imagine how the GC could know which objects might be "complicated" to
finalize and for some reason decide to just stuff them in the closet
forever.

I just wanted to bring up the subject to make sure it was a deliberate
decision. Thanks for clarifying.

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAln3NmMACgkQHPApP6U8
pFiB4A//a3rDY2ZV3iJHIvWb/DdrI5riqAO12bZWkNbF3e7FDSxrXx/0X8/+pu3O
9laCZzVyFeRUdzIXXbtRVaI2gf8a1ZMve9UagciFwhkO0Z4IdzvXhEFDTyjmRo1c
bVlgdGFWEHzs+b/snM/H8y4Ak1J3Psr3UNz6GeZjH93cogJ9OWUouqRLYpWzPdtW
XHqXAg/p3H15FVc1Anwre8h2jVcDFy9G2d0dBODnq/oTHCYaErDQ6cS//jUfPlNZ
L848Tp0lB+FZQcSdraQsjATdP/gPpsgmbHbS1r39wOjAf7VSZdLlZFXvDuv0KB2l
rkQJ/C5sO1mHwSQNghcNDjLoCZ6mjPQMtfHLNy2Q/CY3dFt8YAt4f/ITY/H2f7Kd
kmUPAyyGDDpDQenjAZQQ+C60NqqEa6JPTUn5n2+a9520VKviWaWvupjUn3u7XRot
eQu614ikiR09M4diLvslkCH/0bBqgagdNJ70D2qqCT2F2IUGCZlDz+LaJokkwF3m
jaw+WhVRQs+PkWHTYYecYrTCbS6kxQZJsyPjUNPeChxNccVI+s2K7BRsvGiQz/Pa
TujcguxY3+6rphEGp49edZqIFoUb/90NxCXZZpC7PEUnyy67dut4PUUqpie2LOfD
hnha9vUHj2DG74JljZghHWV5W5Un5fDbPfBSnt5h5JVJzqHBvIM=
=R0Ch
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: [OT] is tomcat monitoring the keystore file?

2017-10-26 Thread Mark Thomas 
On 26/10/17 20:17, Christopher Schultz wrote:



> So this is relying on the OpenSSLContext.finalize() method to clean-up
> after the native SSL context?

Correct.

> It's been "recommended" to not rely on
> finalizers for quite a long time. Is that advice no longer correct?

Like most general rules there are exceptions. Arguably, this is one of
them. The alternative would require an awful lot of code to replicate
what the JVM is already doing.

I believe there are better options available in Java 9.

> I'm particularly concerned about native memory leaks.

The argument against finalizers is that they might never run as the JVM
could shutdown before they are called. In this case, that doesn't
present a problem.

We'd have a problem if an object could be GC'd without the finializer
running. I'm not aware of any scenarios where that happens.

Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: [OT] is tomcat monitoring the keystore file?

2017-10-26 Thread Christopher Schultz 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mark,

On 10/26/17 12:07 PM, Mark Thomas wrote:
> On 26 October 2017 14:36:03 BST, Christopher Schultz
>  wrote:
>> Mark,
>> 
>> On 10/26/17 8:54 AM, Mark Thomas wrote:
>>> On 26/10/2017 09:31, Johan Compagner wrote:
 Hi,
 
 now with LetsCrypt its easy (and free) to get https up and 
 running even if you just use tomcat But the problem is those 
 certificate must be renewed every 3 months This is easy to do
 in a crontab script (that does the renew and makes a java
 keystore again) So i can generate the pfx constantly just
 fine
 
 But does tomcat monitor that file for changes and will it
 then use the new one without restarting the whole server?
>>> 
>>> Currently, no.
>>> 
>>> We have just added the ability to 9.0.x and 8.5.x to reload the
>>>  certificate file on the fly.
>> 
>> Can you point me to some specific commits that implement that?
>> I've been dragging my feet on the work to reload *everything* and
>> if the cert-reloading has already been done, then it seems that
>> most -- if not all -- the work I expected to do is already done.
> 
> http://svn.apache.org/viewvc?view=revision=1808482
> 
> Mark
> 
>> 
>> One of the reasons I hadn't done it yet was because I wasn't
>> sure about which of the many Tomcat components should warehouse
>> that code... there are so many layers and I don't understand
>> exactly which ones are responsible for what things.
>> 
>> Do these patches include replacing the SSLContext, or only the
>> key material that is being used for the handshake for an
>> existing SSLContext ?
> 
> It provides a new SSLContext that will be used for all new
> connections.

Thanks.

So this is relying on the OpenSSLContext.finalize() method to clean-up
after the native SSL context? It's been "recommended" to not rely on
finalizers for quite a long time. Is that advice no longer correct?

I'm particularly concerned about native memory leaks.

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQJRBAEBCAA7FiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlnyNM8dHGNocmlzQGNo
cmlzdG9waGVyc2NodWx0ei5uZXQACgkQHPApP6U8pFh4Eg/+OJdiVLJp4XhPGvd4
kPvUmebwXez+f6JYFORqurxavbKk/i+4ttA9qls3iezxU/uABUY7LpUaHekFQK2m
dvCHv9/A7tF3lti6vY46UUUzp0t/3eJCBYl5lyQ/HRvNfacfhfTckaAYe/+1BiqB
Sj/75y5S5kV6tCJJMOiDIeitXhD/n8CzlJ6S4ReTVT9zuFNA0dShdH3LXeJJmQL3
RnWsxDZDkBDA9k3cH82tufJgCsez7GKDQBmitIlwNpf3Za4v4+QX4djDe0QdPjT8
WL62TaiDJvSjjIpR/j6eHxu6b7JO0orXyfT2LuiTQg7hPktCU+c1u2ePTUbx1NgF
v0gBXIBlTydbykw5tNPhA5vTEl7fSms45Uf7SJJz+ET8RgeU6G7JsAaAHRe+KKor
Xs8xMJMZyvz7SmW76pdkEVd8H+oYSUODbWVbLxMol3f7dZ7WqjsOt5jDoMHenzch
1A2168LQ3eZqSIRto00AnDVXUhEkIMLe6t9PKb+RGZ1CMEgvY3zqYtbkVIjbchf0
Q9GotkU/aSMLnEgJadY71HRhDGmZfDGx6PJZWG1BTQFHJO5al7hq8vxZhMBJPtiq
KOrbl6ydVVkWxKNjSaN/UAS309SQCrxVv9BYOS54GU5wzrCqo58Y3tTxWdXpXQpD
iSn0i2y+ujRDGFUeUdxuPqFkj3U=
=xwUc
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: [OT] is tomcat monitoring the keystore file?

2017-10-26 Thread Mark Thomas 
On 26 October 2017 14:36:03 BST, Christopher Schultz 
 wrote:
>Mark,
>
>On 10/26/17 8:54 AM, Mark Thomas wrote:
>> On 26/10/2017 09:31, Johan Compagner wrote:
>>> Hi,
>>> 
>>> now with LetsCrypt its easy (and free) to get https up and
>>> running even if you just use tomcat But the problem is those
>>> certificate must be renewed every 3 months This is easy to do in
>>> a crontab script (that does the renew and makes a java keystore
>>> again) So i can generate the pfx constantly just fine
>>> 
>>> But does tomcat monitor that file for changes and will it then
>>> use the new one without restarting the whole server?
>> 
>> Currently, no.
>> 
>> We have just added the ability to 9.0.x and 8.5.x to reload the 
>> certificate file on the fly.
>
>Can you point me to some specific commits that implement that? I've
>been dragging my feet on the work to reload *everything* and if the
>cert-reloading has already been done, then it seems that most -- if
>not all -- the work I expected to do is already done.

http://svn.apache.org/viewvc?view=revision=1808482

Mark

>
>One of the reasons I hadn't done it yet was because I wasn't sure
>about which of the many Tomcat components should warehouse that
>code... there are so many layers and I don't understand exactly which
>ones are responsible for what things.
>
>Do these patches include replacing the SSLContext, or only the key
>material that is being used for the handshake for an existing
>SSLContext
>?

It provides a new SSLContext that will be used for all new connections.

Mark



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: is tomcat monitoring the keystore file?

2017-10-26 Thread James H. H. Lampert 

On 26/10/2017 09:31, Johan Compagner wrote:
. . .

But does tomcat monitor that file for changes and will it then use
the new one without restarting the whole server?


On 10/26/17, 5:54 AM, Mark Thomas replied:

Currently, no.

We have just added the ability to 9.0.x and 8.5.x to reload the
certificate file on the fly.

. . .

I was wondering about that myself; I know from experience that it 
definitely does NOT hot-switch to a new keystore when running on an 
AS/400, but wasn't sure about other platforms.


--
JHHL

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: [OT] is tomcat monitoring the keystore file?

2017-10-26 Thread Christopher Schultz 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mark,

On 10/26/17 8:54 AM, Mark Thomas wrote:
> On 26/10/2017 09:31, Johan Compagner wrote:
>> Hi,
>> 
>> now with LetsCrypt its easy (and free) to get https up and
>> running even if you just use tomcat But the problem is those
>> certificate must be renewed every 3 months This is easy to do in
>> a crontab script (that does the renew and makes a java keystore
>> again) So i can generate the pfx constantly just fine
>> 
>> But does tomcat monitor that file for changes and will it then
>> use the new one without restarting the whole server?
> 
> Currently, no.
> 
> We have just added the ability to 9.0.x and 8.5.x to reload the 
> certificate file on the fly.

Can you point me to some specific commits that implement that? I've
been dragging my feet on the work to reload *everything* and if the
cert-reloading has already been done, then it seems that most -- if
not all -- the work I expected to do is already done.

One of the reasons I hadn't done it yet was because I wasn't sure
about which of the many Tomcat components should warehouse that
code... there are so many layers and I don't understand exactly which
ones are responsible for what things.

Do these patches include replacing the SSLContext, or only the key
material that is being used for the handshake for an existing SSLContext
?

> It should be relatively easy to add a component that watches for 
> changes to the cert file (or any of the other files) and trigger a 
> reload as required. I suggest opening an enhancement request in 
> Bugzilla.

+1

> Whether it is a whole new component or just something that gets
> added to the existing back ground processing framework for an
> existing component is TBD.
> 
> If you'd like to work on a patch to implement this, pop over to the
> dev list and we'll point you in the right direction.

- -chris

-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlnx5MMACgkQHPApP6U8
pFjxfw//aKlCe4jMAFdLP1djFjcmlO3vfmrFaf+mHdhLS4c6WMSk4+yIxzUsowDx
TeKpdGOK02RTVRg1MC9AB5Y00H5bs5ztuOOdYMODS4qMzKm69NJTURuAraWJ1hbi
vvn+8Yg77P8/6MDBwoooh3z96WpDENbP3ROZan3reWf2ViBPBbVyoNbNb1pESvow
ZKFzP6fntKc1ecqOxmXPj3Uu0R0pul4FF16CSz6JD2T90Ws9Rf8vAqd54F/RKngn
2WrKtTr08F2kZoSo+qI6O21dUcbEWh8gvtaLtPNMo4YpIqZsE7mXfU3ZDSEKLK+q
pQPQluICNt+5QPaYIKIqy20t2mAFS/K2QSnIdkGqJuEt4wXYuZ45x3rck5VpC8tJ
P9+NcQmS2hUqeJKjWDLX98W6H5BsEAsX6gGZP9beA7RsBOk+7TmL+MRGf+BOI3Cy
dJ845nM3ecnhlz7OtIvJopC87QM0LpWKAtbKkqHLShzo4lXgaDzcyCOb6m/ozGGG
mhesNbX5fDZfUI4dMR95Wgp5Xpvf2drYszvWCnl/cgtEYc+anUh47ADNIc8h6KnF
KLXBOAV+MuVEWFIi1HfCWrpwoIYQQGNTsYlBSEvNsBUd20IGQ25+xII4ERtXKXbA
fw2OHtgqtF2KtHsIwLXFaMHJN+EXIRPbMY/Fwu04A5utGN6iVfw=
=yrp/
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: is tomcat monitoring the keystore file?

2017-10-26 Thread Mark Thomas 
On 26/10/2017 09:31, Johan Compagner wrote:
> Hi,
> 
> now with LetsCrypt its easy (and free) to get https up and running even if
> you just use tomcat
> But the problem is those certificate must be renewed every 3 months
> This is easy to do in a crontab script (that does the renew and makes a
> java keystore again)
> So i can generate the pfx constantly just fine
> 
> But does tomcat monitor that file for changes and will it then use the new
> one without restarting the whole server?

Currently, no.

We have just added the ability to 9.0.x and 8.5.x to reload the
certificate file on the fly. It should be relatively easy to add a
component that watches for changes to the cert file (or any of the other
files) and trigger a reload as required. I suggest opening an
enhancement request in Bugzilla.

Whether it is a whole new component or just something that gets added to
the existing back ground processing framework for an existing component
is TBD.

If you'd like to work on a patch to implement this, pop over to the dev
list and we'll point you in the right direction.

Mark


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

is tomcat monitoring the keystore file?

2017-10-26 Thread Johan Compagner 
Hi,

now with LetsCrypt its easy (and free) to get https up and running even if
you just use tomcat
But the problem is those certificate must be renewed every 3 months
This is easy to do in a crontab script (that does the renew and makes a
java keystore again)
So i can generate the pfx constantly just fine

But does tomcat monitor that file for changes and will it then use the new
one without restarting the whole server?


-- 
Johan Compagner
Servoy