[Bug 63691] New: Add a no-op JarScanner

2019-08-24 Thread bugzilla
https://bz.apache.org/bugzilla/show_bug.cgi?id=63691

Bug ID: 63691
   Summary: Add a no-op JarScanner
   Product: Tomcat 9
   Version: unspecified
  Hardware: PC
Status: NEW
  Severity: normal
  Priority: P2
 Component: Catalina
  Assignee: dev@tomcat.apache.org
  Reporter: isa...@apache.org
  Target Milestone: -

When running Tomcat in embedded mode it is many times desired to skip all of
the jar scanning in favor of a faster startup.  While it's possible to create
an anonymous class, I propose to add a simple NoOp class, e.g. 
org.apache.tomcat.util.scan.NoopJarScanner, possibly with a Singleton instance,
which will have do nothing.

Then we'd be able to easily call
`context.setJarScanner(NoopJarScanner.INSTANCE)`.

If approved, I'd be happy to implement it.

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



JDK 13 is now in the Release Candidate Phase & JDK 14 build 11 is available.

2019-08-24 Thread Rory O'Donnell

Hi Mark,

*JDK 13 is now in the Release Candidate Phase
*

Per the JDK 13 schedule [1], we are now in the Release Candidate phase.
The stabilization repository, jdk/jdk13, is open for P1 bug fixes per 
the JDK Release Process (JEP 3) [2].

All changes require approval via the Fix-Request Process [3].

For more details, see Mark Reinhold's email to jdk-dev mailing list [4]

 * Milestone Schedule:
 o GAC - Aug 22, 2019
 o GAR - Sept 5, 2019
 o GA - Sept 17, 2019

**OpenJDK 14 *EA build 11 is now available at **http://jdk.java.net/14**
*

 * These early access, open source builds are provided under the GNU
   General Public License, versionĀ 2, with the Classpath Exception
   .
 * Release Notes
 o http://jdk.java.net/14/release-notes
 * JEPs targeted to JDK 14
 o JEP 352  - Non-Volatile Mapped
   Byte Buffers
 * Significant changes since the last availability email:
 o Build 10
 + 8226374: Restrict TLS signature schemes and named groups
 + 8227439: Turn off AOT by default
 o Build 11
 + 8224974: Implement JEP 352
 * Changes in this build
   


*jpackage EA - **Build 1 (2019/8/20) *

 * This is an early access build of JEP 343: Packaging Tool
   , aimed at testing a prototype
   implementation of jpackage, which is a new tool for packaging
   self-contained Java applications along with a Java Runtime Environment.
 * Build 1 (2019/8/20) is now available http://jdk.java.net/jpackage/
 * Please send feedback via e-mail to core-libs-...@openjdk.java.net
   

Regards,
Rory

[1] https://openjdk.java.net/projects/jdk/13/#Schedule
[2] https://openjdk.java.net/jeps/3
[3] https://openjdk.java.net/jeps/3#Fix-Request-Process
[4] https://mail.openjdk.java.net/pipermail/jdk-dev/2019-August/003250.html

--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland



[Bug 63690] [HTTP/2] The socket [*] associated with this connection has been closed.

2019-08-24 Thread bugzilla
https://bz.apache.org/bugzilla/show_bug.cgi?id=63690

--- Comment #5 from Mark Thomas  ---
Correct. Tx.

-- 
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 48392] jdbc-pool is not returning the proxied connection in resultSet and statement

2019-08-24 Thread bugzilla
https://bz.apache.org/bugzilla/show_bug.cgi?id=48392

--- Comment #10 from sophia  ---
(In reply to gfernandes from comment #1)
> jdbc-pool version is: 1.0.7.1

You can correct that with another strategy to solve this problem. Our developer
team was facing the problem when they work on https://www.dissertationboss.com
project. Developers team solve the problem by applying a new strategy to solve
the problem.

-- 
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 63690] [HTTP/2] The socket [*] associated with this connection has been closed.

2019-08-24 Thread bugzilla
https://bz.apache.org/bugzilla/show_bug.cgi?id=63690

--- Comment #4 from Boris Petrov  ---
Thank you for the support, Mark.

As I said, this happens with both the latest Chrome and Firefox, as well as
Firefox 47 (these are the three browsers I tested with). Only when using
HTTP/2. The client side is making a POST request to upload a file. The library
that we use is "jQuery File Upload"
(https://github.com/blueimp/jQuery-File-Upload). We split the file in 1 MB
chunks with that library. In 99% of the cases the first request fails. Does
that give you any ideas?

I'll try setting `overheadDataThreadhold` to 0 on Monday and post the findings.
You need the same logging as I already provided, just with that setting,
correct?

Thanks again!

-- 
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 63690] [HTTP/2] The socket [*] associated with this connection has been closed.

2019-08-24 Thread bugzilla
https://bz.apache.org/bugzilla/show_bug.cgi?id=63690

--- Comment #3 from Mark Thomas  ---
The request has triggered the overhead protection because it looks abusive
(small non-final DATA frame). Setting overheadDataThreadhold to zero will
disable the specific protection triggered.
A debug trace with that disabled would be interesting to see how many frames
like that the client is producing. It would also be worth looking into why the
client is behaving that way.

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