Re: ERR_SPDY_COMPRESSION_ERROR (http2)

2016-12-19 Thread Sreeraj V P 
yes.. started download.. hadnt waited to complete.

Sent from BlueMail ​

On 19 Dec 2016, 3:27 p.m., at 3:27 p.m., Durga Srinivasu Karuturi 
 wrote:
>Mark,
>
>Looks like tar/zip attachments are getting removed.
>
>Uploaded same in google drive now.
>
>Please let me know if you can access the same or not.
>
>https://drive.google.com/open?id=0B1OzquDqWi6bVUN0MDk2RDFENG8
>
>Thanks,
>Durga Srinivasu
>
>
>On Mon, Dec 19, 2016 at 3:21 PM, Durga Srinivasu Karuturi <
>durgasriniv...@gmail.com> wrote:
>
>> Mark,
>>
>> Attaching the modified ROOT web-app from tomcat 8.5.9 bundle. Just
>changed
>> index.jsp and added lib [mostly DOJO] folder content to reproduce.
>>
>> If we deploy this in latest 8.5.9 with http2 enabled in chrome we are
>> seeing the SPDY compression errors
>>
>> Please let me know if this helps.
>>
>> Thanks,
>> Durga Srinivasu
>>
>>
>>
>> On Mon, Dec 19, 2016 at 2:31 PM, Mark Thomas 
>wrote:
>>
>>> On 17/12/2016 06:35, Durga Srinivasu Karuturi wrote:
>>> > Do i need to post in any other forum?
>>>
>>> No, you are in the right place.
>>>
>>> You mentioned the issue was reproducible with the Dojo libraries. If
>you
>>> can provide the simplest possible set of steps to recreate this
>issue
>>> from a clean Tomcat 8.5.9 install that would be a big help.
>>>
>>> Mark
>>>
>>> >
>>> > Thanks,
>>> > Durga Srinivasu
>>> >
>>> > On Thu, Dec 15, 2016 at 6:41 PM, Durga Srinivasu Karuturi
>>> > >
>wrote:
>>> >
>>> > Hi,
>>> >
>>> > Any pointers please?
>>> >
>>> > Thanks,
>>> > Durga Srinivasu
>>> >
>>> > On Wed, Dec 14, 2016 at 10:15 PM, Durga Srinivasu Karuturi
>>> > >
>wrote:
>>> >
>>> > Hi,
>>> >
>>> > Recent chrome  [Mac - Sierra : Version  55.0.2883.87
>(64-bit) ]
>>> we are seeing issues in http2 sites.
>>> >
>>> >
>>> > Initially we have seen problem with http2 table header
>size
>>> limit error and to fix this, we have upgraded tomcat 8.5.4 to 8.5.9
>where
>>> tomcat has increased the header limit from 16K to 64K.
>>> >
>>> >
>>> > Now with latest tomcat 8.5.9 we are seeing
>>> ERR_SPDY_COMPRESSION_ERROR while loading dojo libraries.
>>> >
>>> > Tried couple of steps (flush SPDY sokets etc) based on
>google
>>> search on this issue but nothing worked..
>>> >
>>> >
>>> > Inline image 1
>>> >
>>> > t=10513 [st= 1] -HTTP_TRANSACTION_SEND_REQUEST
>>> >
>>> > t=10513 [st= 1] +HTTP_TRANSACTION_READ_HEADERS 
>[dt=36]
>>> >
>>> > t=10549 [st=37]HTTP2_STREAM_ERROR
>>> >
>>> >--> description = "ABANDONED
>>> > (stream_id=139):
>>> > https://10.104.118.174/webacs/lib/dijit/form/_ToggleB
>>> uttonMixin.js.map
>>> >
>>> Mixin.js.map>"
>>> >
>>> >--> status = -363
>>> >
>>> >--> stream_id = 139
>>> >
>>> > t=10549 [st=37] -HTTP_TRANSACTION_READ_HEADERS
>>> >
>>> > * --> net_error = -363
>>> > (ERR_SPDY_COMPRESSION_ERROR)*
>>> >
>>> > t=10549 [st=37]   -URL_REQUEST_START_JOB
>>> >
>>> > *   --> net_error = -363
>>> > (ERR_SPDY_COMPRESSION_ERROR)*
>>> >
>>> > t=10549 [st=37]URL_REQUEST_DELEGATE  [dt=0]
>>> >
>>> > t=10549 [st=37] -REQUEST_ALIVE
>>> >
>>> >  --> net_error = -363
>>> (ERR_SPDY_COMPRESSION_ERROR)
>>> >
>>> >
>>> > Initial content is downloaded (other JS files etc) but on
>some
>>> dojo libraries alone, we are this issue which make application home
>page
>>> load fails.
>>> >
>>> >
>>> > Firefox works!
>>> >
>>> >
>>> > We are having latest tomcat 8.5.9 already. Not sure where
>else
>>> problem now. We have not enabled any compression server side.
>>> >
>>> >
>>> >
>https://bugs.chromium.org/p/chromium/issues/detail?id=673315
>>> >
>
>>> (Chrome bugs i have raised)
>>> >
>>> > My guess is that the bug is in Tomcat, in that it does
>not
>>> send an HPACK dynamic table size update (so the dynamic table should
>be the
>>> default 4 kB) but uses a 64 kB dynamic table.
>>> > As soon as it references entries that are in fact
>already
>>> emitted, that's a compression error.
>>> > See https://www.ietf.org/mail-arch
>>> ive/web/httpbisa/current/msg27867.html
>>> >
>>> 27867.html> for a discussion on how to interpret the specs.
>>> >
>>> > According to the chrome bug notes problem is with tome
>dynamic
>>> table size 64k. I don't know how to confirm this is as tomcat issue
>as well.
>>> >
>>> > Can somebody help here

Re: ERR_SPDY_COMPRESSION_ERROR (http2)

2016-12-19 Thread Durga Srinivasu Karuturi 
Its ~5MB file (ROOT app tar bundle).

I hope the information, which i have shared so far is useful enough to
reproduce the problem locally.

Please let me know if i missed any other information.

Thanks,
Durga Srinivasu


On Tue, Dec 20, 2016 at 7:42 AM, Sreeraj V P  wrote:

