[Bug 60762] Enhancement: Add support for runtime SNI changes in tomcat-embed

[bugzilla]

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

Mahesh  changed:

   What|Removed |Added

 CC||mahesh.ratt...@gmail.com

-- 
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 60762] Enhancement: Add support for runtime SNI changes in tomcat-embed

[bugzilla]

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

--- Comment #17 from Mahesh  ---
Hello,

I was facing this exact bug and glad it is resolved.

But I'm not sure how to proceed with this (really new to configuring tomcat).

I've configured everything in server.xml and 2 way handshaking works. But how
do I periodically call the method added to solve this bug ?

Also I'm not sure which method was actually added. How do I find the code
commit related to this bug ? I tried to find it in github repo but with no
success.

Any help will be really appreciated.

Thanks.

-- 
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

Re: Tomcat JDBC Pool memory leak when using StatementFinalizer interceptor

[Felix Schumacher]

Am 19.07.2018 um 02:18 schrieb Filip Hanik:

Thanks Martin, I agree, regardless of use case, the pool should not
generate a leak.
What do you think about adding a size test in createStatement and if it 
is bigger than a threshold start a cleanup of the list. If the list is 
after the cleanup still "too big", we could generate a warning, that the 
finalizer might not be helpful.


Regards,
 Felix



let me review your proposal

Filip

On Wed, Jul 18, 2018 at 07:48 Martin Knoblauch  wrote:


On Wed, Jul 18, 2018 at 3:24 PM, Martin Knoblauch 
wrote:


Hi  Filip,

On Fri, Jul 13, 2018 at 4:33 PM, Filip Hanik  wrote:


hi Martin,

On Fri, Jul 13, 2018 at 5:48 AM, Martin Knoblauch 
wrote:


Hi, (moving to developers list)

  any ideas on the problem below? This thing is kind of itching me :-)

So I instrumented the "StatementFinalizer" class with some logging and
learned that over time a few instances of the "StatementFinalizer" are
created, used and destroyed. So far so good. For most of those

instances,

the overall number of statements that are added to the "statements"

list by

"createStatement" and the number of statements removed from the list

by

"closeInvoked" is identical and after "closeInvoked" finishes, the

list

is

empty.

  But only for most instances of "StatementFinalizer". I could find

that

there is one instance that is used (statements are added), but the
invocation of "closednvoked" stops after some minutes into the

application.

As a result the "statements" list starts growing.


​Could it be that your application checks out a connection and uses it

for

the life time of the application?
Meaning Connection.close is never called?



  So in fact some instrumentation and digging deeper showed 3 different
problems in the application:

1) there is one SQL Statement not closed (revealed by
"StatementFinalizer(trace=true)")
2) there is one connection not closed after the "final" SQL statement
(revealed by properly activating the "Abandoned" mechanism)
3) there is one connection that is used heavily over the entire lifetime
of the application, and never closed. This one accumulates the memory

that

made me ask the "leak" question

Need to address all three to the application developers.

Given that 1+2 each only happen once, the best solution to avoid the
"leak" might really be to just not use the "StatementFinalizer".




But then, just for the fun of it, would something like this patch be of
interest? It adds a private method "removeClosed()" to the
"StatementFinalizer code. What it does is to remove all "closed" or "null"
statements from the "statements" list. In order to keep it low in the
performance profile, it only does this every "sweepMinutes" minutes (new
interceptor property). My testing shows it keeps the memory consumption
down.

Martin

---

apache-tomcat-8.0.36-src/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/interceptor/StatementFinalizer.java
2016-06-09 16:00:49.0 +0200
+++

apache-tomcat-8.0.36-src-mkn/modules/jdbc-pool/src/main/java/org/apache/tomcat/jdbc/pool/interceptor/StatementFinalizer.java
2018-07-18 14:53:35.242785369 +0200
@@ -18,7 +18,9 @@

  import java.lang.ref.WeakReference;
  import java.lang.reflect.Method;
+import java.sql.SQLException;
  import java.sql.Statement;
+import java.util.Iterator;
  import java.util.LinkedList;
  import java.util.List;
  import java.util.Map;
@@ -40,15 +42,64 @@
  protected List statements = new LinkedList<>();

  private boolean logCreationStack = false;
