Hi Ivan,
I understand the desire of performance improvement. But I don't think
avoiding the use of cache is the price we want to pay for. Besides,
avoiding using of session cache is not something improving the
performance in general, it is typically something impacting the
performance, a
Gentle ping.
If people agree on the approach, I'll go ahead and file a CCC request
for the new recognized system property.
With kind regards,
Ivan
On 11/7/17 6:24 PM, Ivan Gerasimov wrote:
Hello everybody!
The class sun.security.ssl.SSLSessionContextImpl maintains caches for
the
One thing that springs to mind. Some allowance would have to be made
for domain combiners and JAAS Subject propagation: this mechanism also
uses access control contexts, to its own great detriment. I would say
that the JAAS domain combiner strategy should be dropped in favor of a
simple thread
On 11/20/2017 12:34 PM, Michael StJohns wrote:
On 11/20/2017 1:10 PM, Jamil Nimeh wrote:
You're missing the point that setParameter() provides information
used in all future calls to the signature generation, while init()
provides data specifically for a given key stream production. In
Yes Alan correct: I wrongly asumed ist a separate stack. So it is a non-issue.
I tried it out and having a doPriv(lambda) block shortens the possible overall
thread dept by about 200 calls (with my simple stack usage).
BTW: the main thread does behave a bit less predictable: (run results at
On 11/20/2017 1:10 PM, Jamil Nimeh wrote:
You're missing the point that setParameter() provides information
used in all future calls to the signature generation, while init()
provides data specifically for a given key stream production. In
Signature() you call .setParameter() to set up the
Hello Alan,
not sure if it is good or bad to make the security manager even less Mainstream
(especially after there was a Project to reduce the Impact of security
Manager). However, not diving into this discussion here :)
One thing which might be a problem: when doPrivileged does no longer
On 11/20/2017 11:17 AM, Michael StJohns wrote:
One additional topic for discussion: Late in the week we talked about
the current state of the API internally and one item to revisit is
where the DerivationParameterSpec objects are passed. It was brought
up by a couple people that it would
This should help harden the test. Looks fine to me.
Regards,
Sean.
On 20/11/17 16:16, Rob McKenna wrote:
Hi folks,
This test appears to be timing out. The main culprit looks to be the
fact that the 100ms sleep isn't enough for the server to respond (on a
busy test machine) so that timeout has
Apologies in advance for top posting and a need to be a little pedantic
about KDFs. I'll have some comments inline below as well.
KDF's aren't well understood but people think they are. The key stream
generation part is pretty straightforward (keyed PRBG), but the
interaction of how the key
Hi folks,
This test appears to be timing out. The main culprit looks to be the
fact that the 100ms sleep isn't enough for the server to respond (on a
busy test machine) so that timeout has been bumped and some new logging
has been added to make it obvious whats happening should the problem
occur
On 11/19/2017 3:15 PM, Michael StJohns wrote:
That behavior all sounds reasonable, I just have doubts that this
belongs in the spec. Are you expecting KeyDerivation to contain the
logic in your last paragraph? Something like this:
KDFs are somewhat problematic in that *_they may not
On 11/20/2017 5:12 AM, Jamil Nimeh wrote:
On 11/19/2017 12:45 PM, Michael StJohns wrote:
On 11/17/2017 1:07 PM, Adam Petcher wrote:
I agree that this is challenging because there is so much variety in
KDFs. But I don't think that SP 800-108 is a good example of
something that should be
One of the long standing issues with the security manager support is
that the overhead when there is no security manager is non-zero. Two
specific examples are (i) the overhead of defineClass (assuming the
defining loader is a SecureClassLoader) as it involves a callback to get
the
On 11/19/2017 12:45 PM, Michael StJohns wrote:
On 11/17/2017 1:07 PM, Adam Petcher wrote:
On 11/17/2017 10:04 AM, Michael StJohns wrote:
On 11/16/2017 2:15 PM, Adam Petcher wrote:
So it seems like they could all be supplied to init. Alternatively,
algorithm names could specify more
15 matches
Mail list logo