> yes.. started download.. hadnt waited to complete.
>
> Sent from BlueMail ​
>
> On 19 Dec 2016, 3:27 p.m., at 3:27 p.m., Durga Srinivasu Karuturi <
> durgasriniv...@gmail.com> wrote:
> >Mark,
> >
> >Looks like tar/zip attachments are getting removed.
> >
> >Uploaded same in google drive now.
> >
> >Please let me know if you can access the same or not.
> >
> >https://drive.google.com/open?id=0B1OzquDqWi6bVUN0MDk2RDFENG8
> >
> >Thanks,
> >Durga Srinivasu
> >
> >
> >On Mon, Dec 19, 2016 at 3:21 PM, Durga Srinivasu Karuturi <
> >durgasriniv...@gmail.com> wrote:
> >
> >> Mark,
> >>
> >> Attaching the modified ROOT web-app from tomcat 8.5.9 bundle. Just
> >changed
> >> index.jsp and added lib [mostly DOJO] folder content to reproduce.
> >>
> >> If we deploy this in latest 8.5.9 with http2 enabled in chrome we are
> >> seeing the SPDY compression errors
> >>
> >> Please let me know if this helps.
> >>
> >> Thanks,
> >> Durga Srinivasu
> >>
> >>
> >>
> >> On Mon, Dec 19, 2016 at 2:31 PM, Mark Thomas 
> >wrote:
> >>
> >>> On 17/12/2016 06:35, Durga Srinivasu Karuturi wrote:
> >>> > Do i need to post in any other forum?
> >>>
> >>> No, you are in the right place.
> >>>
> >>> You mentioned the issue was reproducible with the Dojo libraries. If
> >you
> >>> can provide the simplest possible set of steps to recreate this
> >issue
> >>> from a clean Tomcat 8.5.9 install that would be a big help.
> >>>
> >>> Mark
> >>>
> >>> >
> >>> > Thanks,
> >>> > Durga Srinivasu
> >>> >
> >>> > On Thu, Dec 15, 2016 at 6:41 PM, Durga Srinivasu Karuturi
> >>> > >
> >wrote:
> >>> >
> >>> > Hi,
> >>> >
> >>> > Any pointers please?
> >>> >
> >>> > Thanks,
> >>> > Durga Srinivasu
> >>> >
> >>> > On Wed, Dec 14, 2016 at 10:15 PM, Durga Srinivasu Karuturi
> >>> > >
> >wrote:
> >>> >
> >>> > Hi,
> >>> >
> >>> > Recent chrome  [Mac - Sierra : Version  55.0.2883.87
> >(64-bit) ]
> >>> we are seeing issues in http2 sites.
> >>> >
> >>> >
> >>> > Initially we have seen problem with http2 table header
> >size
> >>> limit error and to fix this, we have upgraded tomcat 8.5.4 to 8.5.9
> >where
> >>> tomcat has increased the header limit from 16K to 64K.
> >>> >
> >>> >
> >>> > Now with latest tomcat 8.5.9 we are seeing
> >>> ERR_SPDY_COMPRESSION_ERROR while loading dojo libraries.
> >>> >
> >>> > Tried couple of steps (flush SPDY sokets etc) based on
> >google
> >>> search on this issue but nothing worked..
> >>> >
> >>> >
> >>> > Inline image 1
> >>> >
> >>> > t=10513 [st= 1] -HTTP_TRANSACTION_SEND_REQUEST
> >>> >
> >>> > t=10513 [st= 1] +HTTP_TRANSACTION_READ_HEADERS
> >[dt=36]
> >>> >
> >>> > t=10549 [st=37]HTTP2_STREAM_ERROR
> >>> >
> >>> >--> description = "ABANDONED
> >>> > (stream_id=139):
> >>> > https://10.104.118.174/webacs/lib/dijit/form/_ToggleB
> >>> uttonMixin.js.map
> >>> >
> > >>> Mixin.js.map>"
> >>> >
> >>> >--> status = -363
> >>> >
> >>> >--> stream_id = 139
> >>> >
> >>> > t=10549 [st=37] -HTTP_TRANSACTION_READ_HEADERS
> >>> >
> >>> > * --> net_error = -363
> >>> > (ERR_SPDY_COMPRESSION_ERROR)*
> >>> >
> >>> > t=10549 [st=37]   -URL_REQUEST_START_JOB
> >>> >
> >>> > *   --> net_error = -363
> >>> > (ERR_SPDY_COMPRESSION_ERROR)*
> >>> >
> >>> > t=10549 [st=37]URL_REQUEST_DELEGATE  [dt=0]
> >>> >
> >>> > t=10549 [st=37] -REQUEST_ALIVE
> >>> >
> >>> >  --> net_error = -363
> >>> (ERR_SPDY_COMPRESSION_ERROR)
> >>> >
> >>> >
> >>> > Initial content is downloaded (other JS files etc) but on
> >some
> >>> dojo libraries alone, we are this issue which make application home
> >page
> >>> load fails.
> >>> >
> >>> >
> >>> > Firefox works!
> >>> >
> >>> >
> >>> > We are having latest tomcat 8.5.9 already. Not sure where
> >else
> >>> problem now. We have not enabled any compression server side.
> >>> >
> >>> >
> >>> >
> >https://bugs.chromium.org/p/chromium/issues/detail?id=673315
> >>> >
> >
> >>> (Chrome bugs i have raised)
> >>> >
> >>> > My guess is that the bug is in Tomcat, in that it does
> >not
> >>> send an HPACK dynamic table size update (so the dynamic table should
> >be the
> >>> default 4 kB)

Tomcat SSL or Apache SSL

2016-12-19 Thread Edwin Quijada 
Hi!

I am trying to use SSL with my server Tomcat . I have read different articles 
when it recommends that is better use Apache webserver in front of Tomcat to 
and apache handles the SSL conection. My problem is that I cannot use apache in 
front of Tomcat because I am using websockets and these doesnt work with apache 
in front of.


I read howto use Tomcat with SSL but I 'd like to know any comments from you 
about this.

 TIA

Re: Upgrade to 8.5.8/9

2016-12-19 Thread Coty Sutherland 
Hm, errno=111 is a connection refusal. Are you sure that your new
instance has an adequate number of threads available for httpd to
proxy to? Do you see any errors in your tomcat logging? If you do have
sufficient threads in the pool, then maybe there is something (like GC
pauses) hanging your requests that wasn't before and therefore
exhausting the pool causing rejections.

