date:20060622

Re: NIO Connector, please review

2006-06-22 Thread Remy Maucherat


Filip Hanik - Dev Lists wrote:
Ok, I have a non SSL enabled Java NIO connector created and checked in. 
It works in the exact way as APR, meaning it blocks on read and write,
So its no true NIO, but close enough to handle comet style traffic, and 
to increase the connection count without increasing thread count.


I really see no usefulness in such a connector (even if it did work). 
The one and only benefit is that you get to use the JVM native vendor 
network proprietary code rather than the ASF open source code. Really 
cool :)


Rémy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 39821] - JK busy number is abnormal

2006-06-22 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=39821





--- Additional Comments From [EMAIL PROTECTED]  2006-06-22 08:45 ---
Rainer: Will do. Cheers for your fast responses and for nailing the bug!

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r416314 - in /tomcat/tc6.0.x/trunk: build.properties.default build.xml

2006-06-22 Thread remm

Author: remm
Date: Thu Jun 22 03:11:41 2006
New Revision: 416314

URL: http://svn.apache.org/viewvc?rev=416314&view=rev
Log:
- Add new files.

Modified:
tomcat/tc6.0.x/trunk/build.properties.default
tomcat/tc6.0.x/trunk/build.xml

Modified: tomcat/tc6.0.x/trunk/build.properties.default
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/build.properties.default?rev=416314&r1=416313&r2=416314&view=diff
==
--- tomcat/tc6.0.x/trunk/build.properties.default (original)
+++ tomcat/tc6.0.x/trunk/build.properties.default Thu Jun 22 03:11:41 2006
@@ -22,6 +22,7 @@
 compile.debug=true
 
 base-jakarta.loc=http://archive.apache.org/dist/jakarta
+base-tomcat.loc=http://archive.apache.org/dist/tomcat
 
 # - Commons Logging, version 1.0.1 or later -
 commons-logging.home=${base.path}/commons-logging-1.0.4

Modified: tomcat/tc6.0.x/trunk/build.xml
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/build.xml?rev=416314&r1=416313&r2=416314&view=diff
==
--- tomcat/tc6.0.x/trunk/build.xml (original)
+++ tomcat/tc6.0.x/trunk/build.xml Thu Jun 22 03:11:41 2006
@@ -110,6 +110,7 @@
   
 
 
+
 
 
 
@@ -163,6 +164,7 @@
 
 
 
+
 
 
 
@@ -255,7 +257,10 @@
 
 
 
-
+
+
+   
 
   
 
@@ -267,6 +272,10 @@
 
   
 
+
+
+
+
   
 
 
@@ -310,12 +319,24 @@
 
   
 
+  
+
+
+
+  
+
   
 
 
   
   
+
+
+
+  
+  
+  
 
 
 



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: svn commit: r416187 [1/3] - in /tomcat/tc6.0.x/trunk/java/org/apache: catalina/connector/ coyote/http11/ tomcat/util/net/

2006-06-22 Thread Remy Maucherat


[EMAIL PROTECTED] wrote:

-if ("HTTP/1.1".equals(protocol)) {
+if ("HTTP/1.1/NIO".equals(protocol)) {
+
setProtocolHandlerClassName("org.apache.coyote.http11.Http11NioProtocol");
+} else if ("HTTP/1.1".equals(protocol)) {


I think using the actual class name is far better than using arbitrary 
protocol names.


Rémy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 39862] New: - provide support for protocol-independent GenericServlet

2006-06-22 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=39862

   Summary: provide support for protocol-independent GenericServlet
   Product: Tomcat 5
   Version: 5.5.9
  Platform: Other
   URL: http://tomcat.apache.org/tomcat-5.5-
doc/servletapi/javax/servlet/GenericServlet.html
OS/Version: other
Status: NEW
  Severity: enhancement
  Priority: P2
 Component: Catalina
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


The API doc for javax.servlet.GenericServlet states: "Defines a generic,
protocol-independent servlet."

Currently Tomcat does not support protocol-independent servlets, because there
has to be a HTTP header line to route the message to a web applicaton and 
servlet.

To support protocol-independent servlets, there would have to be a mapping from
a dedicated port to the GenericServlet instance. For each active GenericServlet
Tomcat would have to create a ServerSocket, listen on it and route traffic to
the GenericServlet instance.

Protocol-independent GenericServlets would be useful for hosting Socket Server
applications within Tomcat, so the application developer wouldn't have to cope
with Sockets and threading issues. In the original spirit of Servlets Tomcat
would open up to a greater range of server based applications beside web
applications.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: NIO Connector, please review

2006-06-22 Thread Filip Hanik - Dev Lists


Remy Maucherat wrote:

Filip Hanik - Dev Lists wrote:
Ok, I have a non SSL enabled Java NIO connector created and checked 
in. It works in the exact way as APR, meaning it blocks on read and 
write,
So its no true NIO, but close enough to handle comet style traffic, 
and to increase the connection count without increasing thread count.


I really see no usefulness in such a connector (even if it did work). 
The one and only benefit is that you get to use the JVM native vendor 
network proprietary code rather than the ASF open source code. Really 
cool :)
you gotta look at the glass as half full, not half empty :), it also 
doesn't crash the VM when the client aborts the connection on a comet 
request ;)


Rémy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--


Filip Hanik

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: svn commit: r416193 [2/2] - /tomcat/tc6.0.x/trunk/java/org/apache/tomcat/util/net/NioEndpoint.java

2006-06-22 Thread Filip Hanik - Dev Lists

so you mean, that SVN changed the line endings when I checked in the 
code the first time, and that was the mismatch?

cause it was me checking in the file the first time and second.
Filip


William A. Rowe, Jr. wrote:

Filip Hanik - Dev Lists wrote:
wow, what just happened here, how could the entire file diff when I 
checked it in once


can someone shed some light on SVN for me here.


Line endings.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--


Filip Hanik

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: svn commit: r416187 [1/3] - in /tomcat/tc6.0.x/trunk/java/org/apache: catalina/connector/ coyote/http11/ tomcat/util/net/

2006-06-22 Thread Filip Hanik - Dev Lists

I agree, would you mind if I redid the connector, so that the 
protocolHandlerClassName works?
currently, it only checks the protocol, as it does so in the constructor 
of the Connector. so setting protocol or attributes later will have no 
effect


public void begin(Attributes attributes) throws Exception {
digester.push(new Connector(attributes.getValue("protocol")));
}

Filip




Remy Maucherat wrote:

[EMAIL PROTECTED] wrote:

-if ("HTTP/1.1".equals(protocol)) {
+if ("HTTP/1.1/NIO".equals(protocol)) {
+
setProtocolHandlerClassName("org.apache.coyote.http11.Http11NioProtocol"); 


+} else if ("HTTP/1.1".equals(protocol)) {


I think using the actual class name is far better than using arbitrary 
protocol names.


Rémy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--


Filip Hanik

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 39865] New: - Not able to open Openoffice files

2006-06-22 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=39865

   Summary: Not able to open Openoffice files
   Product: Tomcat 5
   Version: 5.5.0
  Platform: All
OS/Version: Windows Server 2003
Status: NEW
  Keywords: ErrorMessage
  Severity: major
  Priority: P1
 Component: Catalina
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


I am using tomcat 5.5. When I use to open the openoffice files (.odp, .odb, 
etc.,) files the files are not opening and just appearing a small ican in the 
top lesthand corner of the Internet Explorer browser.

Please help to fix this issue


Thanks

regards
kumar

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: NIO Connector, please review

2006-06-22 Thread Remy Maucherat


Filip Hanik - Dev Lists wrote:
you gotta look at the glass as half full, not half empty :), it also 
doesn't crash the VM when the client aborts the connection on a comet 
request ;)


I know of no crash problems. I think there's a very negative development 
atmosphere in the components you become involved with, I am not going to 
tolerate this for much longer. If you know of problems, and for example 
have debugged them, you should disclose them.


I quickly tested your NIO connector, and on Windows, it closes the 
connection after getting the first byte. I didn't have time to test further.


Rémy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: svn commit: r416187 [1/3] - in /tomcat/tc6.0.x/trunk/java/org/apache: catalina/connector/ coyote/http11/ tomcat/util/net/

2006-06-22 Thread Remy Maucherat


Filip Hanik - Dev Lists wrote:
I agree, would you mind if I redid the connector, so that the 
protocolHandlerClassName works?
currently, it only checks the protocol, as it does so in the constructor 
of the Connector. so setting protocol or attributes later will have no 
effect


public void begin(Attributes attributes) throws Exception {
digester.push(new Connector(attributes.getValue("protocol")));
}


The protocol attribute can accept the classname as its value.

Rémy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r416390 - in /tomcat/container/tc5.5.x/modules/groupcom: ./ src/share/org/apache/catalina/tribes/group/ src/share/org/apache/catalina/tribes/group/interceptors/ src/share/org/apache/catali

2006-06-22 Thread fhanik

Author: fhanik
Date: Thu Jun 22 08:08:58 2006
New Revision: 416390

URL: http://svn.apache.org/viewvc?rev=416390&view=rev
Log:
Support for JDK1.4 all the way

Added:

tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/io/BufferPool14Impl.java
Modified:
tomcat/container/tc5.5.x/modules/groupcom/VERSION

tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/group/GroupChannel.java

tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/group/interceptors/NonBlockingCoordinator.java

tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/io/BufferPool.java

Modified: tomcat/container/tc5.5.x/modules/groupcom/VERSION
URL: 
http://svn.apache.org/viewvc/tomcat/container/tc5.5.x/modules/groupcom/VERSION?rev=416390&r1=416389&r2=416390&view=diff
==
--- tomcat/container/tc5.5.x/modules/groupcom/VERSION (original)
+++ tomcat/container/tc5.5.x/modules/groupcom/VERSION Thu Jun 22 08:08:58 2006
@@ -1,3 +1,5 @@
+0.9.2.9
+  - jdk1.4 support for buffer pools
 0.9.2.8
   - finished coordinator and bug fixes in the coordinator and ChannelReceiver
 0.9.2.6

Modified: 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/group/GroupChannel.java
URL: 
http://svn.apache.org/viewvc/tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/group/GroupChannel.java?rev=416390&r1=416389&r2=416390&view=diff
==
--- 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/group/GroupChannel.java
 (original)
+++ 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/group/GroupChannel.java
 Thu Jun 22 08:08:58 2006
@@ -318,7 +318,8 @@
 try {
 clazz = 
Class.forName("org.apache.catalina.tribes.group.interceptors.MessageDispatch15Interceptor",
   
true,GroupChannel.class.getClassLoader());
-} catch ( Exception x ) {
+clazz.newInstance();
+} catch ( Throwable x ) {
 clazz = MessageDispatchInterceptor.class;
 }//catch
 try {

Modified: 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/group/interceptors/NonBlockingCoordinator.java
URL: 
http://svn.apache.org/viewvc/tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/group/interceptors/NonBlockingCoordinator.java?rev=416390&r1=416389&r2=416390&view=diff
==
--- 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/group/interceptors/NonBlockingCoordinator.java
 (original)
+++ 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/group/interceptors/NonBlockingCoordinator.java
 Thu Jun 22 08:08:58 2006
@@ -323,6 +323,7 @@
 Membership merged = mergeOnArrive(msg, sender);
 if (isViewConf(msg)) handleViewConf(msg, sender, merged);
 else handleToken(msg, sender, merged);
+ClassLoader loader;
 
 }
 
