date:20230214

Autocommit issue with JDK 1.8, Tomcat 9.0.60, ojdbc8.jar and Oracle DB 19c (19.14.0.0)

2023-02-14 Thread Promit Banik

Hello everyone,

Recently we have done an environment setup upgradation/migration as
mentioned below for our application:
JDK 1.7 ---> JDK 1.8
Tomcat 7.0.47 ---> Tomcat 9.0.60 (Also using Apache HTTP Server along with
Apache Tomcat for new setup)
ojdbc7.jar ---> ojdbc8.jar
Oracle 12c (12.1.0.2.0) ---> Oracle 19c (19.14.0.0)

We have been facing a JDBC autocommit issue since then in this new
environment setup:

Issue: For the first time AutoCommit is true by default. We update the
value of autocommit to false and manually commit the transaction. After
that, we also close the connection. Now if we try to create another
connection object with "DataSource.getConnection()" within 10 seconds (in
debug mode), the previous connection object is getting assigned with
autocommit value to false. But, we expect a new connection object to be
assigned with autocommit value set to true.

During debugging, we found that in the "GenericObjectPool" class, inside
the method "borrowObject", the line "p = idleObjects.pollFirst();" assigns
(i) if within 10 seconds=> the value of p is the previous connection
object; or,
(ii) if after 10 seconds=> the value of p is null and thus one new
connection object is created for p with autocommit value to true

public T borrowObject(final Duration borrowMaxWaitDuration) throws
Exception {
...
...
...
while (p == null) {
create = false;
p = idleObjects.pollFirst();
if (p == null) {
p = create();
if (p != null) {
create = true;
}
}
}
.
.
.
}

-- 
Regards,
Promit Banik
8013671665

JDK 20 Release Candidate and Deprecation

2023-02-14 Thread David Delabassee

Welcome to the latest OpenJDK Quality Outreach update!

The first Release Candidates of JDK 20 have been released [1] as per the
schedule [2]. At this stage, only P1 issues will be evaluated. And with
the JDK 20 General Availability sets for March 21st, it is now time to
fully focus on JDK 21. I'd like to thank those of you who have already
provided feedback on the Early Builds of JDK 21. Feedback is always
extremely useful, even more, when it comes early in the development cycle.

We are always thinking about the future but the future is not limited to
new features (pun intended). Properly removing legacy features from the
platform is also critical. Deprecation has always been an important,
phased, and ongoing effort. To name just two recent examples,
`Thread.stop()` is removed in JDK 20 [3], and the URL Public
Constructors are deprecated in JDK 20 (see the related heads-up below).
It is important to prepare your codebase for such upcoming evolutions
sooner rather than later. To conclude on deprecation, I'll mention my
colleague Nicolai who recently did a full video on this exact topic,
i.e. "Prepare your Codebase for the Future Now!" [4].

[1] https://mail.openjdk.org/pipermail/jdk-dev/2023-February/007364.html
[2] https://openjdk.org/projects/jdk/20/
[3] https://inside.java/2022/11/09/quality-heads-up/
[4] https://inside.java/2023/02/02/newscast-41/

## Heads-Up - JDK 20 - Deprecate URL Public Constructors

The `java.net.URL` class, dating from Java SE 1.0, does not encode or
decode any URL components according to the RFC2396 escaping mechanism.
It is the responsibility of the caller to encode any fields, which need
to be escaped prior to calling URL, and also to decode any escaped
fields that are returned from URL. This has led to many usability
issues, including some potential vulnerabilities when the calling code
did not take this into consideration.

In Java SE 1.4, the `java.net.URI` class has been added to mitigate some
of the `java.net.URL` shortcomings. It also offers methods to create an
URL from an URI.

JDK 20 will deprecate all public constructors of `java.net.URL`. This
will provide a strong warning and discourage developers from using them.
To construct a URL, the `URI::toURL` alternative should instead be
preferred. To construct a `file:` based URL, `Path::toURI` should be
used prior to `URI::toURL`.

