Re: Tomcat 7 under Java 11? Re: Has anybody ever heard of "ECDHE-ECDSA-CHACHA20-POLY1305"?
On 20/03/2019 10:05, Mark Thomas wrote: > On 19/03/2019 23:49, James H. H. Lampert wrote: >> In response to my question: >> I've just (same customer as before) been asked about ECDHE-ECDSA-CHACHA20-POLY1305 and ECDHE-RSA-CHACHA20-POLY1305 and I can't find either one on the Sun or IBM JSSE cipher lists for Java 8. >> >> On 3/19/19, 12:34 AM, Peter@Kreuser-Online wrote: >> >>> Most certainly only >=Java9... (OpenJDK and Oracle, don’t know about >>> IBM though) >> >> Thanks. >> >> I've since learned that IBM Midrange systems will skip 9 and 10, but >> will offer Java 11 at some point. But that begs the question of whether >> or not Tomcat 7 (or our webapp context) will even run under Java 11. > > Tomcat 7 should run. If it doesn't, it would be treated as a bug and > we'd fix it. We do test it from time to time. This thread prompted me to grab the latest OpenJDKs and test them. 9.0.x and 8.5.x build and run with the latest Java 13 early access build (EA12). 7.0.x won't build with Java 12 onwards because Tomcat 7 has a minimum Java version of 6 and Java 11 was the last version of the compiler that accepted Java 6 as an option. Once it is built, Tomcat 7.0.x runs quite happily under Java 13 EA 12. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Datasource Connection Pool
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Rajendra On 3/18/19 12:24, Rajendra wrote: > Tomcat(8.5.32) is not establishing connections to database after > database is restarted. Currently, I am restarting Tomcat instance > if DB is restarted. Please let me know any parameters need to be > added to datasource resource element in Tomcat in order to > establish database connections automatically after database back > into online. You haven't posted your configuration. What do you currently have configured? - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlySWi0ACgkQHPApP6U8 pFg+GRAAqXOtrudPVwyjECs9YUezcSmzqHX8SUMayKn6G4N/IoQUctdgkX86Y1CX OV/k9wiTiiUw/oQ5IuOL2HGn3JS5tMLDK9BWZCtrV2pJLoN9t9GD06bdES34NrV+ wJ4lWjNthQDn21JBLfpt8m/uaDTDvYUJqTljYk5r82KGB4kky/ccUr8gV3BrqSVn 92wZLfpj4t66JPXEBZft03d/4LTCt2qNhJ70E945Ed9u0G/WqoqfpZUfB/FroCI2 p6GNkgYnOdtfIYTUBZpeSZTurxEuFWrs+yzPMGoL0dN0kRxngCSpyurHa5O9gLOY jJFBB6lTX4pX2pbSnIY91S9rOs/AA7jrzzWemcyo9Kv+cO4rlhSpZ4pgQKZPdSwM EACjPFUiVOAW1XCdjE1yUkMatqOlN4WwRaA4gptRv7HMZKdRBV/C6iLudDERO6Y7 6ByTC43d2JNGyi9zPNqiSpq23BGBpxBe5ODM3qolbclNcy2TAg194rUGuKtYstDM oa7+V/EPRheuqcmpBrc5tg9ZPMPLr6gRQKl/ohFxMFnpkAanD5/0bd6TTDdwRFJN 998BDRLNaIh0rtfDUMD0H41Evl6Xl6oKnm2hwfWajtjmkzxHntGkR9g66komzKNm egJT1dE8b2PcmfIeAQ3mD2OSoLxjJ6BQUG4PQZ17x8ECQjc6LHE= =KORC -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Default Max response size in Tomcat
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 3/20/19 10:48, Saurav Sarkar wrote:
> Thanks a lot Olaf for the response.
>
> Yes , i have taken care of that condition
>
> Please find the full code below
>
> protected void doGet(HttpServletRequest request,
> HttpServletResponse response)
>
> throws ServletException, IOException {
>
> try {
>
> String param = request.getParameter("size");
>
> if (param != null) {
>
>
> int kByte = Integer.parseInt(param);
>
>
> response.setContentType("application/octet-stream");
>
>
>
> long length = kByte * 1024;
>
> if (length <= Integer.MAX_VALUE)
>
> {
>
> response.setContentLength((int)length);
>
> }
>
> else
>
> {
>
> response.addHeader("Content-Length", Long.toString(length));
>
> }
Why not simply always use:
response.setContentLengthLong(length);
?
> // response.setContentLength(kByte * 1024);
>
>
> ServletOutputStream outputStream = response.getOutputStream();
>
> byte[] buffer = new byte[1024];
>
> Random random = new Random(System.currentTimeMillis());
>
>
>
>
> while (size < kByte) {
>
> random.nextBytes(buffer);
>
> outputStream.write(buffer);
>
> size += 1;
>
> }
>
>
> outputStream.flush();
>
>
> return;
>
> }
The error you are getting is ClientAbortException. That means that the
client terminated the connection. Perhaps the client didn't want to
accept some huge response.
This is not a server-side error.
- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlySWUcACgkQHPApP6U8
pFjGbBAAgaxhw5B5LwR4Q4/9qvmqIESY+O8RGVF94zzg0derL95BQ/8R4hcV1723
H9LBiHjY1/ZCODCZdOXL8bqCwNYhfE33uXCEXXbNiE4i9SKpAT9yhejZayaJ6oDw
hXv8X7gYZlG8xGwvuVaQ1qrmqeNOLsLcl0hyPjUe2HVZoWgzX5c+WIGvQpGqNLHu
4j+UQsXm+7ALC3vb29S+odvP4qZWf9yEDqQ1RgwbQ499ILM6SGuvYkTQmAeDKGWS
zetAAfjUUhnNZF5qe5QIJkXJZrfPahclmidAqDwA1anb00SsNTmNvmHsPNYWqnC4
2Xnhv3QVZs3PJ66+jZbbBcAkHoyTeDhHGUc1P657MakI//3xViwxAwR0BZwpDCui
VVnk0HISCgv57GQW/C+haGRNQL6bTI8dnhIy0z76tmyUoyNmMLs1HIGSgKmhLYTj
VHlqP/9WzE8FSRXZJJv2wqh2bVwecTKSvmouDGZ5O3c5wweO5HCLfEXz4Bv8yAxJ
x7ugFit0IC01ZvkwD7oJH0eCVibRA1kQoy5vxTy28Vypchv1EmVNNHKax/6EMCZu
kSKK1BOmRV8q4Ut4SRC7H8WdpvCxK5sftHbOkklt8/2wfgmSRkBHDufDe/P0h5av
NQ0QcSGRORLVJ0uEgIF38PmASwqS1f4bla7W2IQfg/0tCSyp9yU=
=H7Jd
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Default Max response size in Tomcat
Thanks a lot Olaf for the response.
Yes , i have taken care of that condition
Please find the full code below
protected void doGet(HttpServletRequest request, HttpServletResponse
response)
throws ServletException, IOException {
try {
String param = request.getParameter("size");
if (param != null) {
int kByte = Integer.parseInt(param);
response.setContentType("application/octet-stream");
long length = kByte * 1024;
if (length <= Integer.MAX_VALUE)
{
response.setContentLength((int)length);
}
else
{
response.addHeader("Content-Length", Long.toString(length));
}
// response.setContentLength(kByte * 1024);
ServletOutputStream outputStream = response.getOutputStream();
byte[] buffer = new byte[1024];
Random random = new Random(System.currentTimeMillis());
while (size < kByte) {
random.nextBytes(buffer);
outputStream.write(buffer);
size += 1;
}
outputStream.flush();
return;
}
}catch (Exception e) {
e.printStackTrace();
response.sendError(500, e.getMessage());
return;
}
}
On Wed, Mar 20, 2019 at 6:26 PM Olaf Kock wrote:
>
>
> On 20.03.19 12:08, Saurav Sarkar wrote:
> > Just to add the stack trace.
> >
> > I am getting ClientAbortException "Connection reset by peer" when i am
> > trying to write to the response stream
> >
> > 2019-03-20T10:32:28.501+ [APP/PROC/WEB/0] ERR
> > org.apache.catalina.connector.ClientAbortException: java.io.IOException:
> > Connection reset by peer
> > 2019-03-20T10:32:28.502+ [APP/PROC/WEB/0] ERR at
> >
> org.apache.catalina.connector.OutputBuffer.realWriteBytes(OutputBuffer.java:364)
> ...
>
> >
> > On Wed, Mar 20, 2019 at 3:51 PM Saurav Sarkar
> > wrote:
> >
> >> Hi All
> >>
> >> I have a very basic test application which serves bytes from memory and
> >> gives it back to the client.
> >>
> >> Whenever i try to send the request for byte size which is of over 2 GB i
> >> get a connection reset error in my server code and a 502 error in my
> chrome
> >> console. Below 2 GB it is working fine.
> >>
> >> In my client side i execute java script which i execute from the
> browser.
> >> This basically executes an XMLHTTPRequest , gets the response (stores in
> >> browser memory) and asks for a save.
> >>
> >> I would like to know if there Is there max response size default value
> >> which is set in default tomcat configuration. ? or any other hints which
> >> you can provide in my use.
> >>
> >>
> >> Thanks and Regards,
> >>
> >> Saurav
> >>
> >> Below is the servlet or server side code
> >>
> >>
> >>
> >> response.setContentLength((int)length);
> >>
> >> }
> >>
> >> else
> >>
> >> {
> >>
> >> response.addHeader("Content-Length", Long.toString(length));
> >>
> >> }
>
> You don't include the initial condition in your code, but I'm assuming
> that the first line is hit: response.setContentLength((int)length);
>
> int in Java is defined to be 32 bit, and always signed. That means that
> any value larger than 2^31 or Integer.MAX_VALUE can't be expressed in
> int as a positive number. In fact, anything between 2^31 and 2^32 will
> be interpreted as a negative number, so you're effectively setting the
> content length to be negative.
>
> Note that there's also a setContentLengthLong method
>
> https://docs.oracle.com/javaee/7/api/javax/servlet/ServletResponse.html#setContentLengthLong-long-
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
Re: Default Max response size in Tomcat
On 20.03.19 12:08, Saurav Sarkar wrote:
> Just to add the stack trace.
>
> I am getting ClientAbortException "Connection reset by peer" when i am
> trying to write to the response stream
>
> 2019-03-20T10:32:28.501+ [APP/PROC/WEB/0] ERR
> org.apache.catalina.connector.ClientAbortException: java.io.IOException:
> Connection reset by peer
> 2019-03-20T10:32:28.502+ [APP/PROC/WEB/0] ERR at
> org.apache.catalina.connector.OutputBuffer.realWriteBytes(OutputBuffer.java:364)
...
>
> On Wed, Mar 20, 2019 at 3:51 PM Saurav Sarkar
> wrote:
>
>> Hi All
>>
>> I have a very basic test application which serves bytes from memory and
>> gives it back to the client.
>>
>> Whenever i try to send the request for byte size which is of over 2 GB i
>> get a connection reset error in my server code and a 502 error in my chrome
>> console. Below 2 GB it is working fine.
>>
>> In my client side i execute java script which i execute from the browser.
>> This basically executes an XMLHTTPRequest , gets the response (stores in
>> browser memory) and asks for a save.
>>
>> I would like to know if there Is there max response size default value
>> which is set in default tomcat configuration. ? or any other hints which
>> you can provide in my use.
>>
>>
>> Thanks and Regards,
>>
>> Saurav
>>
>> Below is the servlet or server side code
>>
>>
>>
>> response.setContentLength((int)length);
>>
>> }
>>
>> else
>>
>> {
>>
>> response.addHeader("Content-Length", Long.toString(length));
>>
>> }
You don't include the initial condition in your code, but I'm assuming
that the first line is hit: response.setContentLength((int)length);
int in Java is defined to be 32 bit, and always signed. That means that
any value larger than 2^31 or Integer.MAX_VALUE can't be expressed in
int as a positive number. In fact, anything between 2^31 and 2^32 will
be interpreted as a negative number, so you're effectively setting the
content length to be negative.
Note that there's also a setContentLengthLong method
https://docs.oracle.com/javaee/7/api/javax/servlet/ServletResponse.html#setContentLengthLong-long-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
[ANN] Apache Tomcat 8.5.39 available
The Apache Tomcat team announces the immediate availability of Apache Tomcat 8.5.39. Apache Tomcat 8 is an open source software implementation of the Java Servlet, JavaServer Pages, Java Unified Expression Language, Java WebSocket and Java Authentication Service Provider Interface for Containers technologies. Apache Tomcat 8.5.x replaces 8.0.x and includes new features pulled forward from the 9.0.x branch. The notable changes since 8.5.38 include: - The APR/Native connector now supports both OpenSSL and JSSE TLS configuration syntax (NIO and NIO2 already support this) - Various improvements to NIO2 - Various fixes for HTTP/2 push requests - Refactor error handling so that errors that occur early in request processing are handled by the application's error handling where the application can be identified Please refer to the change log for the complete list of changes: http://tomcat.apache.org/tomcat-8.5-doc/changelog.html Downloads: http://tomcat.apache.org/download-80.cgi Migration guides from Apache Tomcat 7.x and 8.0.x: http://tomcat.apache.org/migration.html Enjoy! - The Apache Tomcat team - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Default Max response size in Tomcat
Just to add the stack trace. I am getting ClientAbortException "Connection reset by peer" when i am trying to write to the response stream 2019-03-20T10:32:28.501+ [APP/PROC/WEB/0] ERR org.apache.catalina.connector.ClientAbortException: java.io.IOException: Connection reset by peer 2019-03-20T10:32:28.502+ [APP/PROC/WEB/0] ERR at org.apache.catalina.connector.OutputBuffer.realWriteBytes(OutputBuffer.java:364) 2019-03-20T10:32:28.502+ [APP/PROC/WEB/0] ERR at org.apache.catalina.connector.OutputBuffer.flushByteBuffer(OutputBuffer.java:833) 2019-03-20T10:32:28.502+ [APP/PROC/WEB/0] ERR at org.apache.catalina.connector.OutputBuffer.append(OutputBuffer.java:738) 2019-03-20T10:32:28.502+ [APP/PROC/WEB/0] ERR at org.apache.catalina.connector.OutputBuffer.writeBytes(OutputBuffer.java:399) 2019-03-20T10:32:28.502+ [APP/PROC/WEB/0] ERR at org.apache.catalina.connector.OutputBuffer.write(OutputBuffer.java:377) 2019-03-20T10:32:28.502+ [APP/PROC/WEB/0] ERR at org.apache.catalina.connector.CoyoteOutputStream.write(CoyoteOutputStream.java:96) 2019-03-20T10:32:28.502+ [APP/PROC/WEB/0] ERR at org.apache.catalina.connector.CoyoteOutputStream.write(CoyoteOutputStream.java:89) 2019-03-20T10:32:28.502+ [APP/PROC/WEB/0] ERR at org.saurav.cpcftester.NetworkTester.doGet(NetworkTester.java:52) 2019-03-20T10:32:28.502+ [APP/PROC/WEB/0] ERR at javax.servlet.http.HttpServlet.service(HttpServlet.java:635) 2019-03-20T10:32:28.502+ [APP/PROC/WEB/0] ERR at javax.servlet.http.HttpServlet.service(HttpServlet.java:742) 2019-03-20T10:32:28.502+ [APP/PROC/WEB/0] ERR at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:231) 2019-03-20T10:32:28.502+ [APP/PROC/WEB/0] ERR at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) 2019-03-20T10:32:28.502+ [APP/PROC/WEB/0] ERR at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52) 2019-03-20T10:32:28.502+ [APP/PROC/WEB/0] ERR at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193) 2019-03-20T10:32:28.502+ [APP/PROC/WEB/0] ERR at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) 2019-03-20T10:32:28.502+ [APP/PROC/WEB/0] ERR at org.apache.catalina.filters.CorsFilter.handleNonCORS(CorsFilter.java:364) 2019-03-20T10:32:28.502+ [APP/PROC/WEB/0] ERR at org.apache.catalina.filters.CorsFilter.doFilter(CorsFilter.java:170) 2019-03-20T10:32:28.502+ [APP/PROC/WEB/0] ERR at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193) 2019-03-20T10:32:28.502+ [APP/PROC/WEB/0] ERR at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) 2019-03-20T10:32:28.502+ [APP/PROC/WEB/0] ERR at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:199) 2019-03-20T10:32:28.502+ [APP/PROC/WEB/0] ERR at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:96) 2019-03-20T10:32:28.502+ [APP/PROC/WEB/0] ERR at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:493) 2019-03-20T10:32:28.502+ [APP/PROC/WEB/0] ERR at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:140) 2019-03-20T10:32:28.502+ [APP/PROC/WEB/0] ERR at com.sap.xs.java.valves.ErrorReportValve.invoke(ErrorReportValve.java:66) 2019-03-20T10:32:28.502+ [APP/PROC/WEB/0] ERR at ch.qos.logback.access.tomcat.LogbackValve.invoke(LogbackValve.java:256) 2019-03-20T10:32:28.502+ [APP/PROC/WEB/0] ERR at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:87) 2019-03-20T10:32:28.502+ [APP/PROC/WEB/0] ERR at com.sap.xs.security.UserInfoValve.invoke(UserInfoValve.java:19) 2019-03-20T10:32:28.502+ [APP/PROC/WEB/0] ERR at com.sap.xs.statistics.tomcat.valve.RequestTracingValve.invoke(RequestTracingValve.java:43) 2019-03-20T10:32:28.502+ [APP/PROC/WEB/0] ERR at com.sap.xs.logging.catalina.RuntimeInfoValve.invoke(RuntimeInfoValve.java:40) 2019-03-20T10:32:28.502+ [APP/PROC/WEB/0] ERR at org.apache.catalina.valves.RemoteIpValve.invoke(RemoteIpValve.java:679) 2019-03-20T10:32:28.502+ [APP/PROC/WEB/0] ERR at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:342) 2019-03-20T10:32:28.502+ [APP/PROC/WEB/0] ERR at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:800) 2019-03-20T10:32:28.502+ [APP/PROC/WEB/0] ERR at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66) 2019-03-20T10:32:28.502+ [APP/PROC/WEB/0] ERR at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:806) 2019-03-20T10:32:28.502+ [APP/PROC/WEB/0] ERR at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1498) 2019-03-20T10:32:28.502+ [APP/PROC/WEB/0] ERR at
[ANN] Apache Tomcat 8.5.39 available
The Apache Tomcat team announces the immediate availability of Apache Tomcat 8.5.39. Apache Tomcat 8 is an open source software implementation of the Java Servlet, JavaServer Pages, Java Unified Expression Language, Java WebSocket and Java Authentication Service Provider Interface for Containers technologies. Apache Tomcat 8.5.x replaces 8.0.x and includes new features pulled forward from the 9.0.x branch. The notable changes since 8.5.38 include: - The APR/Native connector now supports both OpenSSL and JSSE TLS configuration syntax (NIO and NIO2 already support this) - Various improvements to NIO2 - Various fixes for HTTP/2 push requests - Refactor error handling so that errors that occur early in request processing are handled by the application's error handling where the application can be identified Please refer to the change log for the complete list of changes: http://tomcat.apache.org/tomcat-8.5-doc/changelog.html Downloads: http://tomcat.apache.org/download-80.cgi Migration guides from Apache Tomcat 7.x and 8.0.x: http://tomcat.apache.org/migration.html Enjoy! - The Apache Tomcat team - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Default Max response size in Tomcat
Hi All
I have a very basic test application which serves bytes from memory and
gives it back to the client.
Whenever i try to send the request for byte size which is of over 2 GB i
get a connection reset error in my server code and a 502 error in my chrome
console. Below 2 GB it is working fine.
In my client side i execute java script which i execute from the browser.
This basically executes an XMLHTTPRequest , gets the response (stores in
browser memory) and asks for a save.
I would like to know if there Is there max response size default value
which is set in default tomcat configuration. ? or any other hints which
you can provide in my use.
Thanks and Regards,
Saurav
Below is the servlet or server side code
response.setContentLength((int)length);
}
else
{
response.addHeader("Content-Length", Long.toString(length));
}
// response.setContentLength(kByte * 1024);
ServletOutputStream outputStream = response.getOutputStream();
byte[] buffer = new byte[1024];
Random random = new Random(System.currentTimeMillis());
long size = 0;
while (size < kByte) {
random.nextBytes(buffer);
outputStream.write(buffer);
size += 1;
}
outputStream.flush();
return;
}
}catch (Exception e) {
e.printStackTrace();
response.sendError(500, e.getMessage());
return;
}
}
Re: "Tomcat 9.0.x configuration file differences" broken
for the fortunate, you can use http://meldmerge.org/ ok its local but works well. On Wed, 20 Mar 2019 at 09:58, Mark Thomas wrote: > On 20/03/2019 06:45, Dirk Gfrörer wrote: > > Hello, > > > > before upgrading our Tomcats I usually check for any changes within the > > catalina.policy, etc. files. > > > > I use this URL > > > > https://tomcat.apache.org/migration-9.html > > > > scroll down to the very bottom and than click on the "View Differences" > > button. You get redirected to > > > > > https://gitbox.apache.org/repos/asf?p=tomcat.git=blobdiff=conf%2Fcatalina.policy=9.0.16=9.0.17 > > > > > > which than shows: > > > > Forbidden > > You don't have permission to access /repos/asf on this server. > > > > > > Same is true for > > http://tomcat.apache.org/migration-85.html > > > > Maybe someone on this list is able to check. > > The service that those URLs use has been temporarily disabled by ASF > infra due to abusive traffic. They hope to be able to re-enable it soon. > If not, we'll need to find an alternative solution. > > Mark > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: Tomcat 7 under Java 11? Re: Has anybody ever heard of "ECDHE-ECDSA-CHACHA20-POLY1305"?
On 19/03/2019 23:49, James H. H. Lampert wrote: > In response to my question: > >>> I've just (same customer as before) been asked about >>> ECDHE-ECDSA-CHACHA20-POLY1305 and ECDHE-RSA-CHACHA20-POLY1305 >>> >>> and I can't find either one on the Sun or IBM JSSE cipher lists for >>> Java 8. > > On 3/19/19, 12:34 AM, Peter@Kreuser-Online wrote: > >> Most certainly only >=Java9... (OpenJDK and Oracle, don’t know about >> IBM though) > > Thanks. > > I've since learned that IBM Midrange systems will skip 9 and 10, but > will offer Java 11 at some point. But that begs the question of whether > or not Tomcat 7 (or our webapp context) will even run under Java 11. Tomcat 7 should run. If it doesn't, it would be treated as a bug and we'd fix it. We do test it from time to time. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Inefficient ValueExpressionLiteral.getValue()
On 20/03/2019 05:13, Thibault Kruse wrote:
> Hi,
>
> when migrating from Tomcat7 to Tomcat8 for an application using javax-el
> expression evaluation on every request, we noticed a significant
> performance impact.
Try the latest 8.5.x implementation.
There are changes in Java EE 7 to the EL syntax that do have a negative
performance impact. We have made various changes over the years to
address these. If you test with the latest 8.5.x implementation (8.5.39
was released yesterday and the formal announcement will be going out
shortly) you should see some improvement.
If you still see an issue, a simple test case that reproduces the issue
would be appreciated.
Finally, note that org.mortbay.jasper:apache-el:8.0.33 is not something
that has been released by the Tomcat project.
Mark
>
> Analyzing it, we see that a call sequence like for
> ValueExpression.getValue():
>
>
> ExpressionFactory expressionFactory = new ExpressionFactoryImpl();
> CompositeELResolver elResolver = new CompositeELResolver();
> elResolver.add(new ArrayELResolver());
> elResolver.add(new ListELResolver());
> elResolver.add(new BeanELResolver());
> elResolver.add(new MapELResolver());
> elContext = new ELContext() {
> public ELResolver getELResolver() {return elResolver;}
> }
> ValueExpression ve =
> expressionFactory.createValueExpression(elContext, "...",
> Object.class);
>
> final Object result = ve.getValue(elContext);
>
> calls in tomcat-jasper-el:7.0.8:
>
> * valueExpressionLiteral.getValue(context);
> * ELSupport.coerceToType(Object obj = "foo", Class type =
> java.lang.Object.class)
>
> * returns "foo"
>
>
> whereas in org.mortbay.jasper:apache-el:8.0.33, the call becomes
>
> * valueExpressionLiteral.getValue(context);
>
> * ELContext.convertToType(Object obj = "foo", Class type =
> java.lang.Object.class)
> * elresolver.convertToType(this, obj, type); // returns null
> * ELManager.getExpressionFactory().coerceToType(obj, type)
> * ELSupport.coerceToType(Object obj = "foo", Class type =
> java.lang.Object.class)
>
> The getExpressionFactory() step in particular seems to cause harm in
> the server environment due to the impact of the ReadWriteLock.
>
> Note that what happens here is only the attempt to coerce the String
> "foo" to class Object.
>
> So the additional indirections added to
> valueExpressionLiteral.getValue() seem to be quite unnecessary for
> coercions to Object or to a class that the value is assignable from.
>
> And those indirections hurt performance badly.
>
> So I wonder whether this is a bug/weakness that should be adressed (I
> can provide a more reproducible example than baove in that case), or
> whether there is a simple ELResolver class that we should add to our
> CompositeELResolver to avoid this overhead.
>
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: "Tomcat 9.0.x configuration file differences" broken
On 20/03/2019 06:45, Dirk Gfrörer wrote: > Hello, > > before upgrading our Tomcats I usually check for any changes within the > catalina.policy, etc. files. > > I use this URL > > https://tomcat.apache.org/migration-9.html > > scroll down to the very bottom and than click on the "View Differences" > button. You get redirected to > > https://gitbox.apache.org/repos/asf?p=tomcat.git=blobdiff=conf%2Fcatalina.policy=9.0.16=9.0.17 > > > which than shows: > > Forbidden > You don't have permission to access /repos/asf on this server. > > > Same is true for > http://tomcat.apache.org/migration-85.html > > Maybe someone on this list is able to check. The service that those URLs use has been temporarily disabled by ASF infra due to abusive traffic. They hope to be able to re-enable it soon. If not, we'll need to find an alternative solution. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Inefficient ValueExpressionLiteral.getValue()
I reproduced the problem (on Java8): https://github.com/tkruse/javax-getvalue-slowdown org.apache.tomcat:tomcat-jasper-el:7.0.8 30 expressions in 85 ms org.mortbay.jasper:apache-el:8.0.33 30 expressions in 208 ms Where the slowdown can be reduced by overriding ELContext.convertToType() with a method directly calling ELSupport.coerceToType(). - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
"Tomcat 9.0.x configuration file differences" broken
Hello, before upgrading our Tomcats I usually check for any changes within the catalina.policy, etc. files. I use this URL https://tomcat.apache.org/migration-9.html scroll down to the very bottom and than click on the "View Differences" button. You get redirected to https://gitbox.apache.org/repos/asf?p=tomcat.git=blobdiff=conf%2Fcatalina.policy=9.0.16=9.0.17 which than shows: Forbidden You don't have permission to access /repos/asf on this server. Same is true for http://tomcat.apache.org/migration-85.html Maybe someone on this list is able to check. Kind Regards, DirK Gfrörer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