On Mon, Dec 19, 2016 at 4:47 AM, Greg Huber  wrote:
> Hello,
>
> I am currently running tomcat 8.0.32 and have tried to upgrade to 8.5.8 and
> 8.5.9 without success.  I use mod_jk to connect apache to tomcat running on
> centos 5.11 with Apache 2.2.3.
>
> I have installed openSSL 1.0.2.j to compile the native tomcat-native-1.2.10
> using apr-1.5.2 and tomcat-connectors-1.2.42 for the mod_jk.
>
> The problem is that tomcat seems to start but fails sometimes to connect
> correctly to apache and causes apache to hang.  If I stop tomcat, apache
> starts working again.  I have been through the logs with little indication
> of the problem.  If I revet back to 8.0.32 everything works OK.
>
>
> All I can find is this in the mod_jk.log:
>
>
> [Sat Dec 17 06:11:48 2016][3212:47280261211024] [info] init_jk::mod_jk.c
> (3595): mod_jk/1.2.42 initialized
> [Sat Dec 17 06:11:50 2016][3254:47280261211024] [info]
> jk_open_socket::jk_connect.c (817): connect to 127.0.0.1:8009 failed
> (errno=111)
> [Sat Dec 17 06:11:50 2016][3254:47280261211024] [info]
> ajp_connect_to_endpoint::jk_ajp_common.c (1068): (worker1) Failed opening
> socket to (127.0.0.1:8009) (errno=111)
> [Sat Dec 17 06:11:50 2016][3254:47280261211024] [error]
> ajp_send_request::jk_ajp_common.c (1728): (worker1) connecting to backend
> failed. Tomcat is probably not started or is listening on the wrong port
> (errno=111)
> [Sat Dec 17 06:11:50 2016][3254:47280261211024] [info]
> ajp_service::jk_ajp_common.c (2778): (worker1) sending request to tomcat
> failed (recoverable), because of error during request sending (attempt=1)
> [Sat Dec 17 06:11:50 2016][3254:47280261211024] [info]
> jk_open_socket::jk_connect.c (817): connect to 127.0.0.1:8009 failed
> (errno=111)
> [Sat Dec 17 06:11:50 2016][3254:47280261211024] [info]
> ajp_connect_to_endpoint::jk_ajp_common.c (1068): (worker1) Failed opening
> socket to (127.0.0.1:8009) (errno=111)
> [Sat Dec 17 06:11:50 2016][3254:47280261211024] [error]
> ajp_send_request::jk_ajp_common.c (1728): (worker1) connecting to backend
> failed. Tomcat is probably not started or is listening on the wrong port
> (errno=111)
> [Sat Dec 17 06:11:50 2016][3254:47280261211024] [info]
> ajp_service::jk_ajp_common.c (2778): (worker1) sending request to tomcat
> failed (recoverable), because of error during request sending (attempt=2)
> [Sat Dec 17 06:11:50 2016][3254:47280261211024] [error]
> ajp_service::jk_ajp_common.c (2799): (worker1) connecting to tomcat failed
> (rc=-3, errors=1, client_errors=0).
> [Sat Dec 17 06:11:50 2016][3254:47280261211024] [info] jk_handler::mod_jk.c
> (2995): Service error=-3 for worker=worker1
>
> Any ideas on what I should check?
>
> Cheers

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

Re: Tomcat SSL or Apache SSL

2016-12-19 Thread Christopher Schultz 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Edwin,

On 12/19/16 12:22 PM, Edwin Quijada wrote:
> I am trying to use SSL with my server Tomcat . I have read
> different articles when it recommends that is better use Apache
> webserver in front of Tomcat to and apache handles the SSL
> conection. My problem is that I cannot use apache in front of
> Tomcat because I am using websockets and these doesnt work with
> apache in front of.

I haven't used it, but httpd does have mod_proxy_wstunnel[1]. I'm not
sure if it's production-quality.

> I read howto use Tomcat with SSL but I 'd like to know any
> comments from you about this.

It used to be the conventional wisdom that Tomcat should be fronted by
httpd for two reasons:

1. httpd was faster for static content
2. httpd was faster for TLS termination

Neither of those are true anymore, so they aren't compelling reasons
to use httpd as a reverse-proxy in front of Tomcat. There are *other*
compelling reasons to use httpd in front of Tomcat, but static content
and TLS performance aren't among them.

For the best performance, you are going to want to use either of these
configurations for TLS:

a. NIO/NIO2 with OpenSSL crypto provider
b. APR/tcnative with OpenSSL

The APR/tcnative option has a longer history and will likely yield
slightly better (but possibly not measurable) performance, but it is
more difficult to set-up, requires a native library shim for OpenSSL, et
c.

The NIO/NIO2 option is much easier to configure but the OpenSSL crypto
provider has fewer miles under its treads, so you might want to make
sure you test it a lot before you rely on it in production. Then
again, Websocket in general is somewhat "new" itself, so I'm not sure
if the "newness" of the OpenSSL crypto provider should be particularly
worrisome for you.

Hope that helps,
- -chris

[1] https://httpd.apache.org/docs/2.4/mod/mod_proxy_wstunnel.html
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJYWCH9AAoJEBzwKT+lPKRYDxgQAMdESHpvr081in7FIeJsL7HO
j9uIm07lz2ZaL9ruZd/RBeM7goPUfSgAouuSxTut3Ko/6wbINv5PA1I43BqVulHn
Hnq7tKCfGuUdfjDKUtxDYImK4FW/JDbRZI4mafpDAHkvcsMC5ac5Mb3jtWIr8Dn3
+wgeeGqnHA+juPGFKkNdk4NxBv/nxyLC8vWGY4nTPnKQ69EtAKFCSwNfbN04Y3qr
H4SQ8zon4YMMg/YPyTb3OsL+QnakJPr1bXgN4vpxtKAGGLcUUiPBsVzEX8e4J8b6
ZS41SoteuUa/4YbbKagWgBiTahjxGU4sYoOvVvnCGTpnSQGd2uoK6S5l1OyyWite
osPPvmXnnMGolMv4LT/EZTnUKrmYr8/NNC1tIWiGGNXoCoEG7K3fWxsWy1rIDNEe
8xo3GsCTNj8RnQ9Zd7mRkEgJQj49Mbdoepb9IiQCpcaDs2wBFRt7wVrFhXk4NXEy
AoEWPuQEHgi8BmupjN3pN2i8Du8WN1xchRfRT+XpXnEOq2Drw4bcEpYjJZ2Kltjj
zWJVKCrEJE2afV8acyABGRCkhM5sOTVkupZhAZqz0rfjtZlnOACPfo8o8qbALxb0
z5LQDmDF6CNtP5M+lJAqHA2lRyMkAQkLcPyABu/CDjscvpWcgifds0zbJB7K+WMp
RTL714GE+JxO+Z1JzRqx
=uJlB
-END PGP SIGNATURE-

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

Re: Upgrade to 8.5.8/9

2016-12-19 Thread Christopher Schultz 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Greg,

On 12/19/16 4:47 AM, Greg Huber wrote:
> I am currently running tomcat 8.0.32 and have tried to upgrade to
> 8.5.8 and 8.5.9 without success.  I use mod_jk to connect apache to
> tomcat running on centos 5.11 with Apache 2.2.3.
> 
> I have installed openSSL 1.0.2.j to compile the native
> tomcat-native-1.2.10 using apr-1.5.2 and tomcat-connectors-1.2.42
> for the mod_jk.

If you are using httpd + mod_jk, why are you bothering with APR and
tcnative on the Tomcat side?

> The problem is that tomcat seems to start but fails sometimes to
> connect correctly to apache and causes apache to hang.  If I stop
> tomcat, apache starts working again.  I have been through the logs
> with little indication of the problem.  If I revet back to 8.0.32
> everything works OK.

What if you use the NIO connector instead of APR?

> All I can find is this in the mod_jk.log:
> 
> 
> [Sat Dec 17 06:11:48 2016][3212:47280261211024] [info]
> init_jk::mod_jk.c (3595): mod_jk/1.2.42 initialized [Sat Dec 17
> 06:11:50 2016][3254:47280261211024] [info] 
> jk_open_socket::jk_connect.c (817): connect to 127.0.0.1:8009
> failed (errno=111) [Sat Dec 17 06:11:50 2016][3254:47280261211024]
> [info] ajp_connect_to_endpoint::jk_ajp_common.c (1068): (worker1)
> Failed opening socket to (127.0.0.1:8009) (errno=111) [Sat Dec 17
> 06:11:50 2016][3254:47280261211024] [error] 
> ajp_send_request::jk_ajp_common.c (1728): (worker1) connecting to
> backend failed. Tomcat is probably not started or is listening on
> the wrong port (errno=111) [Sat Dec 17 06:11:50
> 2016][3254:47280261211024] [info] ajp_service::jk_ajp_common.c
> (2778): (worker1) sending request to tomcat failed (recoverable),
> because of error during request sending (attempt=1) [Sat Dec 17
> 06:11:50 2016][3254:47280261211024] [info] 
> jk_open_socket::jk_connect.c (817): connect to 127.0.0.1:8009
> failed (errno=111) [Sat Dec 17 06:11:50 2016][3254:47280261211024]
> [info] ajp_connect_to_endpoint::jk_ajp_common.c (1068): (worker1)
> Failed opening socket to (127.0.0.1:8009) (errno=111) [Sat Dec 17
> 06:11:50 2016][3254:47280261211024] [error] 
> ajp_send_request::jk_ajp_common.c (1728): (worker1) connecting to
> backend failed. Tomcat is probably not started or is listening on
> the wrong port (errno=111) [Sat Dec 17 06:11:50
> 2016][3254:47280261211024] [info] ajp_service::jk_ajp_common.c
> (2778): (worker1) sending request to tomcat failed (recoverable),
> because of error during request sending (attempt=2) [Sat Dec 17
> 06:11:50 2016][3254:47280261211024] [error] 
> ajp_service::jk_ajp_common.c (2799): (worker1) connecting to tomcat
> failed (rc=-3, errors=1, client_errors=0). [Sat Dec 17 06:11:50
> 2016][3254:47280261211024] [info] jk_handler::mod_jk.c (2995):
> Service error=-3 for worker=worker1
> 
> Any ideas on what I should check?

Can you post your  configuration?

Any errors in the log files (specifically logs/catalina.out or, if you
are using jsvc or Windows services, stdout.log/stderr.log/etc.)?

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

iQIcBAEBCAAGBQJYWCLGAAoJEBzwKT+lPKRYzqcP/R34lxIW90ZPn7SQ5SBsbKN8
rvYD+4k7a3EGEnPUhfJaajOMbpTXdPTHyltHOID9CpRRFIGrb+/kcKmaLbllYIqq
NUDvWSDUHK0yELaSjb7+Y980mygqXV3j8wAardcEnZ/wG143ZZozhpQtKjhpLmsb
XMe0HiC9/4TeqCtyZ5IWRdq/UOotnU0m1QMjgGYQPztGwQlfvNYDZ//8apiYkCKY
qUoblyNM1RiH4H6tiX+7ZEfk3exvArw84adcWULYiQNpHMwvsRlfMi1aq8Xcty5+
xhB4SitKoEB6CY/oLwRjWYAUsQIov2trGoqbhxIiQcNpHxoKslLabvzdjmjMPMj0
kbMiGpOFfK4ULqyk1255HNxrGL97lnA2nfIz4q23XUU4AYjQkvWHVe94zbUGzdHM
6WZWLn8aZcugC5ltENAp7bCuye2KzpbA4BRbaoGBgiGRQaGSx+0poTubLODSNRFl
cJv+KyoCS+NX4Lz0gK3sIhHr7xRQno5tYmUKNjIn3/v3Rt5zhjfXCvoElQ+MIlEW
iQfkO6AMw+uWlNnd6Iuya9do4bYs/7oN4NiySy6yuz9v96JC6qjZvOtfj4nViNnm
bTRNDreU8IyBR0/vkgKTNTF7KfebJ6ccxRUuFeqqK3rUikBVDW1SsKGskuQK+Htr
I3y6BDq4qz2VjDdPTXL0
=XGBI
-END PGP SIGNATURE-

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

Re: Runtime Cloning of DataSource for Different DB?

2016-12-19 Thread Christopher Schultz 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Jerry,

On 12/16/16 3:39 PM, Jerry Malcolm wrote:
> On 6/27/2016 4:35 PM, Jerry Malcolm wrote:
>> Mark,
>> 
>> On 6/27/2016 1:07 PM, Mark Thomas wrote:
>>> On 27/06/2016 17:44, Jerry Malcolm wrote:
>>> 
 I'm assuming that context.lookup(...) simply locates the
 "jdbc/myDB"  tag in the context.xml file, pulls all
 of the parms out of that tag, creates a DataSource object
 utilizing the parms, and returns it.If that's the case,
 couldn't I create a variation/subclass of the Context object
 that modifies the url parm that it found in the resource tag
 and puts the desired db name into the url before constructing
 the DataSource?