For more details, see https://bugs.openjdk.org/browse/JDK-8294241

## Heads-Up - JDK 20 - JMX Connections Use an ObjectInputFilter by Default

The default JMX agent now sets an ObjectInputFilter on the RMI
connection to restrict the types that the server will deserialize. This
should not affect normal usage of the MBeans in the JDK. Applications
which register their own MBeans in the platform MBeanServer may need to
extend the serialization filter to support any additional types that
their custom MBeans accept as parameters. The default filter already
covers any type that OpenMBeans and MXBeans might use.

The serialization filter pattern is set in
`JDK/conf/management/management.properties` using the property
`com.sun.management.jmxremote.serial.filter.pattern`. If additional Java
types need to be passed, the default can be overridden by running with
`-Dcom.sun.management.jmxremote.serial.filter.pattern=.`

Serialization Filtering and the filter pattern format are described in
detail in the Core Libraries Guide [5].

[5]
https://docs.oracle.com/en/java/javase/19/core/serialization-filtering1.html#GUID-55BABE96-3048-4A9F-A7E6-781790FF3480

## Heads-Up - Testing Loom: Scoped Values and Structured Concurrency

With one JEP in Preview (Virtual Threads - 2nd Preview) and two JEPs
incubating (Scoped Values - Incubator & Structured Concurrency - 2nd
Incubator) Loom made considerable progress in JDK 20. The Loom team is
always eager to hear from developers experimenting with those APIs,
especially given that both Scoped Values and Structured Concurrency
might become Preview in JDK 21. Feedback should be reported to the
loom-dev [6] mailing list.

[6] https://mail.openjdk.org/pipermail/loom-dev/

## JDK 20 Release Candidate builds

The Release Candidate builds (builds 36) are available [7] and are
provided under the GNU General Public License v2, with the Classpath
Exception. The Release Notes are available here [8].

[7] https://jdk.java.net/20/
[8] https://jdk.java.net/20/release-notes

### Changes in recent JDK 20 builds that may be of interest:

- JDK-8300623: Lambda deserialization regression involving Enum method
reference

- JDK-8298400: Virtual thread instability when stack overflows
- JDK-8298377: JfrVframeStream causes deadlocks in ZGC

## JDK 21 Early-Access builds

The JDK 21 Early-Access (builds 9) are available [9], and are provided
under the GNU General Public License v2, with the Classpath Exception.
The related Javadocs are available here [10] and the Release Notes here
[11].

[9] https://jdk.java.net/21/
[10]

[Bug 66476] org.apache.tomcat.util.net.Acceptor.run Socket accept failed java.io.IOException: Duplicate accept detected.

2023-02-14 Thread bugzilla

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

Omkar  changed:

   What|Removed |Added

 Resolution|DUPLICATE   |---
 Ever confirmed|1   |0
 Status|RESOLVED|UNCONFIRMED

