[Bug 54664] New: [1.1.27 branch] Poll.remove incorrectly reports APR_SUCCESS instead of APR_NOTFOUND for socket without poll
https://issues.apache.org/bugzilla/show_bug.cgi?id=54664 Bug ID: 54664 Summary: [1.1.27 branch] Poll.remove incorrectly reports APR_SUCCESS instead of APR_NOTFOUND for socket without poll Product: Tomcat Native Version: 1.1.27 Hardware: PC OS: Linux Status: NEW Severity: regression Priority: P2 Component: Library Assignee: dev@tomcat.apache.org Reporter: vlser...@gmail.com Classification: Unclassified Considering the patch at Wed Nov 28 07:19:46 2012 UTC (3 months, 1 week ago) by mturk http://svn.apache.org/viewvc/tomcat/native/tags/TOMCAT_NATIVE_1_1_27/native/src/poll.c?r1=1413136&r2=1414560&diff_format=h Patch was applied only to branch and not in trunk yet. But it has a bug regarding Poll.remove() optimization. In case when socket is not linked to any pollset, the result of remove() call should be APR_NOTFOUND, not APR_SUCCESS in lines 262-263. -- 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 54663] JSP Comment processing in jsp:include
https://issues.apache.org/bugzilla/show_bug.cgi?id=54663 Mark Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #2 from Mark Thomas --- JSP.1.3.10.1 EBNF Grammar for JSP Syntax makes it clear that this is not permitted. -- 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 54665] New: Provide JNDI support for java.net.URL resources
https://issues.apache.org/bugzilla/show_bug.cgi?id=54665 Bug ID: 54665 Summary: Provide JNDI support for java.net.URL resources Product: Tomcat 7 Version: unspecified Hardware: PC Status: NEW Severity: normal Priority: P2 Component: Catalina Assignee: dev@tomcat.apache.org Reporter: giovanni.dallog...@addvalue.it Classification: Unclassified At the moment, the URL resource is not provided via JNDI. This is very useful while installing your application in different environments (test / integration / live). Of course, you can write an ObjectFactory, but this requires a "not standard" installation of tomcat. Please, view a use-case and a possible solution here: http://codelevain.wordpress.com/2010/12/18/url-as-jndi-resource/ Thanks in advance. G.D. -- 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
svn commit: r1455102 - /tomcat/trunk/java/org/apache/coyote/http11/upgrade/AbstractServletOutputStream.java
Author: markt
Date: Mon Mar 11 11:49:28 2013
New Revision: 1455102
URL: http://svn.apache.org/r1455102
Log:
Update method name in comment
Modified:
tomcat/trunk/java/org/apache/coyote/http11/upgrade/AbstractServletOutputStream.java
Modified:
tomcat/trunk/java/org/apache/coyote/http11/upgrade/AbstractServletOutputStream.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/coyote/http11/upgrade/AbstractServletOutputStream.java?rev=1455102&r1=1455101&r2=1455102&view=diff
==
---
tomcat/trunk/java/org/apache/coyote/http11/upgrade/AbstractServletOutputStream.java
(original)
+++
tomcat/trunk/java/org/apache/coyote/http11/upgrade/AbstractServletOutputStream.java
Mon Mar 11 11:49:28 2013
@@ -44,7 +44,7 @@ public abstract class AbstractServletOut
sm.getString("upgrade.sos.canWrite.is"));
}
-// Make sure canWrite() and onWritePossible() have a consistent view of
+// Make sure isReady() and onWritePossible() have a consistent view of
// buffer and fireListener when determining if the listener should fire
synchronized (fireListenerLock) {
boolean result = (buffer == null);
@@ -128,7 +128,7 @@ public abstract class AbstractServletOut
} catch (IOException ioe) {
throw new RuntimeException(ioe);
}
-// Make sure canWrite() and onWritePossible() have a consistent view of
+// Make sure isReady() and onWritePossible() have a consistent view of
// buffer and fireListener when determining if the listener should fire
boolean fire = false;
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1455167 - /tomcat/trunk/java/org/apache/tomcat/util/net/NioEndpoint.java
Author: markt
Date: Mon Mar 11 14:58:54 2013
New Revision: 1455167
URL: http://svn.apache.org/r1455167
Log:
Fix upgraded connections (i.e. WebSocket) and SSL for the NIO connector
Modified:
tomcat/trunk/java/org/apache/tomcat/util/net/NioEndpoint.java
Modified: tomcat/trunk/java/org/apache/tomcat/util/net/NioEndpoint.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/net/NioEndpoint.java?rev=1455167&r1=1455166&r2=1455167&view=diff
==
--- tomcat/trunk/java/org/apache/tomcat/util/net/NioEndpoint.java (original)
+++ tomcat/trunk/java/org/apache/tomcat/util/net/NioEndpoint.java Mon Mar 11
14:58:54 2013
@@ -1548,7 +1548,22 @@ public class NioEndpoint extends Abstrac
int handshake = -1;
try {
-if (key!=null) handshake =
socket.handshake(key.isReadable(), key.isWritable());
+if (key != null) {
+if (socket.isHandshakeComplete()) {
+handshake = 0;
+} else {
+handshake = socket.handshake(
+key.isReadable(), key.isWritable());
+// The handshake process reads/writes from/to the
+// socket. status may therefore be OPEN_WRITE once
+// the handshake completes. However, the handshake
+// happens when the socket is opened so the status
+// must always be OPEN_READ after it completes. It
+// is OK to always set this as it is only used if
+// the handshake completes.
+status = SocketStatus.OPEN_READ;
+}
+}
}catch ( IOException x ) {
handshake = -1;
if ( log.isDebugEnabled() ) log.debug("Error during SSL
handshake",x);
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[Tomcat Wiki] Update of "PythonLanguage" by JamesMetelak
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Tomcat Wiki" for change notification. The "PythonLanguage" page has been changed by JamesMetelak: http://wiki.apache.org/tomcat/PythonLanguage?action=diff&rev1=6&rev2=7 Python is a dynamic, interpreted, interactive object-oriented language, built to be somewhere between mid-level language C and shell script. Python includes a lot of libraries out-of-the-box (motto: "battery included"). Links: + * [[http://www.python.org/|Python Official Homepage]] * [[http://wiki.python.org/|Python Official Wiki]] + * - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Tomcat Wiki] Trivial Update of "PythonLanguage" by JamesMetelak
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Tomcat Wiki" for change notification. The "PythonLanguage" page has been changed by JamesMetelak: http://wiki.apache.org/tomcat/PythonLanguage?action=diff&rev1=7&rev2=8 * [[http://www.python.org/|Python Official Homepage]] * [[http://wiki.python.org/|Python Official Wiki]] - * + * [[http://russianaccent.net/|Russian Accent]] - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Tomcat Wiki] Update of "LocalBadContent" by ChuckCaldarale
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Tomcat Wiki" for change notification. The "LocalBadContent" page has been changed by ChuckCaldarale: http://wiki.apache.org/tomcat/LocalBadContent?action=diff&rev1=77&rev2=78 profi-fachuebersetzung\.de profi-fachuebersetzungen\.de profischnell\.com + russianaccent\.net sanfranciscodentistdds\.com sanfrancisco-weddingphotographers\.com scotnothingtodowithyou\.com - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1455201 - /tomcat/trunk/java/org/apache/coyote/http11/upgrade/AbstractServletOutputStream.java
Author: markt
Date: Mon Mar 11 15:59:06 2013
New Revision: 1455201
URL: http://svn.apache.org/r1455201
Log:
Fix concurrency issue.
doWrite() add the socket to the poller if there are bytes left to wrote. The
may poller fire and execution could reach onWritePossible() before the
remaining bytes have been copied to the buffer thereby triggering an NPE.
Modified:
tomcat/trunk/java/org/apache/coyote/http11/upgrade/AbstractServletOutputStream.java
Modified:
tomcat/trunk/java/org/apache/coyote/http11/upgrade/AbstractServletOutputStream.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/coyote/http11/upgrade/AbstractServletOutputStream.java?rev=1455201&r1=1455200&r2=1455201&view=diff
==
---
tomcat/trunk/java/org/apache/coyote/http11/upgrade/AbstractServletOutputStream.java
(original)
+++
tomcat/trunk/java/org/apache/coyote/http11/upgrade/AbstractServletOutputStream.java
Mon Mar 11 15:59:06 2013
@@ -68,17 +68,19 @@ public abstract class AbstractServletOut
@Override
public void write(int b) throws IOException {
-preWriteChecks();
-
-writeInternal(new byte[] { (byte) b }, 0, 1);
+synchronized (writeLock) {
+preWriteChecks();
+writeInternal(new byte[] { (byte) b }, 0, 1);
+}
}
@Override
public void write(byte[] b, int off, int len) throws IOException {
-preWriteChecks();
-
-writeInternal(b, off, len);
+synchronized (writeLock) {
+preWriteChecks();
+writeInternal(b, off, len);
+}
}
@@ -97,51 +99,50 @@ public abstract class AbstractServletOut
private void writeInternal(byte[] b, int off, int len) throws IOException {
-synchronized (writeLock) {
-if (listener == null) {
-// Simple case - blocking IO
-doWrite(true, b, off, len);
+if (listener == null) {
+// Simple case - blocking IO
+doWrite(true, b, off, len);
+} else {
+// Non-blocking IO
+// If the non-blocking read does not complete, doWrite() will add
+// the socket back into the poller. The poller way trigger a new
+// write event before this method has finished updating buffer.
This
+// sync makes sure that buffer is updated before the next write
+// executes.
+int written = doWrite(false, b, off, len);
+if (written < len) {
+// TODO: - Reuse the buffer
+// - Only reallocate if it gets too big (>8k?)
+buffer = new byte[len - written];
+System.arraycopy(b, off + written, buffer, 0, len - written);
} else {
-// Non-blocking IO
-// If the non-blocking read does not complete, doWrite() will
add
-// the socket back into the poller. The poller way trigger a
new
-// write event before this method has finished updating
buffer. This
-// sync makes sure that buffer is updated before the next write
-// executes.
-int written = doWrite(false, b, off, len);
-if (written < len) {
-// TODO: - Reuse the buffer
-// - Only reallocate if it gets too big (>8k?)
-buffer = new byte[len - written];
-System.arraycopy(b, off + written, buffer, 0, len -
written);
-} else {
-buffer = null;
-}
+buffer = null;
}
}
}
protected final void onWritePossible() {
-try {
-writeInternal(buffer, 0, buffer.length);
-} catch (IOException ioe) {
-throw new RuntimeException(ioe);
-}
-// Make sure isReady() and onWritePossible() have a consistent view of
-// buffer and fireListener when determining if the listener should fire
-boolean fire = false;
-
-synchronized (fireListenerLock) {
-if (buffer == null && fireListener) {
-fireListener = false;
-fire = true;
+synchronized (writeLock) {
+try {
+writeInternal(buffer, 0, buffer.length);
+} catch (IOException ioe) {
+throw new RuntimeException(ioe);
+}
+// Make sure isReady() and onWritePossible() have a consistent
view of
+// buffer and fireListener when determining if the listener should
fire
+boolean fire = false;
+
+synchronized (fireListenerLock) {
+if (buffer == null && fireListener) {
+fireListener = false;
+fire = true;
+}
+}
+if (fire) {
+listener.o
[Bug 54668] New: java picture
https://issues.apache.org/bugzilla/show_bug.cgi?id=54668 Bug ID: 54668 Summary: java picture Product: Tomcat 7 Version: unspecified Hardware: Other URL: http://apache.org/system/framework/core.jar OS: Mac OS X 10.3 Status: NEW Severity: normal Priority: P3 Component: Servlet & JSP API Assignee: dev@tomcat.apache.org Reporter: kurt_gado...@yahoo.com Classification: Unclassified -- 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 54668] java picture
https://issues.apache.org/bugzilla/show_bug.cgi?id=54668 --- Comment #1 from Kurt --- Created attachment 30036 --> https://issues.apache.org/bugzilla/attachment.cgi?id=30036&action=edit system java photo -- 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 54668] java picture
https://issues.apache.org/bugzilla/show_bug.cgi?id=54668 Kurt changed: What|Removed |Added Attachment #30036|0 |1 is patch|| -- 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 54668] java picture
https://issues.apache.org/bugzilla/show_bug.cgi?id=54668 Mark Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #2 from Mark Thomas --- Spam. -- 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
[jira] [Created] (MTOMCAT-215) Multiple manifests under META-INF, two Main-Class entries
Tim Astle created MTOMCAT-215: - Summary: Multiple manifests under META-INF, two Main-Class entries Key: MTOMCAT-215 URL: https://issues.apache.org/jira/browse/MTOMCAT-215 Project: Apache Tomcat Maven Plugin Issue Type: Bug Components: tomcat7 Affects Versions: 2.1 Reporter: Tim Astle Assignee: Olivier Lamy (*$^¨%`£) Priority: Minor Relates to this post: http://www.mail-archive.com/users@tomcat.apache.org/msg104817.html When using the -standalone jar / war mojos and looked into the artifact that they produced, I noticed that the META-INF directory contained mulitple MANIFEST.MF entries. I know that the zip archive format supports this, but I'm worried that it may produce undesirable behaviour. Two of the manifest entries define a Main-Class. I'm uncertain how a winner is determined when -jar is the only option provided via command line. Additionally, for users who unzip an archive to make modifications, they could potentially blow-away the desirable manifest when manifests are overwritten to the same location on disk, thus crippling the executable jar / war functionality. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[jira] [Updated] (MTOMCAT-215) Multiple manifests under META-INF, two Main-Class entries
[ https://issues.apache.org/jira/browse/MTOMCAT-215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim Astle updated MTOMCAT-215: -- Attachment: AbstractExecWarMojo.java.patch This patch prevents MANIFEST.MF files from being included in the final package. Do you know of a better way to do this? I kinda peeked around the commons compression API and JAR API, but nothing stood out. > Multiple manifests under META-INF, two Main-Class entries > - > > Key: MTOMCAT-215 > URL: https://issues.apache.org/jira/browse/MTOMCAT-215 > Project: Apache Tomcat Maven Plugin > Issue Type: Bug > Components: tomcat7 >Affects Versions: 2.1 >Reporter: Tim Astle >Assignee: Olivier Lamy (*$^¨%`£) >Priority: Minor > Attachments: AbstractExecWarMojo.java.patch > > > Relates to this post: > http://www.mail-archive.com/users@tomcat.apache.org/msg104817.html > When using the -standalone jar / war mojos and looked into the artifact that > they produced, I noticed that the META-INF directory contained mulitple > MANIFEST.MF entries. I know that the zip archive format supports this, but > I'm worried that it may produce undesirable behaviour. > Two of the manifest entries define a Main-Class. I'm uncertain how a winner > is determined when -jar is the only option provided via command line. > Additionally, for users who unzip an archive to make modifications, they > could potentially blow-away the desirable manifest when manifests are > overwritten to the same location on disk, thus crippling the executable jar / > war functionality. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[jira] [Updated] (MTOMCAT-215) Multiple manifests under META-INF, two Main-Class entries
[ https://issues.apache.org/jira/browse/MTOMCAT-215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim Astle updated MTOMCAT-215: -- Description: Relates to this post: http://www.mail-archive.com/users@tomcat.apache.org/msg104817.html When using the -standalone jar / war mojos and looked into the artifact that they produced, I noticed that the META-INF directory contained mulitple MANIFEST.MF entries. I know that the zip archive format supports this, but I'm worried that it may produce undesirable behaviour as two of the manifest entries define a Main-Class. I'm uncertain how a winner is determined when -jar is the only option provided via command line. Additionally, for users who unzip an archive to make modifications, they could potentially blow-away the desirable manifest when manifests are overwritten to the same location on disk, thus crippling the executable jar / war functionality. was: Relates to this post: http://www.mail-archive.com/users@tomcat.apache.org/msg104817.html When using the -standalone jar / war mojos and looked into the artifact that they produced, I noticed that the META-INF directory contained mulitple MANIFEST.MF entries. I know that the zip archive format supports this, but I'm worried that it may produce undesirable behaviour. Two of the manifest entries define a Main-Class. I'm uncertain how a winner is determined when -jar is the only option provided via command line. Additionally, for users who unzip an archive to make modifications, they could potentially blow-away the desirable manifest when manifests are overwritten to the same location on disk, thus crippling the executable jar / war functionality. > Multiple manifests under META-INF, two Main-Class entries > - > > Key: MTOMCAT-215 > URL: https://issues.apache.org/jira/browse/MTOMCAT-215 > Project: Apache Tomcat Maven Plugin > Issue Type: Bug > Components: tomcat7 >Affects Versions: 2.1 >Reporter: Tim Astle >Assignee: Olivier Lamy (*$^¨%`£) >Priority: Minor > Attachments: AbstractExecWarMojo.java.patch > > > Relates to this post: > http://www.mail-archive.com/users@tomcat.apache.org/msg104817.html > When using the -standalone jar / war mojos and looked into the artifact that > they produced, I noticed that the META-INF directory contained mulitple > MANIFEST.MF entries. I know that the zip archive format supports this, but > I'm worried that it may produce undesirable behaviour as two of the manifest > entries define a Main-Class. I'm uncertain how a winner is determined when > -jar is the only option provided via command line. > Additionally, for users who unzip an archive to make modifications, they > could potentially blow-away the desirable manifest when manifests are > overwritten to the same location on disk, thus crippling the executable jar / > war functionality. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[jira] [Commented] (MTOMCAT-215) Multiple manifests under META-INF, two Main-Class entries
[ https://issues.apache.org/jira/browse/MTOMCAT-215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13599206#comment-13599206 ] Tim Astle commented on MTOMCAT-215: --- There are also multiple LICENSE and NOTICE files under the META-INF, but I was less concerned about those as I can't see those causing any potential technical issues. Worst case, on unzip, those files are overwritten or renamed. > Multiple manifests under META-INF, two Main-Class entries > - > > Key: MTOMCAT-215 > URL: https://issues.apache.org/jira/browse/MTOMCAT-215 > Project: Apache Tomcat Maven Plugin > Issue Type: Bug > Components: tomcat7 >Affects Versions: 2.1 >Reporter: Tim Astle >Assignee: Olivier Lamy (*$^¨%`£) >Priority: Minor > Attachments: AbstractExecWarMojo.java.patch > > > Relates to this post: > http://www.mail-archive.com/users@tomcat.apache.org/msg104817.html > When using the -standalone jar / war mojos and looked into the artifact that > they produced, I noticed that the META-INF directory contained mulitple > MANIFEST.MF entries. I know that the zip archive format supports this, but > I'm worried that it may produce undesirable behaviour as two of the manifest > entries define a Main-Class. I'm uncertain how a winner is determined when > -jar is the only option provided via command line. > Additionally, for users who unzip an archive to make modifications, they > could potentially blow-away the desirable manifest when manifests are > overwritten to the same location on disk, thus crippling the executable jar / > war functionality. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1455314 - in /tomcat/trunk/java/org/apache: coyote/http11/upgrade/AprServletInputStream.java coyote/http11/upgrade/AprServletOutputStream.java tomcat/util/net/SocketWrapper.java
Author: markt
Date: Mon Mar 11 20:30:49 2013
New Revision: 1455314
URL: http://svn.apache.org/r1455314
Log:
APR read/write need to use the same locks for changing the blocking status of
the socket
Modified:
tomcat/trunk/java/org/apache/coyote/http11/upgrade/AprServletInputStream.java
tomcat/trunk/java/org/apache/coyote/http11/upgrade/AprServletOutputStream.java
tomcat/trunk/java/org/apache/tomcat/util/net/SocketWrapper.java
Modified:
tomcat/trunk/java/org/apache/coyote/http11/upgrade/AprServletInputStream.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/coyote/http11/upgrade/AprServletInputStream.java?rev=1455314&r1=1455313&r2=1455314&view=diff
==
---
tomcat/trunk/java/org/apache/coyote/http11/upgrade/AprServletInputStream.java
(original)
+++
tomcat/trunk/java/org/apache/coyote/http11/upgrade/AprServletInputStream.java
Mon Mar 11 20:30:49 2013
@@ -18,7 +18,6 @@ package org.apache.coyote.http11.upgrade
import java.io.IOException;
import java.util.concurrent.locks.Lock;
-import java.util.concurrent.locks.ReentrantReadWriteLock;
import java.util.concurrent.locks.ReentrantReadWriteLock.WriteLock;
import org.apache.tomcat.jni.Socket;
@@ -29,8 +28,6 @@ public class AprServletInputStream exten
private final SocketWrapper wrapper;
private final long socket;
-private final Lock blockingStatusReadLock;
-private final WriteLock blockingStatusWriteLock;
private volatile boolean eagain = false;
private volatile boolean closed = false;
@@ -38,9 +35,6 @@ public class AprServletInputStream exten
public AprServletInputStream(SocketWrapper wrapper) {
this.wrapper = wrapper;
this.socket = wrapper.getSocket().longValue();
-ReentrantReadWriteLock lock = new ReentrantReadWriteLock();
-this.blockingStatusReadLock = lock.readLock();
-this.blockingStatusWriteLock =lock.writeLock();
}
@@ -48,10 +42,13 @@ public class AprServletInputStream exten
protected int doRead(boolean block, byte[] b, int off, int len)
throws IOException {
+Lock readLock = wrapper.getBlockingStatusReadLock();
+WriteLock writeLock = wrapper.getBlockingStatusWriteLock();
+
boolean readDone = false;
int result = 0;
try {
-blockingStatusReadLock.lock();
+readLock.lock();
if (wrapper.getBlockingStatus() == block) {
if (closed) {
throw new IOException(sm.getString("apr.closed"));
@@ -60,31 +57,31 @@ public class AprServletInputStream exten
readDone = true;
}
} finally {
-blockingStatusReadLock.unlock();
+readLock.unlock();
}
if (!readDone) {
try {
-blockingStatusWriteLock.lock();
+writeLock.lock();
wrapper.setBlockingStatus(block);
// Set the current settings for this socket
Socket.optSet(socket, Socket.APR_SO_NONBLOCK, (block ? 0 : 1));
// Downgrade the lock
try {
-blockingStatusReadLock.lock();
-blockingStatusWriteLock.unlock();
+readLock.lock();
+writeLock.unlock();
if (closed) {
throw new IOException(sm.getString("apr.closed"));
}
result = Socket.recv(socket, b, off, len);
} finally {
-blockingStatusReadLock.unlock();
+readLock.unlock();
}
} finally {
// Should have been released above but may not have been on
some
// exception paths
-if (blockingStatusWriteLock.isHeldByCurrentThread()) {
-blockingStatusWriteLock.unlock();
+if (writeLock.isHeldByCurrentThread()) {
+writeLock.unlock();
}
}
}
Modified:
tomcat/trunk/java/org/apache/coyote/http11/upgrade/AprServletOutputStream.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/coyote/http11/upgrade/AprServletOutputStream.java?rev=1455314&r1=1455313&r2=1455314&view=diff
==
---
tomcat/trunk/java/org/apache/coyote/http11/upgrade/AprServletOutputStream.java
(original)
+++
tomcat/trunk/java/org/apache/coyote/http11/upgrade/AprServletOutputStream.java
Mon Mar 11 20:30:49 2013
@@ -18,7 +18,6 @@ package org.apache.coyote.http11.upgrade
import java.io.IOException;
import java.util.concurrent.locks.Lock;
-import java.util.concurrent.locks.ReentrantReadWriteLock;
import java.util.concurrent.locks.ReentrantReadWriteLock.WriteLock;
import org.apache.tomcat.jni.Socket;
@@ -31
Re: Servlet 3.1 Request Upgrade
On 09/03/2013 23:03, Nick Williams wrote: > Mark, > > I noticed the HttpServletRequest upgrade method still had the > signature void upgrade(HttpUpgradeHandler) when it should be extends HttpUpgradeHandler> T upgrade(Class) per the latest spec. > What's your status on getting this changed? Haven't even looked at it. > I started to try to clean > this up a bit (I can email you a partial patch that has compile > errors in WebSocketServlet and WsServlet to save you some time, if > you want), but I hit a road block with WsProtocolHandler, which is > going to need a zero-arg constructor. I stopped there to avoid > stepping on your toes. No need to worry about my toes. Go ahead and make the changes. The (off the top of my head) approach I suggest for WsProtocolHandler is change the current constructor to (I was going to say init) preInit() or any other better name you can thing of and throw an exception in init() if preInit hasn't been called by the time init() is called. That should work... If it doesn't feel free to refactor to get something that does. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1455344 - /tomcat/trunk/java/org/apache/coyote/AbstractProtocol.java
Author: markt
Date: Mon Mar 11 21:48:39 2013
New Revision: 1455344
URL: http://svn.apache.org/r1455344
Log:
Fix comment typo
Modified:
tomcat/trunk/java/org/apache/coyote/AbstractProtocol.java
Modified: tomcat/trunk/java/org/apache/coyote/AbstractProtocol.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/coyote/AbstractProtocol.java?rev=1455344&r1=1455343&r2=1455344&view=diff
==
--- tomcat/trunk/java/org/apache/coyote/AbstractProtocol.java (original)
+++ tomcat/trunk/java/org/apache/coyote/AbstractProtocol.java Mon Mar 11
21:48:39 2013
@@ -666,8 +666,8 @@ public abstract class AbstractProtocol i
// Don't add sockets back to the poller if this was a
// non-blocking write otherwise the poller may trigger
// multiple read events which may lead to thread starvation
-// in the connector. The write() method will add this this
-// socket to the poller if necessary.
+// in the connector. The write() method will add this
socket
+// to the poller if necessary.
if (status != SocketStatus.OPEN_WRITE) {
longPoll(wrapper, processor);
}
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 54671] New: Spec says ServerContainerProvider#getContainer() should be public, but implemented package-private in Tomcat 8.0
https://issues.apache.org/bugzilla/show_bug.cgi?id=54671 Bug ID: 54671 Summary: Spec says ServerContainerProvider#getContainer() should be public, but implemented package-private in Tomcat 8.0 Product: Tomcat 8 Version: trunk Hardware: All OS: All Status: NEW Severity: critical Priority: P2 Component: Specification APIs Assignee: dev@tomcat.apache.org Reporter: nicho...@nicholaswilliams.net Classification: Unclassified Created attachment 30039 --> https://issues.apache.org/bugzilla/attachment.cgi?id=30039&action=edit Patch to resolve issue Fixed with attached patch. -- 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 54671] Spec says ServerContainerProvider#getContainer() should be public, but implemented package-private in Tomcat 8.0
https://issues.apache.org/bugzilla/show_bug.cgi?id=54671 Nick Williams changed: What|Removed |Added Attachment #30039|0 |1 is patch|| Attachment #30039|application/octet-stream|text/plain mime type|| -- 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 54671] Spec says ServerContainerProvider#getServerContainer() should be public, but implemented package-private in Tomcat 8.0
https://issues.apache.org/bugzilla/show_bug.cgi?id=54671 Nick Williams changed: What|Removed |Added Summary|Spec says |Spec says |ServerContainerProvider#get |ServerContainerProvider#get |Container() should be |ServerContainer() should be |public, but implemented |public, but implemented |package-private in Tomcat |package-private in Tomcat |8.0 |8.0 -- 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
svn commit: r1455354 - /tomcat/trunk/java/javax/websocket/server/ServerContainerProvider.java
Author: markt
Date: Mon Mar 11 22:48:07 2013
New Revision: 1455354
URL: http://svn.apache.org/r1455354
Log:
Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=54671
Align implementation with spec
Modified:
tomcat/trunk/java/javax/websocket/server/ServerContainerProvider.java
Modified: tomcat/trunk/java/javax/websocket/server/ServerContainerProvider.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/javax/websocket/server/ServerContainerProvider.java?rev=1455354&r1=1455353&r2=1455354&view=diff
==
--- tomcat/trunk/java/javax/websocket/server/ServerContainerProvider.java
(original)
+++ tomcat/trunk/java/javax/websocket/server/ServerContainerProvider.java Mon
Mar 11 22:48:07 2013
@@ -32,7 +32,7 @@ public abstract class ServerContainerPro
* Use the service loader API to obtain a reference to the
* {@link ServerContainer}.
*/
-static ServerContainer getServerContainer() {
+public static ServerContainer getServerContainer() {
ServerContainer result = null;
ServiceLoader serviceLoader =
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 54671] Spec says ServerContainerProvider#getServerContainer() should be public, but implemented package-private in Tomcat 8.0
https://issues.apache.org/bugzilla/show_bug.cgi?id=54671 Mark Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Mark Thomas --- Not sure how that happened. Fixed. -- 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
Strange APR/native behaviour
I have been tracking down a problem with the Autobahn test suite and APR/native connector when using SSL (all is fine with non-SSL). In the test Autobahn sends a 16MB frame to the server which the server echos back to the client. The problem I am seeing is with a non-blocking write in the AprServletOutputStream [1]. If a write returns EAGAIN (line 97) the socket is added to the poller for write notifications. The poller immediately returns the socket as ready for write. Another write is attempted that returns EAGAIN and the code enters an infinite loop with no more data ever written to the socket. If I add a delay around line 46 that slows the rate of writing down, EAGAIN is never returned and the test completes successfully. I assume I am doing something wrong. Pointers appreciated. Mark [1] http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/coyote/http11/upgrade/AprServletOutputStream.java?annotate=1455314 - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Tomcat Wiki] Trivial Update of "CathernYJ" by CathernYJ
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Tomcat Wiki" for change notification. The "CathernYJ" page has been changed by CathernYJ: http://wiki.apache.org/tomcat/CathernYJ New page: Got nothing to write about me at all.<> Enjoying to be a member of apache.org.<> I just hope I'm useful in one way here.<> <> Here is my blog [[http://www.2look4beds.com/it|please click the following page]] - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Tomcat Wiki] Update of "LocalBadContent" by ChuckCaldarale
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Tomcat Wiki" for change notification. The "LocalBadContent" page has been changed by ChuckCaldarale: http://wiki.apache.org/tomcat/LocalBadContent?action=diff&rev1=78&rev2=79 100freemb\.com 168bc\.com 24h\.msn\.hm + 2look4beds\.com 741\.com 9cy\.com accountsandadvice - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
RE: Strange APR/native behaviour
> From: Mark Thomas [mailto:ma...@apache.org] > Subject: Strange APR/native behaviour > The problem I am seeing is with a non-blocking write in the > AprServletOutputStream [1]. > If a write returns EAGAIN (line 97) the socket is added to the poller > for write notifications. The poller immediately returns the socket as > ready for write. Another write is attempted that returns EAGAIN and the > code enters an infinite loop with no more data ever written to the socket. > If I add a delay around line 46 that slows the rate of writing down, > EAGAIN is never returned and the test completes successfully. Are you positive the EAGAIN path is being taken? Or could it be an exception is being thrown (and swallowed), leaving result = 0, thereby adding the socket to the poller at line 93 and returning zero? - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
