Re: RFR [9] 8035897 : FD_SETSIZE should be set on macosx

2014-08-18 Thread Christos Zoulas
On Aug 18, 5:42pm, fwei...@redhat.com (Florian Weimer) wrote: -- Subject: Re: RFR [9] 8035897 : FD_SETSIZE should be set on macosx | On 08/18/2014 05:36 PM, Christos Zoulas wrote: | > On Aug 18, 5:10pm, fwei...@redhat.com (Florian Weimer) wrote: | > -- Subject: Re: RFR [9] 8035897 : FD_SETSIZE s

Re: RFR [9] 8035897 : FD_SETSIZE should be set on macosx

2014-08-18 Thread Florian Weimer
On 08/18/2014 05:36 PM, Christos Zoulas wrote: On Aug 18, 5:10pm, fwei...@redhat.com (Florian Weimer) wrote: -- Subject: Re: RFR [9] 8035897 : FD_SETSIZE should be set on macosx | On 02/28/2014 03:40 PM, Chris Hegarty wrote: | > Either: | > 1) FD_SETSIZE needs to be set to a larger value, but

Re: RFR [9] 8035897 : FD_SETSIZE should be set on macosx

2014-08-18 Thread Christos Zoulas
On Aug 18, 5:10pm, fwei...@redhat.com (Florian Weimer) wrote: -- Subject: Re: RFR [9] 8035897 : FD_SETSIZE should be set on macosx | On 02/28/2014 03:40 PM, Chris Hegarty wrote: | > Either: | > 1) FD_SETSIZE needs to be set to a larger value, but what value, the | > kernel limit, or other?

Re: sun.net.www.protocol.https.HttpsURLConnectionImpl doesn't equal to self

2014-08-18 Thread Michael McMahon
I'll file a bug for this Stanimir. Thanks for reporting it. Should be able to fix it in JDK 9 fairly promptly and we'll see about back porting it then. - Michael. On 18/08/14 15:04, Stanimir Simeonoff wrote: Hi, As the title says there is a major bug with HttpsURLConnection as it breaks the co

Re: RFR [9] 8035897 : FD_SETSIZE should be set on macosx

2014-08-18 Thread Florian Weimer
On 02/28/2014 03:40 PM, Chris Hegarty wrote: Either: 1) FD_SETSIZE needs to be set to a larger value, but what value, the kernel limit, or other? This is wasteful for most typical apps that don't use large numbers of file descriptors. Or, 2) If fd is greater than 1024, then an appro

Re: AES GCM slow

2014-08-18 Thread Florian Weimer
On 01/27/2014 05:46 PM, Michael StJohns wrote: GCM uses a GF2 multiply as part of the integrity calculation. That operation is pretty expensive. My guess is that if the code was profiled, you'd find a lot of time being spent in com.sun.crypto.provider.GHASH. I ran into this and posted a fix: