date:20220411

Native Compilation, Continuation 2022

2022-04-11 Thread Filip Hanik

Hi folks,

I'm jumping in on the bandwagon again. Specifically to talk some more about
native compilation. The graal compiler is making headway, and it's becoming
better and better at native compilation [1].

I'll put some historical context at the bottom of this post for clarity. I
have a few suggestions that I'd like some input on

1. Get rid of tomcat-embed-programmatic
2. Refactor existing graal JSON instructions [2]
3. Potentially introduce tomcat-embed-graal
4. Add in build feature flags to the code or code optimizations

Today
The amount of input we can provide to the graal compiler today, lets us
work around many of the issues that were the reason for the
tomcat-embed-programmatic.

For example, graal can apply build time code substitution, like mentioned
here [4]. We can also provide multiple JSON files [2], and effectively
create profiles. So there can be an NIO profile, an NIO2 profile and an APR
profile, if that's desired.

Back to Proposal
1. Remove tomcat-embed-programmatic
I believe this served its purpose.

2. Refactor existing graal JSON files
This can allow us to create profiles with various memory footprints
depending on functionality desired.

3. Potentially introduce tomcat-embed-graal
This can have various code substitutions that we find beneficial. [4]

4. Add in build feature flags to the code or code optimizations
graal can still do static analysis to optimize inclusion of code paths. as
demonstrated in this example [5]. As this seems to pollute our codebase
with graal specific stuff when it could have been done as a substitution,
I'm still presenting it to gather more opinions.

Filip

Historical Context
When we created tomcat-embed-programmatic, we did so to reduce the memory
footprint[3] of the simplest tomcat installation. At the time, the graal
compiler was indiscriminate and would absorb virtually any class file in a
library. So we created an experimental jar, tomcat-embed-programmatic, that
was reduced to be embedded, no resource files, no XML support, and removed
the reflection property setters for configurable components.

References
[1]
https://github.com/spring-projects-experimental/spring-native/issues/1426
[2]
https://github.com/apache/tomcat/tree/main/res/graal/tomcat-embed-core/native-image
[3]
https://github.com/spring-projects-experimental/spring-native/issues/1426#issuecomment-1019546681
[4]
https://github.com/spring-projects-experimental/spring-native/issues/1426#issue-1095362633
[5]
https://github.com/spring-projects-experimental/spring-native/issues/1426#issuecomment-1072581363

[Bug 65991] NPE in SSLAuthenticator.java:201 if bindOnInit="false"

2022-04-11 Thread bugzilla

https://bz.apache.org/bugzilla/show_bug.cgi?id=65991

--- Comment #6 from Amit Pande  ---
Hello Remy,

Running into the same issue even without using bindOnInit as mentioned in
comment #4.

This is the connector configuration in use.







---

I see this in logs -

Caused by: org.apache.catalina.LifecycleException: Failed to start
component
[SSLAuthenticator[StandardEngine[Catalina].StandardHost[localhost].StandardContext[]]]
at
org.apache.catalina.util.LifecycleBase.handleSubClassException(LifecycleBase.java:440)
at
org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:198)
at
org.apache.catalina.core.StandardPipeline.startInternal(StandardPipeline.java:176)
at
org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
at
org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5147)
... 10 more
Caused by: java.lang.NullPointerException
at
org.apache.catalina.authenticator.SSLAuthenticator.startInternal(SSLAuthenticator.java:201)
at
org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
... 13 more

Also, any inputs on why this is seen only on Linux and not on Windows.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[Bug 66005] New: Apache crashes, if there is a tomcat server, which can not be resolved

2022-04-11 Thread bugzilla

https://bz.apache.org/bugzilla/show_bug.cgi?id=66005

Bug ID: 66005
   Summary: Apache crashes, if there is a tomcat server, which can
not be resolved
   Product: Tomcat Connectors
   Version: 1.2.48
  Hardware: Other
OS: Linux
Status: NEW
  Severity: normal
  Priority: P2
 Component: mod_jk
  Assignee: dev@tomcat.apache.org
  Reporter: lothar.web...@gmail.com
  Target Milestone: ---

Dear Tomcat development team,
I am not sure, if this is the correct way, for reporting this bug.

We have the Issue, that apache crashes immediatly after startup,
if I add a single worker, which could not be resolved:

Tried with apache 2.4.52/2.4.53 and mod_jk 1.2.48

[debug] build_worker_map::jk_worker.c (249): creating worker myworker
[debug] wc_create_worker::jk_worker.c (153): about to create instance
myworker of ajp13
[debug] ajp_worker_factory::jk_ajp_common.c (3218): ajp worker
'myworker' type=2 created
[debug] wc_create_worker::jk_worker.c (166): about to validate and init
myworker
[debug] ajp_validate::jk_ajp_common.c (2862): worker myworker target
is 'host1.internal.example.org:8009'
[error] ajp_validate::jk_ajp_common.c (2868): worker myworker can't
resolve tomcat address host1.internal.example.org
[debug] ajp_validate::jk_ajp_common.c (2873): worker myworker contact
is disabled
[debug] jk_ajp_push::jk_ajp_common.c (1190): syncing shm for ajp
worker 'myworker' from mem (0->0) [0->0]
[debug] ajp_init::jk_ajp_common.c (3076): (alex) setting endpoint options:
[debug] ajp_init::jk_ajp_common.c (3080): keepalive:  0
[debug] ajp_init::jk_ajp_common.c (3084): socket timeout: 0
[debug] ajp_init::jk_ajp_common.c (3088): socket connect timeout: 0
[debug] ajp_init::jk_ajp_common.c (3092): buffer size:0
[debug] ajp_init::jk_ajp_common.c (3096): pool timeout:   0
[debug] ajp_init::jk_ajp_common.c (3100): ping timeout:   1
[debug] ajp_init::jk_ajp_common.c (3104): connect timeout:0
[debug] ajp_init::jk_ajp_common.c (3108): reply timeout:  0
[debug] ajp_init::jk_ajp_common.c (3112): prepost timeout:0
[debug] ajp_init::jk_ajp_common.c (3116): recovery options:   0
[debug] ajp_init::jk_ajp_common.c (3120): retries:2
[debug] ajp_init::jk_ajp_common.c (3124): max packet size:8192
[debug] ajp_init::jk_ajp_common.c (3128): retry interval: 100
[debug] ajp_init::jk_ajp_common.c (3132): busy limit: 0
[debug] ajp_create_endpoint_cache::jk_ajp_common.c (2932): (myworker)
setting connection pool size to 1 with min 1 and acquire timeout 200

There is a known bug: https://bz.apache.org/bugzilla/show_bug.cgi?id=59164
This was fixed with 1.2.42
I tried to reopen it, but I was forwarded to
"Tomcat users mailing list"

Could you help me please. May be there is a workarround.

Thanks a lot and kind Regards, Lothar

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

38 matches

Mail list logo