@@ -363,7 +364,7 @@
 protected void handleOtherToken(MemberImpl local, CoordinationMessage msg, 
Member sender,Membership merged) throws ChannelException {
 if ( local.equals(msg.getLeader()) ) {
 //I am the new leader
-startElection(false);
+//startElection(false);
 } else {
 msg.view = (MemberImpl[])merged.getMembers();
 sendElectionMsgToNextInline(local,msg);

Modified: 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/io/BufferPool.java
URL: 
http://svn.apache.org/viewvc/tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/io/BufferPool.java?rev=416390&r1=416389&r2=416390&view=diff
==
--- 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/io/BufferPool.java
 (original)
+++ 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/io/BufferPool.java
 Thu Jun 22 08:08:58 2006
@@ -58,16 +58,22 @@
 synchronized (BufferPool.class) {
 if ( instance == null ) {
BufferPoolAPI pool = null;
+   Class clazz = null;
try {
-   Class clazz = 
Class.forName("org.apache.catalina.tribes.io.BufferPool15Impl");
+   clazz = 
Class.forName("org.apache.catalina.tribes.io.BufferPool15Impl");
pool = (BufferPoolAPI)clazz.newInstance();
-   pool.setMaxSize(DEFAULT_POOL_SIZE);
-   log.info("Created a buffer pool with max 
size:"+DEFAULT_POOL_SIZE+" bytes.");
-

Re: NIO Connector, please review

2006-06-22 Thread Filip Hanik - Dev Lists


Remy Maucherat wrote:

Filip Hanik - Dev Lists wrote:
you gotta look at the glass as half full, not half empty :), it also 
doesn't crash the VM when the client aborts the connection on a comet 
request ;)


I know of no crash problems. I think there's a very negative 
development atmosphere in the components you become involved with, I 
am not going to tolerate this for much longer. If you know of 
problems, and for example have debugged them, you should disclose them.

I did, just check
http://marc.theaimsgroup.com/?l=tomcat-dev&m=115064982127403&w=2
In terms of negativity, not sure where your head is at, but there is 
none here.




I quickly tested your NIO connector, and on Windows, it closes the 
connection after getting the first byte. I didn't have time to test 
further.
Really, I ran through a large set of tests here and they all worked 
fine, both chunked encoding and content length based data.


Rémy

Filip


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--


Filip Hanik

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 39866] New: - Context manager name isn't reset correctly after reload, in a cluster.

2006-06-22 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=39866

   Summary: Context manager name isn't reset correctly after reload,
in a cluster.
   Product: Tomcat 5
   Version: 5.5.17
  Platform: Other
OS/Version: Linux
Status: NEW
  Severity: major
  Priority: P2
 Component: Catalina:Cluster
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


The context manager name refered to by the cluster doesn't appear to be reset
when the context reloads.  Other nodes in the cluster receive messages with an
incorrect manager name, after a distributable context is updated by adding or
updating a jar or the web.xml file.

The name appears to be appended to it's previous value after each reload.
Other members of the cluster log messages from the updated node as follows:

 SEVERE: Context manager doesn't exist:host1host1
 SEVERE: Context manager doesn't exist:host1host1host1

(In our case there was only a root context in each host.)

The Cluster definition is exactly as it is in the default server.xml, except
that it's placed at the Engine level, rather than inside a Host.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: NIO Connector, please review

2006-06-22 Thread Remy Maucherat


Filip Hanik - Dev Lists wrote:

I did, just check
http://marc.theaimsgroup.com/?l=tomcat-dev&m=115064982127403&w=2
In terms of negativity, not sure where your head is at, but there is 
none here.


This was quite a subtle mention. The plan is that the socket will not 
get destroyed and deallocated before the error method of the servlet is 
called. If this is indeed done properly, then it is the application's 
fault and the Java code should not change. At the same time, I would 
like to get more robustness and add code for that in the native code, 
because in a very similar way, it is currently possible to crash Tomcat 
with APR using Java2D, which writes stuff asynchronously when finalizing 
its objects.


I quickly tested your NIO connector, and on Windows, it closes the 
connection after getting the first byte. I didn't have time to test 
further.
Really, I ran through a large set of tests here and they all worked 
fine, both chunked encoding and content length based data.


I am not able to get any requests served at all right now (as I said, 
using a telnet, the connection gets closed without an error being logged 
after getting the first byte), while the other connectors work fine. The 
configuration is:




protocol="org.apache.coyote.http11.Http11NioProtocol" />


protocol="org.apache.coyote.http11.Http11Protocol" />


Rémy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r416408 - /tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/Connector.java

2006-06-22 Thread fhanik

Author: fhanik
Date: Thu Jun 22 09:03:32 2006
New Revision: 416408

URL: http://svn.apache.org/viewvc?rev=416408&view=rev
Log:
Reverted checkin, we can use a fully qualified class name inside of the protocol

Modified:
tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/Connector.java

Modified: tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/Connector.java
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/Connector.java?rev=416408&r1=416407&r2=416408&view=diff
==
--- tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/Connector.java 
(original)
+++ tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/Connector.java Thu 
Jun 22 09:03:32 2006
@@ -623,9 +623,7 @@
 }
 
 if (apr) {
-if ("HTTP/1.1/NIO".equals(protocol)) {
-
setProtocolHandlerClassName("org.apache.coyote.http11.Http11NioProtocol");
-} else if ("HTTP/1.1".equals(protocol)) {
+if ("HTTP/1.1".equals(protocol)) {
 setProtocolHandlerClassName
 ("org.apache.coyote.http11.Http11AprProtocol");
 } else if ("AJP/1.3".equals(protocol)) {
@@ -638,9 +636,7 @@
 ("org.apache.coyote.http11.Http11AprProtocol");
 }
 } else {
-if ("HTTP/1.1/NIO".equals(protocol)) {
-
setProtocolHandlerClassName("org.apache.coyote.http11.Http11NioProtocol");
-}else if ("HTTP/1.1".equals(protocol)) {
+if ("HTTP/1.1".equals(protocol)) {
 setProtocolHandlerClassName
 ("org.apache.coyote.http11.Http11Protocol");
 } else if ("AJP/1.3".equals(protocol)) {



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: NIO Connector, please review

2006-06-22 Thread Filip Hanik - Dev Lists


Remy Maucherat wrote:

Filip Hanik - Dev Lists wrote:

I did, just check
http://marc.theaimsgroup.com/?l=tomcat-dev&m=115064982127403&w=2
In terms of negativity, not sure where your head is at, but there is 
none here.


This was quite a subtle mention. The plan is that the socket will not 
get destroyed and deallocated before the error method of the servlet 
is called. If this is indeed done properly, then it is the 
application's fault and the Java code should not change. At the same 
time, I would like to get more robustness and add code for that in the 
native code, because in a very similar way, it is currently possible 
to crash Tomcat with APR using Java2D, which writes stuff 
asynchronously when finalizing its objects.

yes, and I offered to help track these down and will do so.


I quickly tested your NIO connector, and on Windows, it closes the 
connection after getting the first byte. I didn't have time to test 
further.
Really, I ran through a large set of tests here and they all worked 
fine, both chunked encoding and content length based data.


I am not able to get any requests served at all right now (as I said, 
using a telnet, the connection gets closed without an error being 
logged after getting the first byte), while the other connectors work 
fine. The configuration is:




protocol="org.apache.coyote.http11.Http11NioProtocol" />


protocol="org.apache.coyote.http11.Http11Protocol" />

ok, lemme get on that one


Rémy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--


Filip Hanik

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r416409 [1/2] - /tomcat/tc6.0.x/trunk/java/org/apache/tomcat/util/net/NioEndpoint.java

2006-06-22 Thread fhanik

Author: fhanik
Date: Thu Jun 22 09:10:17 2006
New Revision: 416409

URL: http://svn.apache.org/viewvc?rev=416409&view=rev
Log:
Reverted last nights checkin, until I fix the line ending story, and this also 
makes the connector work again

Modified:
tomcat/tc6.0.x/trunk/java/org/apache/tomcat/util/net/NioEndpoint.java


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: NIO Connector, please review

2006-06-22 Thread Filip Hanik - Dev Lists


Filip Hanik - Dev Lists wrote:

Remy Maucherat wrote:

Filip Hanik - Dev Lists wrote:

I did, just check
http://marc.theaimsgroup.com/?l=tomcat-dev&m=115064982127403&w=2
In terms of negativity, not sure where your head is at, but there is 
none here.


This was quite a subtle mention. The plan is that the socket will not 
get destroyed and deallocated before the error method of the servlet 
is called. If this is indeed done properly, then it is the 
application's fault and the Java code should not change. At the same 
time, I would like to get more robustness and add code for that in 
the native code, because in a very similar way, it is currently 
possible to crash Tomcat with APR using Java2D, which writes stuff 
asynchronously when finalizing its objects.

yes, and I offered to help track these down and will do so.


I quickly tested your NIO connector, and on Windows, it closes the 
connection after getting the first byte. I didn't have time to test 
further.
Really, I ran through a large set of tests here and they all worked 
fine, both chunked encoding and content length based data.


I am not able to get any requests served at all right now (as I said, 
using a telnet, the connection gets closed without an error being 
logged after getting the first byte), while the other connectors work 
fine. The configuration is:




protocol="org.apache.coyote.http11.Http11NioProtocol" />


protocol="org.apache.coyote.http11.Http11Protocol" />

ok, lemme get on that one
Alright, fixed, my last night checkin, the one I was unable to diff, 
caused the problem, I have reverted that one, and the Connector since we 
can use the fully qualified classname here.


Filip

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: NIO Connector, please review

2006-06-22 Thread Remy Maucherat


Filip Hanik - Dev Lists wrote:
Alright, fixed, my last night checkin, the one I was unable to diff, 
caused the problem, I have reverted that one, and the Connector since we 
can use the fully qualified classname here.


I am able to diff to see what got fixed, and it's trivial: all requests 
were processed as Comet events.


Rémy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: NIO Connector, please review

2006-06-22 Thread Filip Hanik - Dev Lists


Remy Maucherat wrote:

Filip Hanik - Dev Lists wrote:
Alright, fixed, my last night checkin, the one I was unable to diff, 
caused the problem, I have reverted that one, and the Connector since 
we can use the fully qualified classname here.


I am able to diff to see what got fixed, and it's trivial: all 
requests were processed as Comet events.
yup, noticed that when I ran it in a debugger, I wanted to consolidate 
the two processSocket method into one, i did it wrong.


Filip


--


Filip Hanik

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: NIO Connector, please review

2006-06-22 Thread Remy Maucherat


Filip Hanik - Dev Lists wrote:

Remy Maucherat wrote:

Filip Hanik - Dev Lists wrote:
Alright, fixed, my last night checkin, the one I was unable to diff, 
caused the problem, I have reverted that one, and the Connector since 
we can use the fully qualified classname here.


I am able to diff to see what got fixed, and it's trivial: all 
requests were processed as Comet events.
yup, noticed that when I ran it in a debugger, I wanted to consolidate 
the two processSocket method into one, i did it wrong.


I can confirm it now works. The two methods are fundamentally different, 
and one of them was actually named processSocketEvent until I changed it 
back to processSocket.


However, the throughput is very bad at the moment (/usr/sbin/ab.exe -n 
2 -c 10 -k http://127.0.0.1:8081/tomcat.gif):

800 req/s (with keepalive actually working) vs 6000+ for regular java.io.

Rémy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: NIO Connector, please review

2006-06-22 Thread Costin Manolache

On 6/22/06, Remy Maucherat <[EMAIL PROTECTED]> wrote:

Filip Hanik - Dev Lists wrote:
> Ok, I have a non SSL enabled Java NIO connector created and checked in.
> It works in the exact way as APR, meaning it blocks on read and write,
> So its no true NIO, but close enough to handle comet style traffic, and
> to increase the connection count without increasing thread count.

I really see no usefulness in such a connector (even if it did work).
The one and only benefit is that you get to use the JVM native vendor
network proprietary code rather than the ASF open source code. Really
cool :)

We also use JVM native code for java.lang, and in the old java.io connector
:-)

NIO code is open source as well - Classpath includes a decent
implementation.
The benefit is that nio, even if lower performance than APR, is part of the
jre and so it's slightly easier to use.
I think after the NIO connector is stable we should start deprecating the
old java.io connector.

Costin

Re: NIO Connector, please review

2006-06-22 Thread Jess Holle


Remy Maucherat wrote:

Filip Hanik - Dev Lists wrote:

Remy Maucherat wrote:

Filip Hanik - Dev Lists wrote:
Alright, fixed, my last night checkin, the one I was unable to 
diff, caused the problem, I have reverted that one, and the 
Connector since we can use the fully qualified classname here.


I am able to diff to see what got fixed, and it's trivial: all 
requests were processed as Comet events.
yup, noticed that when I ran it in a debugger, I wanted to 
consolidate the two processSocket method into one, i did it wrong.
I can confirm it now works. The two methods are fundamentally 
different, and one of them was actually named processSocketEvent until 
I changed it back to processSocket.


However, the throughput is very bad at the moment (/usr/sbin/ab.exe -n 
2 -c 10 -k http://127.0.0.1:8081/tomcat.gif):

800 req/s (with keepalive actually working) vs 6000+ for regular java.io.
That's unfortunate.  So regular is better?  What are they doing with 
Grizzly?


--
Jess Holle

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r416423 - /tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/InternalNioInputBuffer.java

2006-06-22 Thread fhanik

Author: fhanik
Date: Thu Jun 22 10:09:14 2006
New Revision: 416423

URL: http://svn.apache.org/viewvc?rev=416423&view=rev
Log:
must come up with a better sleep, this brings the nio connector up to the same 
speed as the io connector however, there is a risk for cpu contention on slow 
clients, fix will be coming

Modified:

tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/InternalNioInputBuffer.java

Modified: 
tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/InternalNioInputBuffer.java
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/InternalNioInputBuffer.java?rev=416423&r1=416422&r2=416423&view=diff
==
--- 
tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/InternalNioInputBuffer.java 
(original)
+++ 
tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/InternalNioInputBuffer.java 
Thu Jun 22 10:09:14 2006
@@ -551,7 +551,7 @@
 return false;
 }
 timedOut = (readTimeout != -1) && 
((System.currentTimeMillis()-start)>this.readTimeout);
-if ( !timedOut && nRead == 0 ) try {Thread.sleep(25);}catch ( 
Exception x ) {}
+//if ( !timedOut && nRead == 0 ) try {Thread.sleep(5);}catch ( 
Exception x ) {}
 }while ( nRead == 0 && (!timedOut) );
 //else throw new IOException(sm.getString("iib.failedread"));
 return false; //timeout



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: NIO Connector, please review

2006-06-22 Thread Filip Hanik - Dev Lists


Jess Holle wrote:

Remy Maucherat wrote:

Filip Hanik - Dev Lists wrote:

Remy Maucherat wrote:

Filip Hanik - Dev Lists wrote:
Alright, fixed, my last night checkin, the one I was unable to 
diff, caused the problem, I have reverted that one, and the 
Connector since we can use the fully qualified classname here.


I am able to diff to see what got fixed, and it's trivial: all 
requests were processed as Comet events.
yup, noticed that when I ran it in a debugger, I wanted to 
consolidate the two processSocket method into one, i did it wrong.
I can confirm it now works. The two methods are fundamentally 
different, and one of them was actually named processSocketEvent 
until I changed it back to processSocket.


However, the throughput is very bad at the moment (/usr/sbin/ab.exe 
-n 2 -c 10 -k http://127.0.0.1:8081/tomcat.gif):
800 req/s (with keepalive actually working) vs 6000+ for regular 
java.io.
That's unfortunate.  So regular is better?  What are they doing with 
Grizzly?

no, its me :)
I need to come up with a non cpu sucking wait algorithm for the wait.

once that is fixed, the performance should be close to identical

Filip



--
Jess Holle

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--


Filip Hanik

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: NIO Connector, please review

2006-06-22 Thread Remy Maucherat


Filip Hanik - Dev Lists wrote:
That's unfortunate.  So regular is better?  What are they doing with 
Grizzly?

no, its me :)
I need to come up with a non cpu sucking wait algorithm for the wait.

once that is fixed, the performance should be close to identical


For some reason, the performance went down further for me with that 
patch (although I noticed the CPU is being used properly this time, 
while before Tomcat was not using all the CPU available).


Rémy


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: NIO Connector, please review

2006-06-22 Thread Filip Hanik - Dev Lists


Remy Maucherat wrote:

Filip Hanik - Dev Lists wrote:
That's unfortunate.  So regular is better?  What are they doing with 
Grizzly?

no, its me :)
I need to come up with a non cpu sucking wait algorithm for the wait.

once that is fixed, the performance should be close to identical


For some reason, the performance went down further for me with that 
patch (although I noticed the CPU is being used properly this time, 
while before Tomcat was not using all the CPU available).
that's strange, mine went up to the same level as the java.io connector, 
I'm not completely done with it though.


Rémy


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--


Filip Hanik

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r416444 [1/2] - in /tomcat/tc6.0.x/trunk/java/org/apache: coyote/http11/Http11NioProcessor.java coyote/http11/InternalNioInputBuffer.java tomcat/util/net/NioEndpoint.java

2006-06-22 Thread fhanik

Author: fhanik
Date: Thu Jun 22 12:05:02 2006
New Revision: 416444

URL: http://svn.apache.org/viewvc?rev=416444&view=rev
Log:
Fix so that we don't do a busy read, instead we are properly doing a NIO poller 
wait
This way, we can achieve blocking read, without wasting CPU cycles.
Since we are using Java 5, I will be changing this implementation from using 
synchronized to using the Exchanger, this is also to avoid anyi locks that can 
happen. For example, in the current implementation the poller can call notify 
before we have had a chance to call wait

Modified:
tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/Http11NioProcessor.java

tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/InternalNioInputBuffer.java
tomcat/tc6.0.x/trunk/java/org/apache/tomcat/util/net/NioEndpoint.java

Modified: 
tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/Http11NioProcessor.java
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/Http11NioProcessor.java?rev=416444&r1=416443&r2=416444&view=diff
==
--- tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/Http11NioProcessor.java 
(original)
+++ tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/Http11NioProcessor.java 
Thu Jun 22 12:05:02 2006
@@ -90,8 +90,8 @@
 readTimeout = timeout;
 //readTimeout = -1;
 }
