[GitHub] [commons-jcs] CAIWan1998 opened a new pull request, #92: Improve performance in the Test phase
CAIWan1998 opened a new pull request, #92: URL: https://github.com/apache/commons-jcs/pull/92 Maven will run all tests in a single forked VM by default. This can be problematic if there are a lot of tests or some very memory-hungry ones. We can fork more test VM by setting `1.5C`. = If there are any inappropriate modifications in this PR, please give me a reply and I will change them. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (DBCP-585) Connection level JMX queries result in concurrent access to connection objects, causing errors
[
https://issues.apache.org/jira/browse/DBCP-585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17526929#comment-17526929
]
Gary D. Gregory commented on DBCP-585:
--
[~Kurtcebe Eroglu]
Please see Phil's previous comment, basically looks good but we need tests
added to the PR.
TY!
> Connection level JMX queries result in concurrent access to connection
> objects, causing errors
> --
>
> Key: DBCP-585
> URL: https://issues.apache.org/jira/browse/DBCP-585
> Project: Commons DBCP
> Issue Type: Bug
>Affects Versions: 2.9.0
>Reporter: Kurtcebe Eroglu
>Priority: Major
> Attachments: 0001-DBCP-585-idea-clarification-1.patch,
> conn_instance_attrs.png, connections_attrs.png, ds_attrs.png, final.png
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> As we expose Connection objects over JMX, they may be accessed by multiple
> threads concurrently;
> a) an application thread that borrows the Connection and uses it business as
> usual,
> b) another thread simultaneously performing a JMX query, which in turn calls
> getters on the same connection object via the MBean interface.
> Also, calls to Connection object getters are mostly delegated to the
> underlying vendor-specific connection provided by the JDBC driver. For
> example, when we make the JMX query to get the "schema" attribute of the JMX
> connection object, this is translated into a
> "java.sql.Connection.getSchema()", and passed to the vendor-specific
> Connection object by DBCP. In the case of Postgres, for example, this is
> further translated to a query "select current_schema()" and sent to the
> server.
> Hence, querying connections over JMX result in concurrent access by multiple
> threads to the underlying Connection provided by the vendors, to the point
> that these two threads may be running queries simultaneously on the same
> connection.
> However, this is not supported by any of the major database vendors. Vendor
> links on Connection objects not being threadsafe:
> - [Postgres|https://jdbc.postgresql.org/documentation/head/thread.html]
> {quote}The PostgreSQL™ JDBC driver is not thread safe. The PostgreSQL server
> is not threaded. Each connection creates a new process on the server; as such
> any concurrent requests to the process would have to be serialized. The
> driver makes no guarantees that methods on connections are synchronized. It
> will be up to the caller to synchronize calls to the driver.
> {quote}
> -
> [Oracle|https://docs.oracle.com/en/database/oracle/oracle-database/19/jjdbc/JDBC-coding-tips.html#GUID-EE479007-D105-4F82-8D51-000CBBD4BC77]
>
> {quote}Oracle strongly discourages sharing a database connection among
> multiple threads. Avoid allowing multiple threads to access a connection
> simultaneously.
> {quote}
> - [Microsoft SQL
> Server|https://www.javadoc.io/doc/com.microsoft.sqlserver/mssql-jdbc/latest/com.microsoft.sqlserver.jdbc/com/microsoft/sqlserver/jdbc/SQLServerConnection.html]
> {quote}SQLServerConnection is not thread safe, however multiple statements
> created from a single connection can be processing simultaneously in
> concurrent threads.
> {quote}
> Another interesting point to note, also to do justice to previous committers
> who have put this feature in place, is that this was not always the case. In
> the following links, you may see the same links to the older versions of the
> same pages. In the past, all vendors indicated that Connection is fully
> thread-safe; [Postgres|https://www.postgresql.org/docs/7.1/jdbc-thread.html],
> [Oracle|https://docs.oracle.com/cd/A97335_02/apps.102/a83724/tips1.htm],
> [MSSQL
> Server|https://www.javadoc.io/doc/com.microsoft.sqlserver/mssql-jdbc/6.1.0.jre7/com/microsoft/sqlserver/jdbc/SQLServerConnection.html].
>
> Hence, it was once safe to expose Connection objects via JMX given the
> thread-safety guarantees for the underlying vendor connection were in place.
> But as Vendors dropped the thread-safety guarantee one by one, it is not safe
> anymore, and may actually cause convoluted errors that pop up intermittently
> due to thread races in the JDBC driver code (see an example in the comments
> section below). Accordingly, exposing Connections via JMX shall be retired
> along with dropped support from most vendors.
> Note: the Datasource MBeans, which provide a vital set of metrics have no
> such problems as they don't depend on the underlying JDBC provider.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (DBCP-585) Connection level JMX queries result in concurrent access to connection objects, causing errors
[
https://issues.apache.org/jira/browse/DBCP-585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17526928#comment-17526928
]
Phil Steitz commented on DBCP-585:
--
[~ggregory] sorry I missed this. There is a small javadoc error in the patch
(says "sets t." when it means something else). There should also be some tests
added to verify it is working as designed. But in general, yes, I am +1 on
this.
> Connection level JMX queries result in concurrent access to connection
> objects, causing errors
> --
>
> Key: DBCP-585
> URL: https://issues.apache.org/jira/browse/DBCP-585
> Project: Commons DBCP
> Issue Type: Bug
>Affects Versions: 2.9.0
>Reporter: Kurtcebe Eroglu
>Priority: Major
> Attachments: 0001-DBCP-585-idea-clarification-1.patch,
> conn_instance_attrs.png, connections_attrs.png, ds_attrs.png, final.png
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> As we expose Connection objects over JMX, they may be accessed by multiple
> threads concurrently;
> a) an application thread that borrows the Connection and uses it business as
> usual,
> b) another thread simultaneously performing a JMX query, which in turn calls
> getters on the same connection object via the MBean interface.
> Also, calls to Connection object getters are mostly delegated to the
> underlying vendor-specific connection provided by the JDBC driver. For
> example, when we make the JMX query to get the "schema" attribute of the JMX
> connection object, this is translated into a
> "java.sql.Connection.getSchema()", and passed to the vendor-specific
> Connection object by DBCP. In the case of Postgres, for example, this is
> further translated to a query "select current_schema()" and sent to the
> server.
> Hence, querying connections over JMX result in concurrent access by multiple
> threads to the underlying Connection provided by the vendors, to the point
> that these two threads may be running queries simultaneously on the same
> connection.
> However, this is not supported by any of the major database vendors. Vendor
> links on Connection objects not being threadsafe:
> - [Postgres|https://jdbc.postgresql.org/documentation/head/thread.html]
> {quote}The PostgreSQL™ JDBC driver is not thread safe. The PostgreSQL server
> is not threaded. Each connection creates a new process on the server; as such
> any concurrent requests to the process would have to be serialized. The
> driver makes no guarantees that methods on connections are synchronized. It
> will be up to the caller to synchronize calls to the driver.
> {quote}
> -
> [Oracle|https://docs.oracle.com/en/database/oracle/oracle-database/19/jjdbc/JDBC-coding-tips.html#GUID-EE479007-D105-4F82-8D51-000CBBD4BC77]
>
> {quote}Oracle strongly discourages sharing a database connection among
> multiple threads. Avoid allowing multiple threads to access a connection
> simultaneously.
> {quote}
> - [Microsoft SQL
> Server|https://www.javadoc.io/doc/com.microsoft.sqlserver/mssql-jdbc/latest/com.microsoft.sqlserver.jdbc/com/microsoft/sqlserver/jdbc/SQLServerConnection.html]
> {quote}SQLServerConnection is not thread safe, however multiple statements
> created from a single connection can be processing simultaneously in
> concurrent threads.
> {quote}
> Another interesting point to note, also to do justice to previous committers
> who have put this feature in place, is that this was not always the case. In
> the following links, you may see the same links to the older versions of the
> same pages. In the past, all vendors indicated that Connection is fully
> thread-safe; [Postgres|https://www.postgresql.org/docs/7.1/jdbc-thread.html],
> [Oracle|https://docs.oracle.com/cd/A97335_02/apps.102/a83724/tips1.htm],
> [MSSQL
> Server|https://www.javadoc.io/doc/com.microsoft.sqlserver/mssql-jdbc/6.1.0.jre7/com/microsoft/sqlserver/jdbc/SQLServerConnection.html].
>
> Hence, it was once safe to expose Connection objects via JMX given the
> thread-safety guarantees for the underlying vendor connection were in place.
> But as Vendors dropped the thread-safety guarantee one by one, it is not safe
> anymore, and may actually cause convoluted errors that pop up intermittently
> due to thread races in the JDBC driver code (see an example in the comments
> section below). Accordingly, exposing Connections via JMX shall be retired
> along with dropped support from most vendors.
> Note: the Datasource MBeans, which provide a vital set of metrics have no
> such problems as they don't depend on the underlying JDBC provider.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[GitHub] [commons-io] garydgregory commented on pull request #347: Add @SuppressWarnings("unchecked").
garydgregory commented on PR #347: URL: https://github.com/apache/commons-io/pull/347#issuecomment-1107636086 Hi @arturobernalg Thank you for the PR. I'm not 100% sure how we should handle these warnings because these can indeed cause a CCE. So maybve we should at least document this fact. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-io] garydgregory commented on pull request #349: Configure Maven Fork Test parameters
garydgregory commented on PR #349: URL: https://github.com/apache/commons-io/pull/349#issuecomment-1107534624 I don't see a need for this, all builds are already green on Windows, macOS, and Linux. We want consistency and 1 VM gives us that. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-io] CAIWan1998 opened a new pull request, #349: Configure Maven Fork Test parameters
CAIWan1998 opened a new pull request, #349: URL: https://github.com/apache/commons-io/pull/349 Maven will run all tests in a single forked VM by default. This can be problematic if there are a lot of tests or some very memory-hungry ones. We can fork more test VM by setting `1.5C`. = If there are any inappropriate modifications in this PR, please give me a reply and I will change them. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-validator] garydgregory merged pull request #74: Bump maven-antrun-plugin from 3.0.0 to 3.1.0
garydgregory merged PR #74: URL: https://github.com/apache/commons-validator/pull/74 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-logging] garydgregory merged pull request #85: Replace comparisons String.indexOf() with String.contains() method.
garydgregory merged PR #85: URL: https://github.com/apache/commons-logging/pull/85 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Comment Edited] (GEOMETRY-144) Review API in "hull" module
[
https://issues.apache.org/jira/browse/GEOMETRY-144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17526836#comment-17526836
]
Matt Juntunen edited comment on GEOMETRY-144 at 4/23/22 11:57 AM:
--
The current implementation uses an algorithm-specific design. For example,
there is a public class named {{MonotoneChain}} that implements the "monotone
chain" 2D convex hull algorithm. I'm wondering if we should abandon this in
favor of providing just a single well-rounded algorithm option. For example,
the API could simply be
{code:java}
public final class ConvexHulls {
public static ConvexHull2D create2D(Collection pts) {
// ...
}
public static ConvexHull3D create3D(Collection pts) {
// ...
}
}
{code}
This relieves users of the need to be knowledgeable about convex hull
algorithms and gives us the flexibility to swap out the algorithm later on if
needed.
was (Author: mattjuntunen):
The current implementation uses an algorithm-specific design. For example,
there is a public class named {{MonotoneChain}} that implements the "monotone
chain" 2D convex hull algorithm. I'm wondering if we should abandon this in
favor of providing just a single well-rounded algorithm option. For example,
the API could simply be
{code:java}
public final class ConvexHulls {
public static ConvexHull2D create2D(Collection pts) {
// ...
}
public static ConvexHull2D create3D(Collection pts) {
// ...
}
}
{code}
This relieves users of the need to be knowledgeable about convex hull
algorithms and gives us the flexibility to swap out the algorithm later on if
needed.
> Review API in "hull" module
> ---
>
> Key: GEOMETRY-144
> URL: https://issues.apache.org/jira/browse/GEOMETRY-144
> Project: Commons Geometry
> Issue Type: Task
>Reporter: Gilles Sadowski
>Assignee: Gilles Sadowski
>Priority: Minor
> Fix For: 1.1
>
>
> Review codes in the
> [{{commons-geometry-hull}}|https://gitbox.apache.org/repos/asf?p=commons-geometry.git;a=tree;f=commons-geometry-hull;hb=HEAD]
> module.
> (x) Minimize the public API
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (GEOMETRY-144) Review API in "hull" module
[
https://issues.apache.org/jira/browse/GEOMETRY-144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17526836#comment-17526836
]
Matt Juntunen commented on GEOMETRY-144:
The current implementation uses an algorithm-specific design. For example,
there is a public class named {{MonotoneChain}} that implements the "monotone
chain" 2D convex hull algorithm. I'm wondering if we should abandon this in
favor of providing just a single well-rounded algorithm option. For example,
the API could simply be
{code:java}
public final class ConvexHulls {
public static ConvexHull2D create2D(Collection pts) {
// ...
}
public static ConvexHull2D create3D(Collection pts) {
// ...
}
}
{code}
This relieves users of the need to be knowledgeable about convex hull
algorithms and gives us the flexibility to swap out the algorithm later on if
needed.
> Review API in "hull" module
> ---
>
> Key: GEOMETRY-144
> URL: https://issues.apache.org/jira/browse/GEOMETRY-144
> Project: Commons Geometry
> Issue Type: Task
>Reporter: Gilles Sadowski
>Assignee: Gilles Sadowski
>Priority: Minor
> Fix For: 1.1
>
>
> Review codes in the
> [{{commons-geometry-hull}}|https://gitbox.apache.org/repos/asf?p=commons-geometry.git;a=tree;f=commons-geometry-hull;hb=HEAD]
> module.
> (x) Minimize the public API
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (GEOMETRY-146) PointSet/Map closest points
[
https://issues.apache.org/jira/browse/GEOMETRY-146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17526835#comment-17526835
]
Matt Juntunen commented on GEOMETRY-146:
PR is in: https://github.com/apache/commons-geometry/pull/195
> PointSet/Map closest points
> ---
>
> Key: GEOMETRY-146
> URL: https://issues.apache.org/jira/browse/GEOMETRY-146
> Project: Commons Geometry
> Issue Type: New Feature
>Reporter: Matt Juntunen
>Priority: Major
> Fix For: 1.1
>
>
> Add methods to the new {{PointSet}} and {{PointMap}} interfaces to allow
> querying of points in order of distance from a query point.
> {code:java}
> PointSet {
> // find the closest point to pt or null if empty
> P closest(P pt);
> // iterate through points in order, with points closest to pt coming first
> Iterable closestFirst(P pt);
> // find the farthest point from pt or null if emtpy
> P farthest(P pt);
> // iterate through point in order, with points farthest from pt coming
> first
> Iterable farthestFirst(P pt);
> }
> {code}
> {{PointMap}} should have similar methods providing access to the map keys and
> entries.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[GitHub] [commons-geometry] darkma773r opened a new pull request, #195: GEOMETRY-146: adding near/far methods to PointMap and PointSet
darkma773r opened a new pull request, #195: URL: https://github.com/apache/commons-geometry/pull/195 Adding nearest/farthest and nearToFar/farToNear methods to PointMap and PointSet. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