>>> Sure.
>>> 
>>> You need to implement the appropriate factory and then specify
>>> your factory class explicitly in the Resource element using the
>>> factory attribute.
>>> 
>>> You probably want to start here for ideas on how to code up
>>> your factory: 
>>> http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/naming/fac
tory/
>>>
>>>
>>>
>>> 
or for a more specific example:
>>> http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/dbc
p/dbcp2/BasicDataSourceFactory.java?view=annotate
>>>
>>>
>>>
>>>
>>> 
Mark
>>> 
>> 
> Mark, It's been several months since we corresponded on this
> thread.  I've been working on other aspects of the project. But the
> time has arrived that I have to get this working.  Refresher I
> want to have one generic  .
> When I need an instance, I pass a dbname to the factory and it
> builds the correct URL substituting the desired dbName into the
> URL.
> 
> I have coded a subclass of BasicDataSourceFactory that has a new 
> getInstance( databaseName ) method on it.  All I'm doing there is 
> getting the URL property from the common/generic  tag
> and appending databaseName to the URL, then calling the parent 
> createDataSource( properties ) method.  I believe that will do what
> I need.  Plus it compiles successfully.
> 
> Where I'm falling apart now is defining the resource tag(s) and 
> successfully coding the request to get an instance.   Normally when
> I reference a "" tag in my code [ ds = 
> (DataSource)envContext.lookup( dataSourceName );  ] the lookup 
> apparently uses the default datasourcefactory and returns a
> datasource. Fine.  But now I want to tell it use my subclass
> factory instead, and I need to pass a parameter (the db name) in.
> So I 'think' I need to get an instance of MyDataSourceFactory, then
> call my new method on it.  But how do I tell "envContext.lookup()"
> that I want to use my own factory and my own custom method (with
> the additional parameter) to get the instance from the factory?
> Or do I use "envContext.lookup() to lookup and give me an
> instance of my FACTORY, and then simply call my method on my 
> factory to get the ds?  Either way, I'm hitting wall on how to do
> it.

It's all in the configuration; your code shouldn't have to do anything.



NOTE: I have no idea if this is the right code here, but conceptually
it sounds like what you are trying to do.