-inputBuffer = new InternalNioInputBuffer(request, headerBufferSize,
-readTimeout);
+inputBuffer = new InternalNioInputBuffer(request, 
headerBufferSize,readTimeout);
+inputBuffer.setPoller(endpoint.getPoller());
 request.setInputBuffer(inputBuffer);
 
 response = new Response();

Modified: 
tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/InternalNioInputBuffer.java
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/InternalNioInputBuffer.java?rev=416444&r1=416443&r2=416444&view=diff
==
--- 
tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/InternalNioInputBuffer.java 
(original)
+++ 
tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/InternalNioInputBuffer.java 
Thu Jun 22 12:05:02 2006
@@ -28,6 +28,10 @@
 import org.apache.tomcat.util.buf.MessageBytes;
 import org.apache.tomcat.util.http.MimeHeaders;
 import org.apache.tomcat.util.res.StringManager;
+import java.nio.channels.Selector;
+import java.nio.channels.SelectionKey;
+import org.apache.tomcat.util.net.NioEndpoint.KeyAttachment;
+import org.apache.tomcat.util.net.NioEndpoint.Poller;
 
 /**
  * Implementation of InputBuffer which provides HTTP request header parsing as
@@ -183,7 +187,7 @@
  * header.
  */
 protected long readTimeout;
-
+private Poller poller;
 
 // - Properties
 
@@ -203,6 +207,9 @@
 return socket;
 }
 