+private long sweepMillis = 0;
+private long lastSweep = 0;
+
+private int addedStmts = 0;
+
+/**
+ * Removes closed or "null" statements from the "statements" list. Useful
for connections that are
+ * never closed. Returns without doing anything in the following cases:
+ *  - Interceptor property "sweepMinutes" is 0 (default)
+ *  - First call after "borrow"
+ *  - Time difference between now and last sweep  has not reached yet
+ *  - Only one statement on list (or list is empty)
+ */
+private void removeClosed() {
+
+if (sweepMillis == 0)  // Nothing to do
+return;
+if (lastSweep == 0) {  // First time around. Nothing to do
+lastSweep = System.currentTimeMillis();
+return;
+}
+if ((System.currentTimeMillis() - lastSweep) < sweepMillis) // Age not
reached, nothing to do
+return;
+if (statements.size() < 2) // empty, or exactely one statement (has
just been added), nothing to do
+return;
+
+lastSweep = System.currentTimeMillis();
+Iterator it = statements.iterator();
+int clsdStmts = 0;
+int nullStmts = 0;
+while(it.hasNext()){
+StatementEntry ws = (StatementEntry)it.next();
+Statement st = ws.getStatement();
+try {
+if (st == null) nullStmts++;
+else if (st.isClosed()) clsdStmts++;
+if ((st == null) || st.isClosed()) it.remove();
+} catch (SQLException e) {
+//ignore 

Re: JDK Release Cadence

[Mark Thomas]

On July 19, 2018 2:29:37 PM UTC, Johannes Elsinghorst 
 wrote:
>Hello,
>I am currently looking into what the new release cadence for the JDK
>means for Tomcat.
>-Is there a plan for tomcat to support Oracles new release cadence,
>i.e. supporting all versions of the JDK or only the LTS  versions?
>-Which JDK are supported by Tomcat? Like  Oracle JDK (Free),  Oracle
>JDK (Commercial), AdoptOpenJDK, Zulu Enterprise
>If this is not the right place to ask these questions please point me
>in the right direction.
>
>Thanks,
>Johannes
>
>
>-
>To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
>For additional commands, e-mail: dev-h...@tomcat.apache.org

Tomcat has a (spec mandated) minimum Java version.

To date we have supported Tomcat on any JVM that a) meets the minimum version 
requirement and b) passes the Java TCK irrespective of vendor.

So far, the change in release cadence hasn't changed that. I also don't see 
anything that would change that.

The latest Tomcat 7 8 and 9 releases all work on Java 10 and with the 11 EA 
release. Now the first 12 EA release is out we'll be testing that too.

If someone finds and reports a Java version related bug I my expectation is 
that it will be fixed. Almost certainly for the next release.

HTH,

Mark

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

JDK Release Cadence

[Johannes Elsinghorst]

Hello,
I am currently looking into what the new release cadence for the JDK means for 
Tomcat.
-Is there a plan for tomcat to support Oracles new release cadence, i.e. 
supporting all versions of the JDK or only the LTS  versions?
-Which JDK are supported by Tomcat? Like  Oracle JDK (Free),  Oracle JDK 
(Commercial), AdoptOpenJDK, Zulu Enterprise
If this is not the right place to ask these questions please point me in the 
right direction.

Thanks,
Johannes


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

Re: Don't require a base directory?

[Romain Manni-Bucau]

up? :)

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le dim. 15 juil. 2018 à 12:12, Romain Manni-Bucau  a
écrit :

> Hi guys,
>
> Just tested with Tomcat 9.0.10 embed and it seems the requirement is a
> base directory is now arbitrary.
>
> To be concrete I overrided org.apache.catalina.startup.Tomcat#initBaseDir
> to not mkdir the folder if it doesn't exist and I ran several apps
> (including meecrowave/cdi based ones) without any issue.
>
> Is it possible to relax this constraint? I envision it as a toggle
> settable on Tomcat instance (tomcat.setRequiresDirectories(false)). If set
> it to false it would disable the mkdir and probably disable the webapp
> extractions.
>
> Guess spring boot can benefit from it as well.
>
> Wdyt?
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github
>  | LinkedIn
>  | Book
> 
>