package fully.qualified;
public class MyDataSourceFactory {
  public void setDBName(String name) { ... };
  public static String getDBName() { ... };
  public Object createDataSource(Properties props) {
String dbURL = getURL().replaceAll("%dbName%", getDBName());

props.put("url", dbURL");
return super.createDataSource(props);
  }
}

I think that's all you're looking for.

It occurs to me that your *code* might need to provide the dbname to
the factory. In that case you might have to provide some environmental
context for this. Maybe a ThreadLocal.



[The "unsharable" scope means that every call to ctx.lookup() will
return a new pooled DataSource. That means you don't want to use JNDI
as your application's stash for the DataSource... you're going to want
to store it instead in e.g. the application scope.]

package fully.qualified;
public class MyDataSourceFactory {
  public ThreadLocal dbName = new ThreadLocal();
  public Object createDataSource(Properties props) {
String dbURL = getURL().replaceAll("%dbName%", dbName.get());

props.put("url", dbURL");
return super.createDataSource(props);
  }
}

// client code
MyDataSourceFactory.dbName.set("explicitDBName");
DataSource dx = ctx.lookup(jndiPath);

I'm not sure if the servlet spec or Tomcat provide any guarantees
about the current thread being used to call the factory's
createDataSource method, but I don't see a reason why Tomcat would use
another thread for that purpose.

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

iQIcBAEBCAAGBQJYWCXzAAoJEBzwKT+lPKRYZH8QALuuG0XTNaJg1qFJi0p25Bbx
Gp7UbIZqOiIpFAavs/pco8+knnas9deX5DLLS8/CfQWK0l9SByAuR+0ltOJa8oCp
KpQXBhBWiJEQggQ1j4Moii/KWLO4Rt0fVAv800fFZ4DVvAEytm5JNP9J1cT9vRJx
RucK9FgFnRi8tKTvhjP0LXly3myFPwr+gHciki7Sh5W8lrKAkSEmOBPZIRyNvFr7

Upgrade to 8.5.8/9

2016-12-19 Thread Greg Huber 
Hello,

I am currently running tomcat 8.0.32 and have tried to upgrade to 8.5.8 and
8.5.9 without success.  I use mod_jk to connect apache to tomcat running on
centos 5.11 with Apache 2.2.3.

I have installed openSSL 1.0.2.j to compile the native tomcat-native-1.2.10
using apr-1.5.2 and tomcat-connectors-1.2.42 for the mod_jk.

The problem is that tomcat seems to start but fails sometimes to connect
correctly to apache and causes apache to hang.  If I stop tomcat, apache
starts working again.  I have been through the logs with little indication
of the problem.  If I revet back to 8.0.32 everything works OK.


All I can find is this in the mod_jk.log:


[Sat Dec 17 06:11:48 2016][3212:47280261211024] [info] init_jk::mod_jk.c
(3595): mod_jk/1.2.42 initialized
[Sat Dec 17 06:11:50 2016][3254:47280261211024] [info]
jk_open_socket::jk_connect.c (817): connect to 127.0.0.1:8009 failed
(errno=111)
[Sat Dec 17 06:11:50 2016][3254:47280261211024] [info]
ajp_connect_to_endpoint::jk_ajp_common.c (1068): (worker1) Failed opening
socket to (127.0.0.1:8009) (errno=111)
[Sat Dec 17 06:11:50 2016][3254:47280261211024] [error]
ajp_send_request::jk_ajp_common.c (1728): (worker1) connecting to backend
failed. Tomcat is probably not started or is listening on the wrong port
(errno=111)
[Sat Dec 17 06:11:50 2016][3254:47280261211024] [info]
ajp_service::jk_ajp_common.c (2778): (worker1) sending request to tomcat
failed (recoverable), because of error during request sending (attempt=1)
[Sat Dec 17 06:11:50 2016][3254:47280261211024] [info]
jk_open_socket::jk_connect.c (817): connect to 127.0.0.1:8009 failed
(errno=111)
[Sat Dec 17 06:11:50 2016][3254:47280261211024] [info]
ajp_connect_to_endpoint::jk_ajp_common.c (1068): (worker1) Failed opening
socket to (127.0.0.1:8009) (errno=111)
[Sat Dec 17 06:11:50 2016][3254:47280261211024] [error]
ajp_send_request::jk_ajp_common.c (1728): (worker1) connecting to backend
failed. Tomcat is probably not started or is listening on the wrong port
(errno=111)
[Sat Dec 17 06:11:50 2016][3254:47280261211024] [info]
ajp_service::jk_ajp_common.c (2778): (worker1) sending request to tomcat
failed (recoverable), because of error during request sending (attempt=2)
[Sat Dec 17 06:11:50 2016][3254:47280261211024] [error]
ajp_service::jk_ajp_common.c (2799): (worker1) connecting to tomcat failed
(rc=-3, errors=1, client_errors=0).
[Sat Dec 17 06:11:50 2016][3254:47280261211024] [info] jk_handler::mod_jk.c
(2995): Service error=-3 for worker=worker1

Any ideas on what I should check?

Cheers

Re: ERR_SPDY_COMPRESSION_ERROR (http2)

2016-12-19 Thread Durga Srinivasu Karuturi 
Mark,

Looks like tar/zip attachments are getting removed.

Uploaded same in google drive now.

Please let me know if you can access the same or not.

https://drive.google.com/open?id=0B1OzquDqWi6bVUN0MDk2RDFENG8

Thanks,
Durga Srinivasu


On Mon, Dec 19, 2016 at 3:21 PM, Durga Srinivasu Karuturi <
durgasriniv...@gmail.com> wrote:

> Mark,
>
> Attaching the modified ROOT web-app from tomcat 8.5.9 bundle. Just changed
> index.jsp and added lib [mostly DOJO] folder content to reproduce.
>
> If we deploy this in latest 8.5.9 with http2 enabled in chrome we are
> seeing the SPDY compression errors
>
> Please let me know if this helps.
>
> Thanks,
> Durga Srinivasu
>
>
>
> On Mon, Dec 19, 2016 at 2:31 PM, Mark Thomas  wrote:
>
>> On 17/12/2016 06:35, Durga Srinivasu Karuturi wrote:
>> > Do i need to post in any other forum?
>>
>> No, you are in the right place.
>>
>> You mentioned the issue was reproducible with the Dojo libraries. If you
>> can provide the simplest possible set of steps to recreate this issue
>> from a clean Tomcat 8.5.9 install that would be a big help.
>>
>> Mark
>>
>> >
>> > Thanks,
>> > Durga Srinivasu
>> >
>> > On Thu, Dec 15, 2016 at 6:41 PM, Durga Srinivasu Karuturi
>> > > wrote:
>> >
>> > Hi,
>> >
>> > Any pointers please?
>> >
>> > Thanks,
>> > Durga Srinivasu
>> >
>> > On Wed, Dec 14, 2016 at 10:15 PM, Durga Srinivasu Karuturi
>> > > wrote:
>> >
>> > Hi,
>> >
>> > Recent chrome  [Mac - Sierra : Version  55.0.2883.87 (64-bit) ]
>> we are seeing issues in http2 sites.
>> >
>> >
>> > Initially we have seen problem with http2 table header size
>> limit error and to fix this, we have upgraded tomcat 8.5.4 to 8.5.9 where
>> tomcat has increased the header limit from 16K to 64K.
>> >
>> >
>> > Now with latest tomcat 8.5.9 we are seeing
>> ERR_SPDY_COMPRESSION_ERROR while loading dojo libraries.
>> >
>> > Tried couple of steps (flush SPDY sokets etc) based on google
>> search on this issue but nothing worked..
>> >
>> >
>> > Inline image 1
>> >
>> > t=10513 [st= 1] -HTTP_TRANSACTION_SEND_REQUEST
>> >
>> > t=10513 [st= 1] +HTTP_TRANSACTION_READ_HEADERS  [dt=36]
>> >
>> > t=10549 [st=37]HTTP2_STREAM_ERROR
>> >
>> >--> description = "ABANDONED
>> > (stream_id=139):
>> > https://10.104.118.174/webacs/lib/dijit/form/_ToggleB
>> uttonMixin.js.map
>> > > Mixin.js.map>"
>> >
>> >--> status = -363
>> >
>> >--> stream_id = 139
>> >
>> > t=10549 [st=37] -HTTP_TRANSACTION_READ_HEADERS
>> >
>> > * --> net_error = -363
>> > (ERR_SPDY_COMPRESSION_ERROR)*
>> >
>> > t=10549 [st=37]   -URL_REQUEST_START_JOB
>> >
>> > *   --> net_error = -363
>> > (ERR_SPDY_COMPRESSION_ERROR)*
>> >
>> > t=10549 [st=37]URL_REQUEST_DELEGATE  [dt=0]
>> >
>> > t=10549 [st=37] -REQUEST_ALIVE
>> >
>> >  --> net_error = -363
>> (ERR_SPDY_COMPRESSION_ERROR)
>> >
>> >
>> > Initial content is downloaded (other JS files etc) but on some
>> dojo libraries alone, we are this issue which make application home page
>> load fails.
>> >
>> >
>> > Firefox works!
>> >
>> >
>> > We are having latest tomcat 8.5.9 already. Not sure where else
>> problem now. We have not enabled any compression server side.
>> >
>> >
>> > https://bugs.chromium.org/p/chromium/issues/detail?id=673315
>> > 
>> (Chrome bugs i have raised)
>> >
>> > My guess is that the bug is in Tomcat, in that it does not
>> send an HPACK dynamic table size update (so the dynamic table should be the
>> default 4 kB) but uses a 64 kB dynamic table.
>> > As soon as it references entries that are in fact already
>> emitted, that's a compression error.
>> > See https://www.ietf.org/mail-arch
>> ive/web/httpbisa/current/msg27867.html
>> > > 27867.html> for a discussion on how to interpret the specs.
>> >
>> > According to the chrome bug notes problem is with tome dynamic
>> table size 64k. I don't know how to confirm this is as tomcat issue as well.
>> >
>> > Can somebody help here to trace the problem?
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
>>
>

Re: ERR_SPDY_COMPRESSION_ERROR (http2)

2016-12-19 Thread Mark Thomas 
On 17/12/2016 06:35, Durga Srinivasu Karuturi wrote:
> Do i need to post in any other forum?

No, you are in the right place.

You mentioned the issue was reproducible with the Dojo libraries. If you
can provide the simplest possible set of steps to recreate this issue
from a clean Tomcat 8.5.9 install that would be a big help.

Mark

> 
> Thanks,
> Durga Srinivasu
> 
> On Thu, Dec 15, 2016 at 6:41 PM, Durga Srinivasu Karuturi
> > wrote:
> 
> Hi,
> 
> Any pointers please?
> 
> Thanks,
> Durga Srinivasu
> 
> On Wed, Dec 14, 2016 at 10:15 PM, Durga Srinivasu Karuturi
> > wrote:
> 
> Hi,
> 
> Recent chrome  [Mac - Sierra : Version  55.0.2883.87 (64-bit) ] we 
> are seeing issues in http2 sites. 
> 
> 
> Initially we have seen problem with http2 table header size limit 
> error and to fix this, we have upgraded tomcat 8.5.4 to 8.5.9 where tomcat 
> has increased the header limit from 16K to 64K. 
> 
> 
> Now with latest tomcat 8.5.9 we are seeing  
> ERR_SPDY_COMPRESSION_ERROR while loading dojo libraries.
> 
> Tried couple of steps (flush SPDY sokets etc) based on google search 
> on this issue but nothing worked..
> 
> 
> Inline image 1
> 
> t=10513 [st= 1] -HTTP_TRANSACTION_SEND_REQUEST
> 
> t=10513 [st= 1] +HTTP_TRANSACTION_READ_HEADERS  [dt=36]
> 
> t=10549 [st=37]HTTP2_STREAM_ERROR
> 
>--> description = "ABANDONED
> (stream_id=139):
> https://10.104.118.174/webacs/lib/dijit/form/_ToggleButtonMixin.js.map
> 
> "
> 
>--> status = -363
> 
>--> stream_id = 139
> 
> t=10549 [st=37] -HTTP_TRANSACTION_READ_HEADERS
> 
> * --> net_error = -363
> (ERR_SPDY_COMPRESSION_ERROR)*
> 
> t=10549 [st=37]   -URL_REQUEST_START_JOB
> 
> *   --> net_error = -363
> (ERR_SPDY_COMPRESSION_ERROR)*
> 
> t=10549 [st=37]URL_REQUEST_DELEGATE  [dt=0]
> 
> t=10549 [st=37] -REQUEST_ALIVE
> 
>  --> net_error = -363 (ERR_SPDY_COMPRESSION_ERROR)
> 
> 
> Initial content is downloaded (other JS files etc) but on some dojo 
> libraries alone, we are this issue which make application home page load 
> fails.
> 
> 
> Firefox works!
> 
> 
> We are having latest tomcat 8.5.9 already. Not sure where else 
> problem now. We have not enabled any compression server side.
> 
> 
> https://bugs.chromium.org/p/chromium/issues/detail?id=673315
>  
> (Chrome bugs i have raised)
> 
> My guess is that the bug is in Tomcat, in that it does not send 
> an HPACK dynamic table size update (so the dynamic table should be the 
> default 4 kB) but uses a 64 kB dynamic table.  
> As soon as it references entries that are in fact already 
> emitted, that's a compression error.  
> See 
> https://www.ietf.org/mail-archive/web/httpbisa/current/msg27867.html
> 
>  for a 
> discussion on how to interpret the specs.
> 
> According to the chrome bug notes problem is with tome dynamic table 
> size 64k. I don't know how to confirm this is as tomcat issue as well. 
> 
> Can somebody help here to trace the problem?
> 
> 
> 
>  
> 
> 
> 


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

Re: ERR_SPDY_COMPRESSION_ERROR (http2)

2016-12-19 Thread Mark Thomas 
On 19/12/2016 09:56, Durga Srinivasu Karuturi wrote:
> Mark,
> 
> Looks like tar/zip attachments are getting removed.
> 
> Uploaded same in google drive now.
> 
> Please let me know if you can access the same or not.
> 
> https://drive.google.com/open?id=0B1OzquDqWi6bVUN0MDk2RDFENG8#

I can.

Generally, it is better to provide the steps. e.g.:

Add this line to index.jsp:
...

Download these libraries and add them in WEB-INF/lib
http://...

Mark

> 
> Thanks,
> Durga Srinivasu
> 
> 
> On Mon, Dec 19, 2016 at 3:21 PM, Durga Srinivasu Karuturi <
> durgasriniv...@gmail.com> wrote:
> 
>> Mark,
>>
>> Attaching the modified ROOT web-app from tomcat 8.5.9 bundle. Just changed
>> index.jsp and added lib [mostly DOJO] folder content to reproduce.
>>
>> If we deploy this in latest 8.5.9 with http2 enabled in chrome we are
>> seeing the SPDY compression errors
>>
>> Please let me know if this helps.
>>
>> Thanks,
>> Durga Srinivasu
>>
>>
>>
>> On Mon, Dec 19, 2016 at 2:31 PM, Mark Thomas  wrote:
>>
>>> On 17/12/2016 06:35, Durga Srinivasu Karuturi wrote:
 Do i need to post in any other forum?
>>>
>>> No, you are in the right place.
>>>
>>> You mentioned the issue was reproducible with the Dojo libraries. If you
>>> can provide the simplest possible set of steps to recreate this issue
>>> from a clean Tomcat 8.5.9 install that would be a big help.
>>>
>>> Mark
>>>