+public Poller getPoller() {
+return poller;
+}
 
 /**
  * Add an input filter to the filter library.
@@ -272,6 +279,9 @@
 this.swallowInput = swallowInput;
 }
 
+public void setPoller(Poller poller) {
+this.poller = poller;
+}
 
 // - Public Methods
 
@@ -551,7 +561,20 @@
 return false;
 }
 timedOut = (readTimeout != -1) && 
((System.currentTimeMillis()-start)>this.readTimeout);
-//if ( !timedOut && nRead == 0 ) try {Thread.sleep(5);}catch ( 
Exception x ) {}
+if ( !timedOut && nRead == 0 ) 
+try {
+final SelectionKey key = 
socket.keyFor(poller.getSelector());
+KeyAttachment att = (KeyAttachment)key.attachment();
+att.setWakeUp(true);
+
+poller.addEvent(
+new Runnable() {
+public void run() {
+if ( key != null ) 
key.interestOps(SelectionKey.OP_READ);
+}
+});
+synchronized (att.getMutex()) { att.getMutex().wait(25);}
+}catch ( Exception x ) {}
 }while ( nRead == 0 && (!timedOut) );
 //else throw new IOException(sm.getString("iib.failedread"));
 return false; //timeout



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: svn commit: r416444 [1/2] - in /tomcat/tc6.0.x/trunk/java/org/apache: coyote/http11/Http11NioProcessor.java coyote/http11/InternalNioInputBuffer.java tomcat/util/net/NioEndpoint.java

2006-06-22 Thread Remy Maucherat


[EMAIL PROTECTED] wrote:

Author: fhanik
Date: Thu Jun 22 12:05:02 2006
New Revision: 416444

URL: http://svn.apache.org/viewvc?rev=416444&view=rev
Log:
Fix so that we don't do a busy read, instead we are properly doing a NIO poller 
wait
This way, we can achieve blocking read, without wasting CPU cycles.
Since we are using Java 5, I will be changing this implementation from using 
synchronized to using the Exchanger, this is also to avoid anyi locks that can 
happen. For example, in the current implementation the poller can call notify 
before we have had a chance to call wait


This is a little bit better (2300 r/s now), but:
- I get some cancelled key exceptions (most likely they could be caught):
22 juin 2006 21:32:38 org.apache.tomcat.util.net.NioEndpoint$Poller events
GRAVE:
java.nio.channels.CancelledKeyException
at sun.nio.ch.SelectionKeyImpl.ensureValid(Unknown Source)
at sun.nio.ch.SelectionKeyImpl.interestOps(Unknown Source)
at 
org.apache.coyote.http11.InternalNioInputBuffer$1.run(InternalNioInputBuffer.java:573)
at 
org.apache.tomcat.util.net.NioEndpoint$Poller.events(NioEndpoint.java:1120)
at 
org.apache.tomcat.util.net.NioEndpoint$Poller.run(NioEndpoint.java:1176)

at java.lang.Thread.run(Unknown Source)
- I get a problem in the poller thread after a while:
Exception in thread "http-8081-Poller-0" java.lang.NullPointerException
at sun.nio.ch.WindowsSelectorImpl$FdMap.remove(Unknown Source)
at sun.nio.ch.WindowsSelectorImpl$FdMap.access$3000(Unknown Source)
at sun.nio.ch.WindowsSelectorImpl.implDereg(Unknown Source)
at sun.nio.ch.SelectorImpl.processDeregisterQueue(Unknown Source)
at sun.nio.ch.WindowsSelectorImpl.doSelect(Unknown Source)
at sun.nio.ch.SelectorImpl.lockAndDoSelect(Unknown Source)
at sun.nio.ch.SelectorImpl.select(Unknown Source)
at 
org.apache.tomcat.util.net.NioEndpoint$Poller.run(NioEndpoint.java:1182)

at java.lang.Thread.run(Unknown Source)

However, performance without keepalive (no -k) is down.

Rémy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r416456 - in /tomcat/tc6.0.x/trunk/java/org/apache: coyote/http11/InternalNioInputBuffer.java tomcat/util/net/NioEndpoint.java

2006-06-22 Thread fhanik

Author: fhanik
Date: Thu Jun 22 12:59:39 2006
New Revision: 416456

URL: http://svn.apache.org/viewvc?rev=416456&view=rev
Log:
Catch the cancelled key exceptions and act appropriately

Modified:

tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/InternalNioInputBuffer.java
tomcat/tc6.0.x/trunk/java/org/apache/tomcat/util/net/NioEndpoint.java

Modified: 
tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/InternalNioInputBuffer.java
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/InternalNioInputBuffer.java?rev=416456&r1=416455&r2=416456&view=diff
==
--- 
tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/InternalNioInputBuffer.java 
(original)
+++ 
tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/InternalNioInputBuffer.java 
Thu Jun 22 12:59:39 2006
@@ -32,6 +32,7 @@
 import java.nio.channels.SelectionKey;
 import org.apache.tomcat.util.net.NioEndpoint.KeyAttachment;
 import org.apache.tomcat.util.net.NioEndpoint.Poller;
+import java.nio.channels.CancelledKeyException;
 
 /**
  * Implementation of InputBuffer which provides HTTP request header parsing as
@@ -564,13 +565,21 @@
 if ( !timedOut && nRead == 0 ) 
 try {
 final SelectionKey key = 
socket.keyFor(poller.getSelector());
-KeyAttachment att = (KeyAttachment)key.attachment();
+final KeyAttachment att = (KeyAttachment)key.attachment();
 att.setWakeUp(true);
 
 poller.addEvent(
 new Runnable() {
 public void run() {
-if ( key != null ) 
key.interestOps(SelectionKey.OP_READ);
+try {
+if (key != null) 
key.interestOps(SelectionKey.OP_READ);
+} catch (CancelledKeyException ckx) {
+try {
+socket.socket().close();
+socket.close();
+att.setWakeUp(false);
+} catch (Exception ignore) {}
+}
 }
 });
 synchronized (att.getMutex()) { att.getMutex().wait(25);}

Modified: tomcat/tc6.0.x/trunk/java/org/apache/tomcat/util/net/NioEndpoint.java
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/tomcat/util/net/NioEndpoint.java?rev=416456&r1=416455&r2=416456&view=diff
==
--- tomcat/tc6.0.x/trunk/java/org/apache/tomcat/util/net/NioEndpoint.java 
(original)
+++ tomcat/tc6.0.x/trunk/java/org/apache/tomcat/util/net/NioEndpoint.java Thu 
Jun 22 12:59:39 2006
@@ -1106,7 +1106,14 @@
 if ( att != null ) att.setWakeUp(false);
 Runnable r = new Runnable() {
 public void run() {
-if ( key != null ) key.interestOps(SelectionKey.OP_READ);
+try {
+if (key != null) key.interestOps(SelectionKey.OP_READ);
+}catch ( CancelledKeyException ckx ) {
+try {
+socket.socket().close();
+socket.close();
+} catch ( Exception ignore ) {}
+}
 }
 };
 addEvent(r);



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: svn commit: r416444 [1/2] - in /tomcat/tc6.0.x/trunk/java/org/apache: coyote/http11/Http11NioProcessor.java coyote/http11/InternalNioInputBuffer.java tomcat/util/net/NioEndpoint.java

2006-06-22 Thread Filip Hanik - Dev Lists


Thanks for the help on this.
I am now catching those exceptions, I have the correct speed, but after 
the test is done, the poller is going ape-sh#@ and takes 100% of cpu, 
making future tests really slow.

I need to figure out why it isn't letting go of the connections

Filip

Remy Maucherat wrote:

[EMAIL PROTECTED] wrote:

Author: fhanik
Date: Thu Jun 22 12:05:02 2006
New Revision: 416444

URL: http://svn.apache.org/viewvc?rev=416444&view=rev
Log:
Fix so that we don't do a busy read, instead we are properly doing a 
NIO poller wait

This way, we can achieve blocking read, without wasting CPU cycles.
Since we are using Java 5, I will be changing this implementation 
from using synchronized to using the Exchanger, this is also to avoid 
anyi locks that can happen. For example, in the current 
implementation the poller can call notify before we have had a chance 
to call wait


This is a little bit better (2300 r/s now), but:
- I get some cancelled key exceptions (most likely they could be caught):
22 juin 2006 21:32:38 org.apache.tomcat.util.net.NioEndpoint$Poller 
events

GRAVE:
java.nio.channels.CancelledKeyException
at sun.nio.ch.SelectionKeyImpl.ensureValid(Unknown Source)
at sun.nio.ch.SelectionKeyImpl.interestOps(Unknown Source)
at 
org.apache.coyote.http11.InternalNioInputBuffer$1.run(InternalNioInputBuffer.java:573) 

at 
org.apache.tomcat.util.net.NioEndpoint$Poller.events(NioEndpoint.java:1120) 

at 
org.apache.tomcat.util.net.NioEndpoint$Poller.run(NioEndpoint.java:1176)

at java.lang.Thread.run(Unknown Source)
- I get a problem in the poller thread after a while:
Exception in thread "http-8081-Poller-0" java.lang.NullPointerException
at sun.nio.ch.WindowsSelectorImpl$FdMap.remove(Unknown Source)
at sun.nio.ch.WindowsSelectorImpl$FdMap.access$3000(Unknown 
Source)

at sun.nio.ch.WindowsSelectorImpl.implDereg(Unknown Source)
at sun.nio.ch.SelectorImpl.processDeregisterQueue(Unknown Source)
at sun.nio.ch.WindowsSelectorImpl.doSelect(Unknown Source)
at sun.nio.ch.SelectorImpl.lockAndDoSelect(Unknown Source)
at sun.nio.ch.SelectorImpl.select(Unknown Source)
at 
org.apache.tomcat.util.net.NioEndpoint$Poller.run(NioEndpoint.java:1182)

at java.lang.Thread.run(Unknown Source)

However, performance without keepalive (no -k) is down.

Rémy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--


Filip Hanik

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: svn commit: r416444 [1/2] - in /tomcat/tc6.0.x/trunk/java/org/apache: coyote/http11/Http11NioProcessor.java coyote/http11/InternalNioInputBuffer.java tomcat/util/net/NioEndpoint.java

2006-06-22 Thread Filip Hanik - Dev Lists

basically what is happening is that the connection is "keep-alive" so it 
goes back and register itself for more read,
read return -1, which is end of stream, and it re-register itself. I 
will make it throw an exception to end the loop


Filip


Filip Hanik - Dev Lists wrote:

Thanks for the help on this.
I am now catching those exceptions, I have the correct speed, but 
after the test is done, the poller is going ape-sh#@ and takes 100% of 
cpu, making future tests really slow.

I need to figure out why it isn't letting go of the connections

Filip

Remy Maucherat wrote:

[EMAIL PROTECTED] wrote:

Author: fhanik
Date: Thu Jun 22 12:05:02 2006
New Revision: 416444

URL: http://svn.apache.org/viewvc?rev=416444&view=rev
Log:
Fix so that we don't do a busy read, instead we are properly doing a 
NIO poller wait

This way, we can achieve blocking read, without wasting CPU cycles.
Since we are using Java 5, I will be changing this implementation 
from using synchronized to using the Exchanger, this is also to 
avoid anyi locks that can happen. For example, in the current 
implementation the poller can call notify before we have had a 
chance to call wait


This is a little bit better (2300 r/s now), but:
- I get some cancelled key exceptions (most likely they could be 
caught):
22 juin 2006 21:32:38 org.apache.tomcat.util.net.NioEndpoint$Poller 
events

GRAVE:
java.nio.channels.CancelledKeyException
at sun.nio.ch.SelectionKeyImpl.ensureValid(Unknown Source)
at sun.nio.ch.SelectionKeyImpl.interestOps(Unknown Source)
at 
org.apache.coyote.http11.InternalNioInputBuffer$1.run(InternalNioInputBuffer.java:573) 

at 
org.apache.tomcat.util.net.NioEndpoint$Poller.events(NioEndpoint.java:1120) 

at 
org.apache.tomcat.util.net.NioEndpoint$Poller.run(NioEndpoint.java:1176)

at java.lang.Thread.run(Unknown Source)
- I get a problem in the poller thread after a while:
Exception in thread "http-8081-Poller-0" java.lang.NullPointerException
at sun.nio.ch.WindowsSelectorImpl$FdMap.remove(Unknown Source)
at sun.nio.ch.WindowsSelectorImpl$FdMap.access$3000(Unknown 
Source)

at sun.nio.ch.WindowsSelectorImpl.implDereg(Unknown Source)
at sun.nio.ch.SelectorImpl.processDeregisterQueue(Unknown 
Source)

at sun.nio.ch.WindowsSelectorImpl.doSelect(Unknown Source)
at sun.nio.ch.SelectorImpl.lockAndDoSelect(Unknown Source)
at sun.nio.ch.SelectorImpl.select(Unknown Source)
at 
org.apache.tomcat.util.net.NioEndpoint$Poller.run(NioEndpoint.java:1182)

at java.lang.Thread.run(Unknown Source)

However, performance without keepalive (no -k) is down.

Rémy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]








--


Filip Hanik

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r416461 - in /tomcat/tc6.0.x/trunk/java/org/apache: coyote/http11/InternalNioInputBuffer.java tomcat/util/net/NioEndpoint.java

2006-06-22 Thread fhanik

Author: fhanik
Date: Thu Jun 22 13:28:27 2006
New Revision: 416461

URL: http://svn.apache.org/viewvc?rev=416461&view=rev
Log:
Two fixes,
process timeouts last, no need to check a timeout on a valid read. hence we do 
it after we process the actual operations
Throw an IO exception if we reach end of stream so that the sockets can get 
properly closed down
Speed is the same for nio and io right now, nio seems just a tad faster without 
keep alives

Modified:

tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/InternalNioInputBuffer.java
tomcat/tc6.0.x/trunk/java/org/apache/tomcat/util/net/NioEndpoint.java

Modified: 
tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/InternalNioInputBuffer.java
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/InternalNioInputBuffer.java?rev=416461&r1=416460&r2=416461&view=diff
==
--- 
tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/InternalNioInputBuffer.java 
(original)
+++ 
tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/InternalNioInputBuffer.java 
Thu Jun 22 13:28:27 2006
@@ -559,7 +559,8 @@
 lastValid = pos + nRead;
 return true;
 } else if (nRead == -1) {
-return false;
+//return false;
+throw new IOException("end of stream reached.");
 }
 timedOut = (readTimeout != -1) && 
((System.currentTimeMillis()-start)>this.readTimeout);
 if ( !timedOut && nRead == 0 ) 

Modified: tomcat/tc6.0.x/trunk/java/org/apache/tomcat/util/net/NioEndpoint.java
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/tomcat/util/net/NioEndpoint.java?rev=416461&r1=416460&r2=416461&view=diff
==
--- tomcat/tc6.0.x/trunk/java/org/apache/tomcat/util/net/NioEndpoint.java 
(original)
+++ tomcat/tc6.0.x/trunk/java/org/apache/tomcat/util/net/NioEndpoint.java Thu 
Jun 22 13:28:27 2006
@@ -1191,32 +1191,15 @@
 log.error("",x);
 continue;
 }
-//timeout
-Set keys = selector.keys();
-long now = System.currentTimeMillis();
-for (Iterator iter = keys.iterator(); iter.hasNext(); ) {
-SelectionKey key = (SelectionKey) iter.next();
-try {
-if (key.interestOps() == SelectionKey.OP_READ) {
-//only timeout sockets that we are waiting for a 
read from
-KeyAttachment ka = (KeyAttachment) 
key.attachment();
-long delta = now - ka.getLastAccess();
-if (delta > (long) soTimeout) {
-cancelledKey(key);
-}
-}
-}catch ( CancelledKeyException ckx ) {
-cancelledKey(key);
-}
-}
+
 
 
-if (keyCount == 0) continue;
+//if (keyCount == 0) continue;
 
-Iterator iterator = selector.selectedKeys().iterator();
+Iterator iterator = keyCount > 0 ? 
selector.selectedKeys().iterator() : null;
 // Walk through the collection of ready keys and dispatch
 // any active event.
-while (iterator.hasNext()) {
+while (iterator != null && iterator.hasNext()) {
 SelectionKey sk = (SelectionKey) iterator.next();
 iterator.remove();
 KeyAttachment attachment = (KeyAttachment)sk.attachment();
@@ -1255,7 +1238,25 @@
 }
 }//while
 
-
+//timeout
+Set keys = selector.keys();
+long now = System.currentTimeMillis();
+for (Iterator iter = keys.iterator(); iter.hasNext(); ) {
+SelectionKey key = (SelectionKey) iter.next();
+try {
+if (key.interestOps() == SelectionKey.OP_READ) {
+//only timeout sockets that we are waiting for a 
read from
+KeyAttachment ka = (KeyAttachment) 
key.attachment();
+long delta = now - ka.getLastAccess();
+if (delta > (long) soTimeout) {
+cancelledKey(key);
+}
+}
+}catch ( CancelledKeyException ckx ) {
+cancelledKey(key);
+}
+}
+
 }
 synchronized (this) {
 this.notifyAll();



-

svn commit: r416481 - /tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/InternalNioInputBuffer.java

2006-06-22 Thread fhanik

Author: fhanik
Date: Thu Jun 22 15:02:23 2006
New Revision: 416481

URL: http://svn.apache.org/viewvc?rev=416481&view=rev
Log:
Dont do the not needed operations, if they are not needed.
Performance is just a tad under java.io, which is expected as we need to poll, 
as opposed to constantly wait for data.

Modified:

tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/InternalNioInputBuffer.java

Modified: 
tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/InternalNioInputBuffer.java
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/InternalNioInputBuffer.java?rev=416481&r1=416480&r2=416481&view=diff
==
--- 
tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/InternalNioInputBuffer.java 
(original)
+++ 
tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/InternalNioInputBuffer.java 
Thu Jun 22 15:02:23 2006
@@ -567,10 +567,14 @@
 try {
 final SelectionKey key = 
socket.keyFor(poller.getSelector());
 final KeyAttachment att = (KeyAttachment)key.attachment();
-att.setWakeUp(true);
-
-poller.addEvent(
-new Runnable() {
+//to do, add in a check, we might have just timed out on 
the wait,
+//so there is no need to register us again.
+boolean addToQueue = false;
+try { addToQueue = 
((key.interestOps()&SelectionKey.OP_READ) != SelectionKey.OP_READ); } catch ( 
CancelledKeyException ignore ){}
+if ( addToQueue ) {
+att.setWakeUp(true);
+poller.addEvent(
+new Runnable() {
 public void run() {
 try {
 if (key != null) 
key.interestOps(SelectionKey.OP_READ);
@@ -582,12 +586,16 @@
 } catch (Exception ignore) {}
 }
 }
-});
-synchronized (att.getMutex()) { att.getMutex().wait(25);}
+});
+}//end if
+synchronized (att.getMutex()) {
+if ( att.getWakeUp() ) att.getMutex().wait(25);
+}
 }catch ( Exception x ) {}
 }while ( nRead == 0 && (!timedOut) );
 //else throw new IOException(sm.getString("iib.failedread"));
-return false; //timeout
+//return false; //timeout
+throw new IOException("read timed out.");
 }
 
 



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

NIO vs BIO speed

2006-06-22 Thread Filip Hanik - Dev Lists


I've attached two test runs NIO vs BIO.
The results are very similar, in a regular scenario, blocking IO should 
be a little bit faster, cause it doesn't have to poll, and then hand off 
to a separate thread before reading.
Benefit of the NIO is of course that the number of open sockets are no 
longer limited by thread count.


Remy, can you run your tests again, are you still seeing a huge difference?
thanks
Filip


Remy Maucherat wrote:

Filip Hanik - Dev Lists wrote:
That's unfortunate.  So regular is better?  What are they doing with 
Grizzly?

no, its me :)
I need to come up with a non cpu sucking wait algorithm for the wait.

once that is fixed, the performance should be close to identical


For some reason, the performance went down further for me with that 
patch (although I noticed the CPU is being used properly this time, 
while before Tomcat was not using all the CPU available).


Rémy


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--


Filip Hanik
This is ApacheBench, Version 2.0.41-dev <$Revision: 1.2 $> apache-2.0
Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright (c) 1998-2002 The Apache Software Foundation, http://www.apache.org/

Benchmarking 192.168.3.105 (be patient)


Server Software:Apache-Coyote/1.1
Server Hostname:192.168.3.105
Server Port:8081

Document Path:  /tomcat.gif
Document Length:1934 bytes

Concurrency Level:  10
Time taken for tests:   2.187500 seconds
Complete requests:  2
Failed requests:0
Write errors:   0
Keep-Alive requests:19806
Total transferred:  43279030 bytes
HTML transferred:   3868 bytes
Requests per second:9142.86 [#/sec] (mean)
Time per request:   1.094 [ms] (mean)
Time per request:   0.109 [ms] (mean, across all concurrent requests)
Transfer rate:  19320.69 [Kbytes/sec] received

Connection Times (ms)
  min  mean[+/-sd] median   max
Connect:00   0.0  0   0
Processing: 01   3.8  0  31
Waiting:01   3.8  0  31
Total:  01   3.8  0  31

Percentage of the requests served within a certain time (ms)
  50%  0
  66%  0
  75%  0
  80%  0
  90%  0
  95% 15
  98% 15
  99% 15
 100% 31 (longest request)
This is ApacheBench, Version 2.0.41-dev <$Revision: 1.2 $> apache-2.0
Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright (c) 1998-2002 The Apache Software Foundation, http://www.apache.org/

Benchmarking 192.168.3.105 (be patient)


Server Software:Apache-Coyote/1.1
Server Hostname:192.168.3.105
Server Port:8080

Document Path:  /tomcat.gif
Document Length:1934 bytes

Concurrency Level:  10
Time taken for tests:   2.62500 seconds
Complete requests:  2
Failed requests:0
Write errors:   0
Keep-Alive requests:19802
Total transferred:  43279240 bytes
HTML transferred:   3868 bytes
Requests per second:9696.97 [#/sec] (mean)
Time per request:   1.031 [ms] (mean)
Time per request:   0.103 [ms] (mean, across all concurrent requests)
Transfer rate:  20491.64 [Kbytes/sec] received

Connection Times (ms)
  min  mean[+/-sd] median   max
Connect:00   0.0  0   0
Processing: 00   5.8  0  93
Waiting:00   5.6  0  93
Total:  00   5.8  0  93

Percentage of the requests served within a certain time (ms)
  50%  0
  66%  0
  75%  0
  80%  0
  90%  0
  95%  0
  98% 15
  99% 15
 100% 93 (longest request)

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: NIO vs BIO speed

2006-06-22 Thread Filip Hanik - Dev Lists

Here is another test that I ran from a remote machine, setting 
maxThreads="25" and ab concurrency to 50 and keepalive on.
In this case, NIO is a lot faster. Turn off keepalive on ab, and we get 
similar results to previous run, where BIO is a tad faster.


[EMAIL PROTECTED] bin]$ ./ab -n 2 -k -c 50 
http://192.168.3.105:8080/tomcat.gif (BIO)

This is ApacheBench, Version 2.0.41-dev <$Revision: 1.121.2.12 $> apache-2.0
Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright (c) 1998-2002 The Apache Software Foundation, 
http://www.apache.org/


Benchmarking 192.168.3.105 (be patient)
Completed 2000 requests
Completed 4000 requests
Completed 6000 requests
Completed 8000 requests
Completed 1 requests
Completed 12000 requests
Completed 14000 requests
Completed 16000 requests
Completed 18000 requests
Finished 2 requests


Server Software:Apache-Coyote/1.1
Server Hostname:192.168.3.105
Server Port:8080

Document Path:  /tomcat.gif
Document Length:1934 bytes

Concurrency Level:  50
Time taken for tests:   7.41056 seconds
Complete requests:  2
Failed requests:0
Write errors:   0
Keep-Alive requests:10028
Total transferred:  43239331 bytes
HTML transferred:   38687126 bytes
Requests per second:2840.48 [#/sec] (mean)
Time per request:   17.603 [ms] (mean)
Time per request:   0.352 [ms] (mean, across all concurrent requests)
Transfer rate:  5996.97 [Kbytes/sec] received

Connection Times (ms)
 min  mean[+/-sd] median   max
Connect:05  22.1  03009
Processing: 0   11   5.8 11 273
Waiting:0   10   5.4 11 226
Total:  0   16  22.9 163027

Percentage of the requests served within a certain time (ms)
 50% 16
 66% 21
 75% 23
 80% 24
 90% 26
 95% 28
 98% 30
 99% 32
100%   3027 (longest request)
[EMAIL PROTECTED] bin]$ ./ab -n 2 -k -c 50 
http://192.168.3.105:8081/tomcat.gif

This is ApacheBench, Version 2.0.41-dev <$Revision: 1.121.2.12 $> apache-2.0
Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright (c) 1998-2002 The Apache Software Foundation, 
http://www.apache.org/


Benchmarking 192.168.3.105 (be patient)
Completed 2000 requests
Completed 4000 requests
Completed 6000 requests
Completed 8000 requests
Completed 1 requests
Completed 12000 requests
Completed 14000 requests
Completed 16000 requests
Completed 18000 requests
Finished 2 requests


Server Software:Apache-Coyote/1.1
Server Hostname:192.168.3.105
Server Port:8081

Document Path:  /tomcat.gif
Document Length:1934 bytes

Concurrency Level:  50
Time taken for tests:   5.526996 seconds
Complete requests:  2
Failed requests:0
Write errors:   0
Keep-Alive requests:2
Total transferred:  43281248 bytes
HTML transferred:   38681018 bytes
Requests per second:3618.60 [#/sec] (mean)
Time per request:   13.817 [ms] (mean)
Time per request:   0.276 [ms] (mean, across all concurrent requests)
Transfer rate:  7647.19 [Kbytes/sec] received

Connection Times (ms)
 min  mean[+/-sd] median   max
Connect:00   0.1  0   3
Processing: 1   13   3.7 13 220
Waiting:1   13   3.7 13 220
Total:  1   13   3.8 13 220

Percentage of the requests served within a certain time (ms)
 50% 13
 66% 14
 75% 15
 80% 16
 90% 17
 95% 19
 98% 21
 99% 22
100%220 (longest request)
[EMAIL PROTECTED] bin]$


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: NIO vs BIO speed

2006-06-22 Thread Remy Maucherat


Filip Hanik - Dev Lists wrote:

Remy, can you run your tests again, are you still seeing a huge difference?


Obviously, you did not change anything.

Rémy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: NIO vs BIO speed

2006-06-22 Thread Remy Maucherat


Filip Hanik - Dev Lists wrote:
Here is another test that I ran from a remote machine, setting 
maxThreads="25" and ab concurrency to 50 and keepalive on.
In this case, NIO is a lot faster. Turn off keepalive on ab, and we get 
similar results to previous run, where BIO is a tad faster.


Scaling the thread per connection model is done by increasing the amount 
of threads. This particular test demonstrates the obvious.


If I understand the results correctly, the results would be acceptable 
on Unix.


Rémy


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: NIO vs BIO speed

2006-06-22 Thread Filip Hanik - Dev Lists





Remy Maucherat wrote:
Filip Hanik
- Dev Lists wrote:
  
  Remy, can you run your tests again, are you
still seeing a huge difference?

  
  
Obviously, you did not change anything.
  

yes, I changed from busy read to polling, I wasn't sure if you ran your
tests after that.
I've ran my tests both on Windows and on Fedora Core 4, same results on
both machines.
if the concurrency is lower than maxThreads, bio has between a 1-10%
gain.
But as soon as the concurrency goes higher than maxThreads the nio
connector is way faster, in my case 66% faster.
In the concurrency>maxThreads, my NIO connector is slightly faster
than the APR connector as well.

Filip


Rémy
  
  
-
  
To unsubscribe, e-mail: [EMAIL PROTECTED]
  
For additional commands, e-mail: [EMAIL PROTECTED]
  
  
  



-- 


Filip Hanik

Re: NIO vs BIO speed

2006-06-22 Thread Filip Hanik - Dev Lists





Remy Maucherat wrote:
Filip
Hanik - Dev Lists wrote:
  
  Here is another test that I ran from a remote
machine, setting maxThreads="25" and ab concurrency to 50 and keepalive
on.

In this case, NIO is a lot faster. Turn off keepalive on ab, and we get
similar results to previous run, where BIO is a tad faster.

  
  
Scaling the thread per connection model is done by increasing the
amount of threads. This particular test demonstrates the obvious.
  

yes, what is interesting though, is my NIO connector is not really true
NIO, as it ties up a thread while polling for data. The true
implementation would have not invoked that thread yet, but for that I
would have had to rewritten the connector from scratch as I couldn't
have taken advantage of code already written and tested.
The reason it was done like this, is cause that way I could use almost
all the code from the APR connector.
So you could call it a semi-"thread-per-connection" model, yet handles
better than the true thread per connection model.
APR does the same thing.


If I understand the results correctly, the results would be acceptable
on Unix.
  

yes, I think they are looking pretty good. And I am fairly confident in
this new code, as most of it, is old tested APR code.

Filip

-- 


Filip Hanik

UNSUBSCRIBE PLEASE..............................

2006-06-22 Thread hamood rehman

From: Filip Hanik - Dev Lists <[EMAIL PROTECTED]>
Reply-To: "Tomcat Developers List" 
To: Tomcat Developers List 
Subject: Re: NIO Connector, please review
Date: Thu, 22 Jun 2006 11:25:59 -0500

Remy Maucherat wrote:

Filip Hanik - Dev Lists wrote:
Alright, fixed, my last night checkin, the one I was unable to diff, 
caused the problem, I have reverted that one, and the Connector since we 
can use the fully qualified classname here.

I am able to diff to see what got fixed, and it's trivial: all requests 
were processed as Comet events.
yup, noticed that when I ran it in a debugger, I wanted to consolidate the 
two processSocket method into one, i did it wrong.

Filip

--

Filip Hanik

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[EMAIL PROTECTED]: Project tomcat-tc6 (in module tomcat-tc6) failed

2006-06-22 Thread Bill Barker

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project tomcat-tc6 has an issue affecting its community integration.
This issue affects 1 projects.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- tomcat-tc6 :  Java Servlet 2.5 & Server Pages JSP 2.1 implementation (for 
...


Full details are available at:
http://vmgump.apache.org/gump/public/tomcat-tc6/tomcat-tc6/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -INFO- Failed with reason build failed
 -DEBUG- Extracted fallback artifacts from Gump Repository



The following work was performed:
http://vmgump.apache.org/gump/public/tomcat-tc6/tomcat-tc6/gump_work/build_tomcat-tc6_tomcat-tc6.html
Work Name: build_tomcat-tc6_tomcat-tc6 (Type: Build)
Work ended in a state of : Failed
Elapsed: 27 secs
Command Line: java -Djava.awt.headless=true org.apache.tools.ant.Main 
-Dgump.merge=/x1/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only 
-Dcommons-logging-api.jar=/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-22062006.jar
 
-Dtomcat-dbcp.jar=/usr/local/gump/public/workspace/tomcat-tc6/tomcat-deps/tomcat-jdbc-22062006.jar
 
-Djasper-jdt.jar=/usr/local/gump/packages/eclipse-3.1M6/plugins/org.eclipse.jdt.core_3.1.0/jdtcore.jar
 
[Working Directory: /usr/local/gump/public/workspace/tomcat-tc6]
CLASSPATH: 
/opt/jdk1.5/lib/tools.jar:/usr/local/gump/public/workspace/tomcat-tc6/classes:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/packages/junit3.8.1/junit.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/packages/javamail-1.4/mail.jar:/usr/local/gump/packages/javamail-1.4/lib/mailapi.jar:/usr/local/gump/packages/jaf-1.1ea/activation.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-22062006.jar:/usr/local/gump/packages/eclipse-3.1M6/plugins/org.eclipse.jdt.core_3.1.0/jdtcore.jar:/usr/local/gump/public/workspace/tomcat-tc6/tomcat-deps/tomcat-jdbc-22062006.jar
-
[javac] 
 ^
[javac] 
/x1/gump/public/workspace/tomcat-tc6/java/org/apache/catalina/mbeans/DefaultContextMBean.java:40:
 warning: unmappable character for encoding ASCII
[javac]  * @version $Revision: 303133 $ $Date: 2004-08-29 18:46:15 +0200 
(dim., 29 ao??t 2004) $
[javac] 
 ^
[javac] 
/x1/gump/public/workspace/tomcat-tc6/java/org/apache/catalina/mbeans/DefaultContextMBean.java:40:
 warning: unmappable character for encoding ASCII
[javac]  * @version $Revision: 303133 $ $Date: 2004-08-29 18:46:15 +0200 
(dim., 29 ao??t 2004) $
[javac] 
  ^
[javac] 
/x1/gump/public/workspace/tomcat-tc6/java/org/apache/catalina/mbeans/MBeanUtils.java:62:
 warning: unmappable character for encoding ASCII
[javac]  * @version $Revision: 303558 $ $Date: 2004-12-01 12:17:34 +0100 
(mer., 01 d??c. 2004) $
[javac] 
^
[javac] 
/x1/gump/public/workspace/tomcat-tc6/java/org/apache/catalina/mbeans/MBeanUtils.java:62:
 warning: unmappable character for encoding ASCII
[javac]  * @version $Revision: 303558 $ $Date: 2004-12-01 12:17:34 +0100 
(mer., 01 d??c. 2004) $
[javac] 
 ^
[javac] 
/x1/gump/public/workspace/tomcat-tc6/java/org/apache/catalina/mbeans/NamingResourcesMBean.java:39:
 warning: unmappable character for encoding ASCII
[javac]  * @version $Revision: 303133 $ $Date: 2004-08-29 18:46:15 +0200 
(dim., 29 ao??t 2004) $
[javac] 
 ^
[javac] 
/x1/gump/public/workspace/tomcat-tc6/java/org/apache/catalina/mbeans/NamingResourcesMBean.java:39:
 warning: unmappable character for encoding ASCII
[javac]  * @version $Revision: 303133 $ $Date: 2004-08-29 18:46:15 +0200 
(dim., 29 ao??t 2004) $
[jav

[EMAIL PROTECTED]: Project tomcat-tc6 (in module tomcat-tc6) failed

2006-06-22 Thread Bill Barker

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project tomcat-tc6 has an issue affecting its community integration.
This issue affects 1 projects.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- tomcat-tc6 :  Java Servlet 2.5 & Server Pages JSP 2.1 implementation (for 
...


Full details are available at:
http://vmgump.apache.org/gump/public/tomcat-tc6/tomcat-tc6/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -INFO- Failed with reason build failed
 -DEBUG- Extracted fallback artifacts from Gump Repository



The following work was performed:
http://vmgump.apache.org/gump/public/tomcat-tc6/tomcat-tc6/gump_work/build_tomcat-tc6_tomcat-tc6.html
Work Name: build_tomcat-tc6_tomcat-tc6 (Type: Build)
Work ended in a state of : Failed
Elapsed: 27 secs
Command Line: java -Djava.awt.headless=true org.apache.tools.ant.Main 
-Dgump.merge=/x1/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only 
-Dcommons-logging-api.jar=/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-22062006.jar
 
-Dtomcat-dbcp.jar=/usr/local/gump/public/workspace/tomcat-tc6/tomcat-deps/tomcat-jdbc-22062006.jar
 
-Djasper-jdt.jar=/usr/local/gump/packages/eclipse-3.1M6/plugins/org.eclipse.jdt.core_3.1.0/jdtcore.jar
 
[Working Directory: /usr/local/gump/public/workspace/tomcat-tc6]
CLASSPATH: 
/opt/jdk1.5/lib/tools.jar:/usr/local/gump/public/workspace/tomcat-tc6/classes:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/packages/junit3.8.1/junit.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/packages/javamail-1.4/mail.jar:/usr/local/gump/packages/javamail-1.4/lib/mailapi.jar:/usr/local/gump/packages/jaf-1.1ea/activation.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/target/commons-logging-api-22062006.jar:/usr/local/gump/packages/eclipse-3.1M6/plugins/org.eclipse.jdt.core_3.1.0/jdtcore.jar:/usr/local/gump/public/workspace/tomcat-tc6/tomcat-deps/tomcat-jdbc-22062006.jar
-
[javac] 
 ^
[javac] 
/x1/gump/public/workspace/tomcat-tc6/java/org/apache/catalina/mbeans/DefaultContextMBean.java:40:
 warning: unmappable character for encoding ASCII
[javac]  * @version $Revision: 303133 $ $Date: 2004-08-29 18:46:15 +0200 
(dim., 29 ao??t 2004) $
[javac] 
 ^
[javac] 
/x1/gump/public/workspace/tomcat-tc6/java/org/apache/catalina/mbeans/DefaultContextMBean.java:40:
 warning: unmappable character for encoding ASCII
[javac]  * @version $Revision: 303133 $ $Date: 2004-08-29 18:46:15 +0200 
(dim., 29 ao??t 2004) $
[javac] 
  ^
[javac] 
/x1/gump/public/workspace/tomcat-tc6/java/org/apache/catalina/mbeans/MBeanUtils.java:62:
 warning: unmappable character for encoding ASCII
[javac]  * @version $Revision: 303558 $ $Date: 2004-12-01 12:17:34 +0100 
(mer., 01 d??c. 2004) $
[javac] 
^
[javac] 
/x1/gump/public/workspace/tomcat-tc6/java/org/apache/catalina/mbeans/MBeanUtils.java:62:
 warning: unmappable character for encoding ASCII
[javac]  * @version $Revision: 303558 $ $Date: 2004-12-01 12:17:34 +0100 
(mer., 01 d??c. 2004) $
[javac] 
 ^
[javac] 
/x1/gump/public/workspace/tomcat-tc6/java/org/apache/catalina/mbeans/NamingResourcesMBean.java:39:
 warning: unmappable character for encoding ASCII
[javac]  * @version $Revision: 303133 $ $Date: 2004-08-29 18:46:15 +0200 
(dim., 29 ao??t 2004) $
[javac] 
 ^
[javac] 
/x1/gump/public/workspace/tomcat-tc6/java/org/apache/catalina/mbeans/NamingResourcesMBean.java:39:
 warning: unmappable character for encoding ASCII
[javac]  * @version $Revision: 303133 $ $Date: 2004-08-29 18:46:15 +0200 
(dim., 29 ao??t 2004) $
[jav

DO NOT REPLY [Bug 39873] New: - unable to access the jar files

2006-06-22 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=39873

   Summary: unable to access the jar files
   Product: Tomcat 3
   Version: Unknown
  Platform: Other
OS/Version: Windows 2000
Status: NEW
  Severity: normal
  Priority: P1
 Component: Webapps
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]


I am unable to access the jar files even wen the server is switched off

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

New Feature List

2006-06-22 Thread Riyaz Mansoor



i'll keep it brief.

i'm looking to spend time on working on the new features coming to 
tomcat 5.5 or 6


on the website, i could find no info on this. i was hoping there would 
be a page listing the features being worked in 5.5 and the coming 
features in 6


riyaz

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: svn commit: r415549 - /tomcat/connectors/trunk/jni/native/src/network.c

2006-06-22 Thread prakash shanmugam


hello mturk
 i want to know how to store a *.doc file ,or *.pdf file in MYSQL
database using JSP or SERVLET as a front end
if you know the asnwer please reply me soon its very important.
bye



On 6/20/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:


Author: mturk
Date: Tue Jun 20 00:56:27 2006
New Revision: 415549

URL: http://svn.apache.org/viewvc?rev=415549&view=rev
Log:
Ups. Deleted the crucial Revision tag :)

Modified:
   tomcat/connectors/trunk/jni/native/src/network.c

Modified: tomcat/connectors/trunk/jni/native/src/network.c
URL:
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jni/native/src/network.c?rev=415549&r1=415548&r2=415549&view=diff

==
--- tomcat/connectors/trunk/jni/native/src/network.c (original)
+++ tomcat/connectors/trunk/jni/native/src/network.c Tue Jun 20 00:56:27
2006
@@ -16,7 +16,7 @@
/*
*
* @author Mladen Turk
- * @version
+ * @version $Revision$, $Date$
*/