--- Comment #2 from Omkar  ---
(In reply to Mark Thomas from comment #1)
> I suspect this is triggered by local port re-use. Possible scenarios for
> that are described in bug 65776.
> 
> I suspect what you really need is an update to Tomcat 9.0.59 or later.
> 
> It might be possible to reduce the frequency via configuration (e.g. disable
> HTTP keep-alive) but those changes may cone with performance impacts.
> 
> The users list is the place to discuss possible workarounds if a Tomcat
> upgrade is not possible.
> 
> *** This bug has been marked as a duplicate of bug 65776 ***

Hi Thomas,

Thank you for prompt response. I really appreciate that. But I am still marking
the status as "Unconfirmed" because, we have still not been able to find cause
of the weird behavior. I mean, we can "assume" reuse of local port,... but why
this happens "ONLY" for requests coming from outside network ? Why this does
not happen for requests sent from within the internal company network. I mean,
i would agree if the behaviour is same across different requests, but here the
distinction is clear. 
The issue occurs "ONLY" for external requests and not internal requests. Why is
it so ? What can we do to confirm that local port is re-used ONLY for external
requests ? 
In other words, if i upgrade to Tomcat above 9.0.59 or above and if it still
continues the wierd behavior for external requests then ? How can we be sure
that upgrade is the only solution ? The bug 65776 you have referred definetly
talks about similar issue, but it says nothing about external or internal
requests.

We need your help to understand this unusual behavior. Let us know what more
diagnostics we can perform to find the root cause. Together we can find the
cause. One more information i would like to provide you here: -

The machine on which the Tomcat is running has local IP and public IP (for
external network or world). When requests comes from within the company network
it is via local IP and when the request comes from external world, it comes via
public IP.

Thanks and Regards
Omkar Patkar

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

Buildbot failure in on tomcat-8.5.x

2023-02-14 Thread buildbot

Build status: BUILD FAILED: failed compile (failure)
Worker used: bb_worker2_ubuntu
URL: https://ci2.apache.org/#builders/36/builds/390
Blamelist: Mark Thomas 
Build Text: failed compile (failure)
Status Detected: new failure
Build Source Stamp: [branch 8.5.x] e627164acdd4aaae3056e7acdec694e477bba17a


Steps:

  worker_preparation: 0

  git: 0

  shell: 0

  shell_1: 0

  shell_2: 0

  shell_3: 0

  shell_4: 0

  shell_5: 0

  compile: 0

  shell_6: 0

  shell_7: 0

  shell_8: 0

  shell_9: 0

  Rsync docs to nightlies.apache.org: 0

  shell_10: 0

  Rsync RAT to nightlies.apache.org: 0

  compile_1: 2

  shell_11: 0

  Rsync Logs to nightlies.apache.org: 0


-- ASF Buildbot


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

Buildbot failure in on tomcat-9.0.x

2023-02-14 Thread buildbot

Build status: BUILD FAILED: failed compile (failure)
Worker used: bb_worker2_ubuntu
URL: https://ci2.apache.org/#builders/37/builds/452
Blamelist: Mark Thomas 
Build Text: failed compile (failure)
Status Detected: new failure
Build Source Stamp: [branch 9.0.x] 4ff0e72d4f0bfc8d41f2ddaca2af650723124ec4


Steps:

  worker_preparation: 0

  git: 0

  shell: 0

  shell_1: 0

  shell_2: 0

  shell_3: 0

  shell_4: 0

  shell_5: 0

  compile: 1

  shell_6: 0

  shell_7: 0

  shell_8: 0

  shell_9: 0

  Rsync docs to nightlies.apache.org: 0

  shell_10: 0

  Rsync RAT to nightlies.apache.org: 0

  compile_1: 2

  shell_11: 0

  Rsync Logs to nightlies.apache.org: 0


-- ASF Buildbot


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

[Bug 65776] "Duplicate accept detected" error from a subsequent request with the same local port

2023-02-14 Thread bugzilla

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

Mark Thomas  changed:

   What|Removed |Added

 CC||patkarom...@gmail.com

--- Comment #17 from Mark Thomas  ---
*** Bug 66476 has been marked as a duplicate of this bug. ***

-- 
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 66476] org.apache.tomcat.util.net.Acceptor.run Socket accept failed java.io.IOException: Duplicate accept detected.

2023-02-14 Thread bugzilla

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

Mark Thomas  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|NEW |RESOLVED

--- Comment #1 from Mark Thomas  ---
I suspect this is triggered by local port re-use. Possible scenarios for that
are described in bug 65776.

I suspect what you really need is an update to Tomcat 9.0.59 or later.

It might be possible to reduce the frequency via configuration (e.g. disable
HTTP keep-alive) but those changes may cone with performance impacts.

The users list is the place to discuss possible workarounds if a Tomcat upgrade
is not possible.

*** This bug has been marked as a duplicate of bug 65776 ***

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

50 matches

Mail list logo