 Thanks,
 Durga Srinivasu

 On Thu, Dec 15, 2016 at 6:41 PM, Durga Srinivasu Karuturi
 > wrote:

 Hi,

 Any pointers please?

 Thanks,
 Durga Srinivasu

 On Wed, Dec 14, 2016 at 10:15 PM, Durga Srinivasu Karuturi
 > wrote:

 Hi,

 Recent chrome  [Mac - Sierra : Version  55.0.2883.87 (64-bit) ]
>>> we are seeing issues in http2 sites.


 Initially we have seen problem with http2 table header size
>>> limit error and to fix this, we have upgraded tomcat 8.5.4 to 8.5.9 where
>>> tomcat has increased the header limit from 16K to 64K.


 Now with latest tomcat 8.5.9 we are seeing
>>> ERR_SPDY_COMPRESSION_ERROR while loading dojo libraries.

 Tried couple of steps (flush SPDY sokets etc) based on google
>>> search on this issue but nothing worked..


 Inline image 1

 t=10513 [st= 1] -HTTP_TRANSACTION_SEND_REQUEST

 t=10513 [st= 1] +HTTP_TRANSACTION_READ_HEADERS  [dt=36]

 t=10549 [st=37]HTTP2_STREAM_ERROR

--> description = "ABANDONED
 (stream_id=139):
 https://10.104.118.174/webacs/lib/dijit/form/_ToggleB
>>> uttonMixin.js.map
 >> Mixin.js.map>"

--> status = -363

--> stream_id = 139

 t=10549 [st=37] -HTTP_TRANSACTION_READ_HEADERS

 * --> net_error = -363
 (ERR_SPDY_COMPRESSION_ERROR)*

