svn commit: r1792171 - /tomcat/trunk/java/org/apache/catalina/tribes/group/interceptors/MessageDispatchInterceptor.java
Author: markt
Date: Fri Apr 21 09:53:16 2017
New Revision: 1792171
URL: http://svn.apache.org/viewvc?rev=1792171&view=rev
Log:
Silence IDE nags
Add @Override markers
Modified:
tomcat/trunk/java/org/apache/catalina/tribes/group/interceptors/MessageDispatchInterceptor.java
Modified:
tomcat/trunk/java/org/apache/catalina/tribes/group/interceptors/MessageDispatchInterceptor.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/tribes/group/interceptors/MessageDispatchInterceptor.java?rev=1792171&r1=1792170&r2=1792171&view=diff
==
---
tomcat/trunk/java/org/apache/catalina/tribes/group/interceptors/MessageDispatchInterceptor.java
(original)
+++
tomcat/trunk/java/org/apache/catalina/tribes/group/interceptors/MessageDispatchInterceptor.java
Fri Apr 21 09:53:16 2017
@@ -208,6 +208,7 @@ public class MessageDispatchInterceptor
}
+@Override
public void setAlwaysSend(boolean alwaysSend) {
this.alwaysSend = alwaysSend;
}
@@ -285,6 +286,7 @@ public class MessageDispatchInterceptor
* Return the current number of threads that are managed by the pool.
* @return the current number of threads that are managed by the pool
*/
+@Override
public int getPoolSize() {
if (executor instanceof ThreadPoolExecutor) {
return ((ThreadPoolExecutor) executor).getPoolSize();
@@ -297,6 +299,7 @@ public class MessageDispatchInterceptor
* Return the current number of threads that are in use.
* @return the current number of threads that are in use
*/
+@Override
public int getActiveCount() {
if (executor instanceof ThreadPoolExecutor) {
return ((ThreadPoolExecutor) executor).getActiveCount();
@@ -309,6 +312,7 @@ public class MessageDispatchInterceptor
* Return the total number of tasks that have ever been scheduled for
execution by the pool.
* @return the total number of tasks that have ever been scheduled for
execution by the pool
*/
+@Override
public long getTaskCount() {
if (executor instanceof ThreadPoolExecutor) {
return ((ThreadPoolExecutor) executor).getTaskCount();
@@ -321,6 +325,7 @@ public class MessageDispatchInterceptor
* Return the total number of tasks that have completed execution by the
pool.
* @return the total number of tasks that have completed execution by the
pool
*/
+@Override
public long getCompletedTaskCount() {
if (executor instanceof ThreadPoolExecutor) {
return ((ThreadPoolExecutor) executor).getCompletedTaskCount();
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Read events suspend/resume logic in websocket impl to achieve backpressure
On 19/04/17 11:43, Violeta Georgieva wrote: > Hi, > > 2017-03-29 23:59 GMT+03:00 Mark Thomas : >> I think the problem is that "reading in progress" and suspended are >> treated separately when it is the combination of the two that represents >> the current state. >> >> If it were me, I'd probably look at adding a state machine (but that is >> just how I tend to approach these sorts of problems). > > You are right. I reworked the patch, the new implementation is using a > state machine. The changes are available here > https://github.com/apache/tomcat/pull/42 > > Can you please take a look? I think the concurrency issues around state have been resolved. However, I do have some other review comments - one of which I think is an issue that needs to be fixed before the patch is applied. I think there is the possibility of data loss on the client. Consider the following sequence in WsFrameClient.processSocketRead(): - Large read -> response is filled - processSocketRead() copies response to inputBuffer - external thread calls suspend() - inputBuffer is not processed - while loop exits - another read is performed - that read completes and fills response - external thread calls resume() - processSocketRead() copies some of response to inputBuffer can't copy all since inputBuffer is now full data is left in response - external thread calls suspend() - inputBuffer is not processed - while loop exits - response is cleared and data is lost Minor: 1. In suspend() and resume() consider checks of the current state in all branches of the switch statement to reduce the risk of incorrect state transitions. The scenarios I can think of where this would be a problem are somewhat contrived so only a minor concern. 2. Is the SuspendableMessageReceiver interface necessary? More a style / consistency question than anything else. 3. I think resumeProcessing() needs a short Javadoc to make clear that there may be data in the input buffer that needs to be processed on resume Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 61022] New: Returning Closed Connections to the Pool
https://bz.apache.org/bugzilla/show_bug.cgi?id=61022
Bug ID: 61022
Summary: Returning Closed Connections to the Pool
Product: Tomcat Modules
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: jdbc-pool
Assignee: dev@tomcat.apache.org
Reporter: g...@hilbertinc.com
Target Milestone: ---
The connection pool was returning a closed connection to the pool. The root
cause of this was that my code was accessing the underlying ("real") connection
and closing it. My code snipped follows:
private void onResultSetExhausted() throws SQLException {
if (!getResultSet().isClosed()) {
Statement statement = getResultSet().getStatement();
if (!statement.isClosed()) {
Connection connection = statement.getConnection();
getResultSet().getStatement().close();
if (!connection.isClosed()) {
connection.close();
}
}
getResultSet().close();
}
}
This implies that the problem may be a regression of the problem described in
48392. My proposed solution is to check the real connection state in the
ProxyConnection::invoke method. A snippet of that code is:
if (compare(CLOSE_VAL,method)) {
if (connection==null) return null; //noop for already closed.
PooledConnection poolc = this.connection;
this.connection = null;
if (!poolc.getConnection().isClosed()) { // <-- Added this
pool.returnConnection(poolc);
}
return null;
} else if (compare(TOSTRING_VAL,method)) {
--
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 61022] Returning Closed Connections to the Pool
https://bz.apache.org/bugzilla/show_bug.cgi?id=61022
Christopher Schultz changed:
What|Removed |Added
Status|NEW |NEEDINFO
--- Comment #1 from Christopher Schultz ---
(In reply to Gary Murphy from comment #0)
> my code was accessing the underlying ("real")
> connection and closing it.
Umm... don't do that / NOTABUG?
--
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 61022] Returning Closed Connections to the Pool
https://bz.apache.org/bugzilla/show_bug.cgi?id=61022 --- Comment #2 from Gary Murphy --- I am not sure what you are needing. I am using the connection pool with functional programming, not in a serlvet container as the normal use case would expect. As a result, I don't always easily have the reference to the connection, unless I start passing it through the monad, which is possible, I suppose. I guess my expectation is that a proper implementation of a proxy design pattern would implement all of the use cases of the proxy. Or to put it another way, if 48392 was accepted as a bug, this should be, too. I took a second look at the code and my proposed solution might leak resources, so I updated the ConnectionPool class to check in the "returnConnection" method. What are our next steps, here? -- 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 61022] Returning Closed Connections to the Pool
https://bz.apache.org/bugzilla/show_bug.cgi?id=61022 --- Comment #3 from Christopher Schultz --- Are you saying that bug #48392 is actually not completely fixed? 48392 was reported for getResultSet().getConnection(), but the comments indicate that also getResultSet().getStatement().getConnection() was fixed as well. So, are you reporting a regression/incomplete fix for 48392 or am I missing something else? -- 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 60875] Process Request null pointer exception.
https://bz.apache.org/bugzilla/show_bug.cgi?id=60875 Mark Thomas changed: What|Removed |Added Status|NEEDINFO|RESOLVED Resolution|--- |FIXED --- Comment #5 from Mark Thomas --- Several possible root causes for this have been fixed in 8.5.14 onwards. If you still see this issue with 8.5.14 or later, please re-open and provide the steps to reproduce the issue. -- 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 60461] SIGSEGV in SSLSocket.getInfos
https://bz.apache.org/bugzilla/show_bug.cgi?id=60461 matt...@cacorp.com changed: What|Removed |Added Status|NEEDINFO|NEW --- Comment #15 from matt...@cacorp.com --- I'm sorry, I have no steps, I don't know how to reproduce it. Is there any other information I can give you? Is there anything I should do to try to figure out how to reproduce 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
[Bug 61022] Returning Closed Connections to the Pool
https://bz.apache.org/bugzilla/show_bug.cgi?id=61022 --- Comment #4 from Gary Murphy --- I didn't go back through the source code history, since 48392 was fixed in 2011. I suspect it was fixed properly and regressed at some subsequent refactor. I think the proper fix would be the one discussed there - meaning that the connection should provide a proxy for the statement and the statement should provide a proxy for the result set. That will keep the semantics of the Connection class consistent. However, the fix I made to ConnectionPool to simply check for a closed connection would be simpler and would resolve my issue. I would be glad to send that to you for your review if you would like. -- 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 60461] SIGSEGV in SSLSocket.getInfos
https://bz.apache.org/bugzilla/show_bug.cgi?id=60461 Mark Thomas changed: What|Removed |Added Status|NEW |NEEDINFO --- Comment #14 from Mark Thomas --- Steps to reproduce still required. -- 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 60875] Process Request null pointer exception.
https://bz.apache.org/bugzilla/show_bug.cgi?id=60875 --- Comment #6 from Aaron --- (In reply to Mark Thomas from comment #5) > Several possible root causes for this have been fixed in 8.5.14 onwards. > > If you still see this issue with 8.5.14 or later, please re-open and provide > the steps to reproduce the issue. Thank you for your remind. I have solved my problem by adding config useSendfile=false to connector. I will try new version and give you feedback. -- 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 60461] SIGSEGV in SSLSocket.getInfos
https://bz.apache.org/bugzilla/show_bug.cgi?id=60461 Mark Thomas changed: What|Removed |Added Status|NEW |NEEDINFO -- 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 60461] SIGSEGV in SSLSocket.getInfos
https://bz.apache.org/bugzilla/show_bug.cgi?id=60461 matt...@cacorp.com changed: What|Removed |Added Status|NEEDINFO|NEW --- Comment #16 from matt...@cacorp.com --- Looking at his log and my logs, the commonality is that it starts with a call to getAttributeNames on the request. Not sure if that helps at all, that's a call that works all the time without crashing. I have multiple sites running on the server and the crashes are not limited to just one of them. None of them are doing anything out of the ordinary, and nothing in any of my logs looks suspicious. I would LOVE to give you the info you need, but I just don't know what that could be. I need some guidance more than just NEEDINFO. -- 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