#include "tcn.h"



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: NIO vs BIO speed

2006-06-22 Thread Dakota Jack

I am interested in this code.  Is there a way I can see the code?  Thanks.

On 6/22/06, Filip Hanik - Dev Lists <[EMAIL PROTECTED]> wrote:



  


Remy Maucherat wrote:
Filip
Hanik - Dev Lists wrote:
  
  Here is another test that I ran from a remote
machine, setting maxThreads="25" and ab concurrency to 50 and keepalive
on.

In this case, NIO is a lot faster. Turn off keepalive on ab, and we get
similar results to previous run, where BIO is a tad faster.

  
  
Scaling the thread per connection model is done by increasing the
amount of threads. This particular test demonstrates the obvious.
  

yes, what is interesting though, is my NIO connector is not really true
NIO, as it ties up a thread while polling for data. The true
implementation would have not invoked that thread yet, but for that I
would have had to rewritten the connector from scratch as I couldn't
have taken advantage of code already written and tested.
The reason it was done like this, is cause that way I could use almost
all the code from the APR connector.
So you could call it a semi-"thread-per-connection" model, yet handles
better than the true thread per connection model.
APR does the same thing.


If I understand the results correctly, the results would be acceptable
on Unix.
  

yes, I think they are looking pretty good. And I am fairly confident in
this new code, as most of it, is old tested APR code.

Filip

-- 


Filip Hanik





-- "You can lead a horse to water but you cannot make it float on its back."~Dakota Jack~

Re: New Feature List

2006-06-22 Thread prakash shanmugam


hai if you can help me it will be a big relief for me
now iam using tomcat 5.0 and linux as my server machine and the client
machine are windows xp
in my coding iam using JSP and SERVLETS. the problem is i want to store
images and pdf files into mydatabase . the backend is mysql 4.0
can u able to help. if u are able todo this i will be really helpful to u.
bye


On 6/23/06, Riyaz Mansoor <[EMAIL PROTECTED]> wrote:



i'll keep it brief.

i'm looking to spend time on working on the new features coming to
tomcat 5.5 or 6

on the website, i could find no info on this. i was hoping there would
be a page listing the features being worked in 5.5 and the coming
features in 6

riyaz

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

49 matches

Mail list logo