 t=10549 [st=37]   -URL_REQUEST_START_JOB

 *   --> net_error = -363
 (ERR_SPDY_COMPRESSION_ERROR)*

 t=10549 [st=37]URL_REQUEST_DELEGATE  [dt=0]

 t=10549 [st=37] -REQUEST_ALIVE

  --> net_error = -363
>>> (ERR_SPDY_COMPRESSION_ERROR)


 Initial content is downloaded (other JS files etc) but on some
>>> dojo libraries alone, we are this issue which make application home page
>>> load fails.


 Firefox works!


 We are having latest tomcat 8.5.9 already. Not sure where else
>>> problem now. We have not enabled any compression server side.


 https://bugs.chromium.org/p/chromium/issues/detail?id=673315
 
>>> (Chrome bugs i have raised)

 My guess is that the bug is in Tomcat, in that it does not
>>> send an HPACK dynamic table size update (so the dynamic table should be the
>>> default 4 kB) but uses a 64 kB dynamic table.
 As soon as it references entries that are in fact already
>>> emitted, that's a compression error.
 See https://www.ietf.org/mail-arch
>>> ive/web/httpbisa/current/msg27867.html
 >> 27867.html> for a discussion on how to interpret the specs.

 According to the chrome bug notes problem is with tome dynamic
>>> table size 64k. I don't know how to confirm this is as tomcat issue as well.

 Can somebody help here to trace the problem?

Re: ERR_SPDY_COMPRESSION_ERROR (http2)

2016-12-19 Thread Durga Srinivasu Karuturi 
The below are the changes I did in ROOT web app:

1.  Added dojo libraries and login.js in ROOT/lib
2.  Added DOJO bootstrap and some dojo reference code in index.jsp as below:


var djConfig = {
isDebug: false,
debugAtAllCosts: false,
parseOnLoad: false,
supportedBrowser: {
'IE': [11],
'FF': ['44+'],
'ESR': [38],
'Chrome': ['48+']
},
async: true
};
   




require([
"login",
], function(){
require([
"dojo/_base/declare",
"dojo/parser",
"dojo/aspect",
"dojo/has",
"dojo/request/xhr",
"dojo/dom-form",
"dojo/dom-attr",
"dijit/registry",
"dojo/dom-construct",
"dojo/hash",
"dojo/data/ItemFileWriteStore",
"dojo/domReady!"
], function(declare, parser, aspect, has, xhr, domForm,
domAttr, registry, domConstruct, do_hash){
parser.parse();
});
});





On Mon, Dec 19, 2016 at 4:09 PM, Mark Thomas  wrote:

> On 19/12/2016 09:56, Durga Srinivasu Karuturi wrote:
> > Mark,
> >
> > Looks like tar/zip attachments are getting removed.
> >
> > Uploaded same in google drive now.
> >
> > Please let me know if you can access the same or not.
> >
> > https://drive.google.com/open?id=0B1OzquDqWi6bVUN0MDk2RDFENG8#
>
> I can.
>
> Generally, it is better to provide the steps. e.g.:
>
> Add this line to index.jsp:
> ...
>
> Download these libraries and add them in WEB-INF/lib
> http://...
>
> Mark
>
> >
> > Thanks,
> > Durga Srinivasu
> >
> >
> > On Mon, Dec 19, 2016 at 3:21 PM, Durga Srinivasu Karuturi <
> > durgasriniv...@gmail.com> wrote:
> >
> >> Mark,
> >>
> >> Attaching the modified ROOT web-app from tomcat 8.5.9 bundle. Just
> changed
> >> index.jsp and added lib [mostly DOJO] folder content to reproduce.
> >>
> >> If we deploy this in latest 8.5.9 with http2 enabled in chrome we are
> >> seeing the SPDY compression errors
> >>
> >> Please let me know if this helps.
> >>
> >> Thanks,
> >> Durga Srinivasu
> >>
> >>
> >>
> >> On Mon, Dec 19, 2016 at 2:31 PM, Mark Thomas  wrote:
> >>
> >>> On 17/12/2016 06:35, Durga Srinivasu Karuturi wrote:
>  Do i need to post in any other forum?
> >>>
> >>> No, you are in the right place.
> >>>
> >>> You mentioned the issue was reproducible with the Dojo libraries. If
> you
> >>> can provide the simplest possible set of steps to recreate this issue
> >>> from a clean Tomcat 8.5.9 install that would be a big help.
> >>>
> >>> Mark
> >>>
> 
>  Thanks,
>  Durga Srinivasu
> 
>  On Thu, Dec 15, 2016 at 6:41 PM, Durga Srinivasu Karuturi
>  > wrote:
> 
>  Hi,
> 
>  Any pointers please?
> 
>  Thanks,
>  Durga Srinivasu
> 
>  On Wed, Dec 14, 2016 at 10:15 PM, Durga Srinivasu Karuturi
>  >
> wrote:
> 
>  Hi,
> 
>  Recent chrome  [Mac - Sierra : Version  55.0.2883.87 (64-bit)
> ]
> >>> we are seeing issues in http2 sites.
> 
> 
>  Initially we have seen problem with http2 table header size
> >>> limit error and to fix this, we have upgraded tomcat 8.5.4 to 8.5.9
> where
> >>> tomcat has increased the header limit from 16K to 64K.
> 
> 
>  Now with latest tomcat 8.5.9 we are seeing
> >>> ERR_SPDY_COMPRESSION_ERROR while loading dojo libraries.
> 
>  Tried couple of steps (flush SPDY sokets etc) based on google
> >>> search on this issue but nothing worked..
> 
> 
>  Inline image 1
> 
>  t=10513 [st= 1] -HTTP_TRANSACTION_SEND_REQUEST
> 
>  t=10513 [st= 1] +HTTP_TRANSACTION_READ_HEADERS  [dt=36]
> 
>  t=10549 [st=37]HTTP2_STREAM_ERROR
> 
> --> description = "ABANDONED
>  (stream_id=139):
>  https://10.104.118.174/webacs/lib/dijit/form/_ToggleB
> >>> uttonMixin.js.map
>   >>> Mixin.js.map>"
> 
> --> status = -363
> 
> --> stream_id = 139
> 
>  t=10549 [st=37] -HTTP_TRANSACTION_READ_HEADERS
> 
>  * --> net_error = -363
>  (ERR_SPDY_COMPRESSION_ERROR)*
> 
>  t=10549 [st=37]   -URL_REQUEST_START_JOB
> 
>  *   --> net_error = -363
>