Re: Proposed new CometEvent.notify method

[Remy Maucherat]

Filip Hanik - Dev Lists wrote:

yes, but that's ok. the sequence would be this
a) available() == 1
b) InputStream.read() == 0
c) available() == 0
what this would mean, is that available()==1 means there is data fetched 
from the actual socket, may or may not translate into user data.
In the sequence above, that is such a case, available returned 1, cause 
there was data, read returned 0 cause it didn't translate into user 
data, and further attempts to available() showed that there were no more 
data to be fetched.


When new data comes in, available() (non blocking) again shows up as 1, 
InputStream.read() may or may not return data.


I personally, think this would be an extremely elegant way to do non 
blocking read, as this would also be useful for regular servlets.


No, I don't agree with reading bytes in the lower layer as it would 
swallow problems even more than doing it in the adapter without any 
additional benefit (BTW, read cannot return 0). There's also a likely 
problem that it would require additional structures to hold that data, 
and which are present in the adapter.


Rémy

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

svn commit: r534930 - /tomcat/tc6.0.x/trunk/java/org/apache/catalina/core/AprLifecycleListener.java

[fhanik]

Author: fhanik
Date: Thu May  3 09:43:35 2007
New Revision: 534930

URL: http://svn.apache.org/viewvc?view=rev&rev=534930
Log:
Fix the bug in AprLifecycleListener, the value of SSLEngine is never 
transferred to the listener.
Patch submitted by mturk

Modified:
tomcat/tc6.0.x/trunk/java/org/apache/catalina/core/AprLifecycleListener.java

Modified: 
tomcat/tc6.0.x/trunk/java/org/apache/catalina/core/AprLifecycleListener.java
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/catalina/core/AprLifecycleListener.java?view=diff&rev=534930&r1=534929&r2=534930
==
--- 
tomcat/tc6.0.x/trunk/java/org/apache/catalina/core/AprLifecycleListener.java 
(original)
+++ 
tomcat/tc6.0.x/trunk/java/org/apache/catalina/core/AprLifecycleListener.java 
Thu May  3 09:43:35 2007
@@ -18,7 +18,9 @@
 package org.apache.catalina.core;
 
 
+import java.lang.reflect.InvocationTargetException;
 import java.lang.reflect.Method;
+
 import org.apache.catalina.Lifecycle;
 import org.apache.catalina.LifecycleEvent;
 import org.apache.catalina.LifecycleListener;
@@ -27,8 +29,6 @@
 import org.apache.juli.logging.LogFactory;
 import org.apache.tomcat.jni.Library;
 
-import java.lang.reflect.InvocationTargetException;
-
 
 
 /**
@@ -213,6 +213,14 @@
 Method method = clazz.getMethod(methodName, paramTypes);
 method.invoke(null, paramValues);
 sslInitialized = true;
+}
+
+public String getSSLEngine() {
+return SSLEngine;
+}
+
+public void setSSLEngine(String SSLEngine) {
+this.SSLEngine = SSLEngine;
 }
 
 }



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

Re: Proposed new CometEvent.notify method

[Filip Hanik - Dev Lists]

Remy Maucherat wrote:

Filip Hanik - Dev Lists wrote:

yes, but that's ok. the sequence would be this
a) available() == 1
b) InputStream.read() == 0
c) available() == 0
what this would mean, is that available()==1 means there is data 
fetched from the actual socket, may or may not translate into user data.
In the sequence above, that is such a case, available returned 1, 
cause there was data, read returned 0 cause it didn't translate into 
user data, and further attempts to available() showed that there were 
no more data to be fetched.


When new data comes in, available() (non blocking) again shows up as 
1, InputStream.read() may or may not return data.


I personally, think this would be an extremely elegant way to do non 
blocking read, as this would also be useful for regular servlets.


No, I don't agree with reading bytes in the lower layer as it would 
swallow problems even more than doing it in the adapter without any 
additional benefit (BTW, read cannot return 0). There's also a likely 
problem that it would require additional structures to hold that data, 
and which are present in the adapter.
Let's not shut it down quite yet, and move forward, as I think there 
could be some value behind this.

also, why can't read return 0?

More to come
Filip


Rémy

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

Re: Proposed new CometEvent.notify method

[Remy Maucherat]

Filip Hanik - Dev Lists wrote:
No, I don't agree with reading bytes in the lower layer as it would 
swallow problems even more than doing it in the adapter without any 
additional benefit (BTW, read cannot return 0). There's also a likely 
problem that it would require additional structures to hold that data, 
and which are present in the adapter.
Let's not shut it down quite yet, and move forward, as I think there 
could be some value behind this.


It's simply I feel CoyoteAdapter.event is a better place to experiment 
with doing a read and is extremely simple (it would call 
InputBuffer.realReadBytes).



also, why can't read return 0?


It's the contract of this API (which is blocking IO), it's not me ;)

Rémy

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

Re: Proposed new CometEvent.notify method

[Filip Hanik - Dev Lists]

Remy Maucherat wrote:

Filip Hanik - Dev Lists wrote:
No, I don't agree with reading bytes in the lower layer as it would 
swallow problems even more than doing it in the adapter without any 
additional benefit (BTW, read cannot return 0). There's also a 
likely problem that it would require additional structures to hold 
that data, and which are present in the adapter.
Let's not shut it down quite yet, and move forward, as I think there 
could be some value behind this.


It's simply I feel CoyoteAdapter.event is a better place to experiment 
with doing a read and is extremely simple (it would call 
InputBuffer.realReadBytes).



also, why can't read return 0?


It's the contract of this API (which is blocking IO), it's not me ;)
I hear you loud and clear, although the API doesn't specify as 0 being 
an illegal value, it is assumed in many places in the code that the 
value is either -1 or >0

http://java.sun.com/j2se/1.5.0/docs/api/java/io/InputStream.html#read(byte[])

I still don't think CoyoteAdapter.event is the right place for it 
either, I think we can do better than that.
Let me experiment a little bit, in the meantime, I still think we should 
push out a stable version sooner rather than later.


Filip



Rémy

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

svn commit: r535030 - in /tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector: CoyoteAdapter.java InputBuffer.java Request.java

[remm]

Author: remm
Date: Thu May  3 16:54:31 2007
New Revision: 535030

URL: http://svn.apache.org/viewvc?view=rev&rev=535030
Log:
- Remove the didRead flag (an error checking hack).
- If there is a read event, do at least one read on the connector (the buffer 
is necessarily empty, otherwise
  there would have been an error during the previous read event).
- Side effect: EOFs can be reported using the END event, and exceptions can be 
reported as ERROR.

Modified:
tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/CoyoteAdapter.java
tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/InputBuffer.java
tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/Request.java

Modified: 
tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/CoyoteAdapter.java
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/CoyoteAdapter.java?view=diff&rev=535030&r1=535029&r2=535030
==
--- tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/CoyoteAdapter.java 
(original)
+++ tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/CoyoteAdapter.java 
Thu May  3 16:54:31 2007
@@ -127,10 +127,24 @@
 
request.getEvent().setEventType(CometEvent.EventType.END);
 request.getEvent().setEventSubType(null);
 } else {
-
request.getEvent().setEventType(CometEvent.EventType.READ);
-request.getEvent().setEventSubType(null);
-read = true;
-request.resetDidRead();
+try {
+// Fill the read buffer of the servlet layer
+if (request.read()) {
+read = true;
+}
+} catch (Exception e) {
+error = true;
+}
+if (read) {
+
request.getEvent().setEventType(CometEvent.EventType.READ);
+request.getEvent().setEventSubType(null);
+} else if (error) {
+
request.getEvent().setEventType(CometEvent.EventType.ERROR);
+
request.getEvent().setEventSubType(CometEvent.EventSubType.CLIENT_DISCONNECT);
+} else {
+
request.getEvent().setEventType(CometEvent.EventType.END);
+request.getEvent().setEventSubType(null);
+}
 }
 } else if (status == SocketStatus.DISCONNECT) {
 
request.getEvent().setEventType(CometEvent.EventType.ERROR);
@@ -170,7 +184,7 @@
 }
 if (response.isClosed() || !request.isComet()) {
 res.action(ActionCode.ACTION_COMET_END, null);
-} else if (!error && read && (!request.didRead() || 
request.getAvailable())) {
+} else if (!error && read && request.getAvailable()) {
 // If this was a read and not all bytes have been read, or 
if no data
 // was read from the connector, then it is an error
 error = true;

Modified: 
tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/InputBuffer.java
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/InputBuffer.java?view=diff&rev=535030&r1=535029&r2=535030
==
--- tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/InputBuffer.java 
(original)
+++ tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/InputBuffer.java 
Thu May  3 16:54:31 2007
@@ -99,12 +99,6 @@
 
 
 /**
- * Flag which if a read was performed.
- */
-private boolean didRead = true;
-
-
-/**
  * Byte chunk used to input bytes.
  */
 private ByteChunk inputChunk = new ByteChunk();
@@ -274,28 +268,10 @@
 coyoteRequest.action(ActionCode.ACTION_AVAILABLE, null);
 available = (coyoteRequest.getAvailable() > 0) ? 1 : 0;
 }
-if ((available == 0) && !didRead) {
-// This is a comet read and no read was done: at least one
-// read can be made without blocking (in very rare cases, it will
-// reach the end of the stream, for example if the bytes sent 
-// were from a next request, or if the request content-length is
-// wrong)
-available = 1;
-}
 return available;
 }
 
 
-public boolean didRead() {
-return didRead;
-}
-
-
-public void resetDidRead() {
-didRead = false;
-}
-
-
 // - Bytes Handling Methods
 
 
@@ -317,7 +293,6 @@

Re: Proposed new CometEvent.notify method

[Remy Maucherat]

Filip Hanik - Dev Lists wrote:

It's the contract of this API (which is blocking IO), it's not me ;)
I hear you loud and clear, although the API doesn't specify as 0 being 
an illegal value, it is assumed in many places in the code that the 
value is either -1 or >0
http://java.sun.com/j2se/1.5.0/docs/api/java/io/InputStream.html#read(byte[]) 


0 is the characteristic of non blocking IO. Reading the javadocs, it 
seems obvious 0 is never allowed except for basic argument error cases:


If b is null, a NullPointerException is thrown. If the length of b is 
zero, then no bytes are read and 0 is returned; otherwise, there is an 
attempt to read at least one byte. If no byte is available because the 
stream is at end of file, the value -1 is returned; otherwise, at least 
one byte is read and stored into b.


I still don't think CoyoteAdapter.event is the right place for it 
either, I think we can do better than that.
Let me experiment a little bit, in the meantime, I still think we should 
push out a stable version sooner rather than later.


Ok, I'll try something in the meantime in CoyoteAdapter, since it's 
trivial (and I think does all that is needed at this point).


I would be ok to tag 6.0.13 before doing any further functional changes, 
as it contains numerous bugfixes since 6.0.10.


Rémy


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

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

[remm]

Author: remm
Date: Thu May  3 17:04:39 2007
New Revision: 535035

URL: http://svn.apache.org/viewvc?view=rev&rev=535035
Log:
- Use the better IOException type (any other exception is totally unexpected).

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

Modified: 
tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/CoyoteAdapter.java
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/CoyoteAdapter.java?view=diff&rev=535035&r1=535034&r2=535035
==
--- tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/CoyoteAdapter.java 
(original)
+++ tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/CoyoteAdapter.java 
Thu May  3 17:04:39 2007
@@ -132,7 +132,7 @@
 if (request.read()) {
 read = true;
 }
-} catch (Exception e) {
+} catch (IOException e) {
 error = true;
 }
 if (read) {



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

svn commit: r535038 - in /tomcat/tc6.0.x/trunk/java/org/apache/catalina/startup: Constants.java DigesterFactory.java

[remm]

Author: remm
Date: Thu May  3 17:19:56 2007
New Revision: 535038

URL: http://svn.apache.org/viewvc?view=rev&rev=535038
Log:
- Add some xsds to the constants.

Modified:
tomcat/tc6.0.x/trunk/java/org/apache/catalina/startup/Constants.java
tomcat/tc6.0.x/trunk/java/org/apache/catalina/startup/DigesterFactory.java

Modified: tomcat/tc6.0.x/trunk/java/org/apache/catalina/startup/Constants.java
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/catalina/startup/Constants.java?view=diff&rev=535038&r1=535037&r2=535038
==
--- tomcat/tc6.0.x/trunk/java/org/apache/catalina/startup/Constants.java 
(original)
+++ tomcat/tc6.0.x/trunk/java/org/apache/catalina/startup/Constants.java Thu 
May  3 17:19:56 2007
@@ -49,10 +49,15 @@
 "/javax/servlet/jsp/resources/web-jsptaglibrary_1_2.dtd";
 
 public static final String TldSchemaPublicId_20 =
-"web-jsptaglibrary_2_0.xsd";;
+"web-jsptaglibrary_2_0.xsd";
 public static final String TldSchemaResourcePath_20 =
 "/javax/servlet/jsp/resources/web-jsptaglibrary_2_0.xsd";
 
+public static final String TldSchemaPublicId_21 =
+"web-jsptaglibrary_2_1.xsd";
+public static final String TldSchemaResourcePath_21 =
+"/javax/servlet/jsp/resources/web-jsptaglibrary_2_1.xsd";
+
 public static final String WebDtdPublicId_22 =
 "-//Sun Microsystems, Inc.//DTD Web Application 2.2//EN";
 public static final String WebDtdResourcePath_22 =
@@ -64,24 +69,34 @@
 "/javax/servlet/resources/web-app_2_3.dtd";
 
 public static final String WebSchemaPublicId_24 =
-"web-app_2_4.xsd";;
+"web-app_2_4.xsd";
 public static final String WebSchemaResourcePath_24 =
 "/javax/servlet/resources/web-app_2_4.xsd";
 
+public static final String WebSchemaPublicId_25 =
+"web-app_2_5.xsd";
+public static final String WebSchemaResourcePath_25 =
+"/javax/servlet/resources/web-app_2_5.xsd";
+
 public static final String J2eeSchemaPublicId_14 =
-"j2ee_1_4.xsd";;
+"j2ee_1_4.xsd";
 public static final String J2eeSchemaResourcePath_14 =
 "/javax/servlet/resources/j2ee_1_4.xsd";
 
 public static final String W3cSchemaPublicId_10 =
-"xml.xsd";;
+"xml.xsd";
 public static final String W3cSchemaResourcePath_10 =
 "/javax/servlet/resources/xml.xsd";
 
 public static final String JspSchemaPublicId_20 =
-"jsp_2_0.xsd";;
+"jsp_2_0.xsd";
 public static final String JspSchemaResourcePath_20 =
 "/javax/servlet/jsp/resources/jsp_2_0.xsd";
+
+public static final String JspSchemaPublicId_21 =
+"jsp_2_1.xsd";
+public static final String JspSchemaResourcePath_21 =
+"/javax/servlet/jsp/resources/jsp_2_1.xsd";
 
 public static final String J2eeWebServiceSchemaPublicId_11 =
 "j2ee_web_services_1_1.xsd";

Modified: 
tomcat/tc6.0.x/trunk/java/org/apache/catalina/startup/DigesterFactory.java
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/catalina/startup/DigesterFactory.java?view=diff&rev=535038&r1=535037&r2=535038
==
--- tomcat/tc6.0.x/trunk/java/org/apache/catalina/startup/DigesterFactory.java 
(original)
+++ tomcat/tc6.0.x/trunk/java/org/apache/catalina/startup/DigesterFactory.java 
Thu May  3 17:19:56 2007
@@ -104,6 +104,10 @@
 // JSP
 register(Constants.JspSchemaResourcePath_20,
  Constants.JspSchemaPublicId_20);
+
+register(Constants.JspSchemaResourcePath_21,
+Constants.JspSchemaPublicId_21);
+
 // TLD
 register(Constants.TldDtdResourcePath_11,  
  Constants.TldDtdPublicId_11);
@@ -114,6 +118,9 @@
 register(Constants.TldSchemaResourcePath_20,
  Constants.TldSchemaPublicId_20);
 
+register(Constants.TldSchemaResourcePath_21,
+Constants.TldSchemaPublicId_21);
+
 // web.xml
 register(Constants.WebDtdResourcePath_22,
  Constants.WebDtdPublicId_22);
@@ -123,6 +130,9 @@
 
 register(Constants.WebSchemaResourcePath_24,
  Constants.WebSchemaPublicId_24);
+
+register(Constants.WebSchemaResourcePath_25,
+Constants.WebSchemaPublicId_25);
 
 // Web Service
 register(Constants.J2eeWebServiceSchemaResourcePath_11,



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

Re: Proposed new CometEvent.notify method

[Filip Hanik - Dev Lists]

Remy Maucherat wrote:

Filip Hanik - Dev Lists wrote:

It's the contract of this API (which is blocking IO), it's not me ;)
I hear you loud and clear, although the API doesn't specify as 0 
being an illegal value, it is assumed in many places in the code that 
the value is either -1 or >0
http://java.sun.com/j2se/1.5.0/docs/api/java/io/InputStream.html#read(byte[]) 



0 is the characteristic of non blocking IO. Reading the javadocs, it 
seems obvious 0 is never allowed except for basic argument error cases:


If b is null, a NullPointerException is thrown. If the length of b is 
zero, then no bytes are read and 0 is returned; otherwise, there is an 
attempt to read at least one byte. If no byte is available because the 
stream is at end of file, the value -1 is returned; otherwise, at 
least one byte is read and stored into b.


I still don't think CoyoteAdapter.event is the right place for it 
either, I think we can do better than that.
Let me experiment a little bit, in the meantime, I still think we 
should push out a stable version sooner rather than later.


Ok, I'll try something in the meantime in CoyoteAdapter, since it's 
trivial (and I think does all that is needed at this point).
The available() has a side effect, if there is a partial or non valid 
chunked header (ie the client also sends some garbage), available() 
returns >0, and the read() goes into a forever blocking read as no more 
data is coming in.
this was not the case before, as a READ event, you did one read, and 
then available returned 0, and you'd be fine until next READ event.
since it's a client data error, I'm ok with it, question is, how common 
are these client errors.


I would be ok to tag 6.0.13 before doing any further functional 
changes, as it contains numerous bugfixes since 6.0.10.
Let us wait a few days for these available() changes to get some 
feedback, then we can tag and go through our stability tests.


Filip


Rémy


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

Re: Proposed new CometEvent.notify method

[Remy Maucherat]

Filip Hanik - Dev Lists wrote:
Ok, I'll try something in the meantime in CoyoteAdapter, since it's 
trivial (and I think does all that is needed at this point).
The available() has a side effect, if there is a partial or non valid 
chunked header (ie the client also sends some garbage), available() 
returns >0, and the read() goes into a forever blocking read as no more 
data is coming in.
this was not the case before, as a READ event, you did one read, and 
then available returned 0, and you'd be fine until next READ event.
since it's a client data error, I'm ok with it, question is, how common 
are these client errors.


It doesn't really make a difference. Even if you do only one read during 
the read event, it is possible to only send a portion of the chunk 
header, causing the ChunkedInputBuffer to block if its previous chunk 
was fully read (or if it is the first chunk). The only realistic 
solution is to add a system property forbidding reads during parsing of 
the chunk header, as I don't think it's a very reasonable situation.


I would be ok to tag 6.0.13 before doing any further functional 
changes, as it contains numerous bugfixes since 6.0.10.
Let us wait a few days for these available() changes to get some 
feedback, then we can tag and go through our stability tests.


Ok. I was ready to tag tomorrow evening before starting on the timeout 
feature for APR, but I can wait more if you have changes to do 
(otherwise, I don't think anyone is going to really test since it's the 
WE). I can tag again if there's a horrible bug.


Rémy


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

Re: svn commit: r534695 - /tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/Http11NioProcessor.java

[Remy Maucherat]

[EMAIL PROTECTED] wrote:

Author: fhanik
Date: Wed May  2 19:35:56 2007
New Revision: 534695

URL: http://svn.apache.org/viewvc?view=rev&rev=534695
Log:
Same fix as for the APR processor, although wouldn't this flag be set on the 
"recycle" method


Yes, I did not commit the same patch for the NIO connector since it was 
useless there (the flag is reset in recycle, which was not the case in 
the APR connector).


Rémy

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

Re: Proposed new CometEvent.notify method

[Filip Hanik - Dev Lists]

Remy Maucherat wrote:

Remy Maucherat wrote:

Hi,

To more conveniently support some use cases, a new notify method 
could be added to the event. This would do an action callback and 
call a new method in the Poller class would add the socket to a 
structure like the socket add list. The comet poller thread will then 
check if there are sockets in that list, and call an event (as for 
the event type, it could be a regular timeout - it's very similar - 
or a new type which will behave the same as timeout - which would be 
significantly harder since modifications will have to be made to 
accommodate the new event type).


I know how to make this fairly easily with the APR connector, and I'm 
not so sure about the NIO one (most likely it's very similar, 
however). The main thing which is annoying to implement is if the 
fact that there will not be any other concurrent event occurring has 
to be enforced and there are multiple pollers (I think the socket has 
to be removed "just in case" from each poller, which is quite annoying).


Along with it, I think a semi dynamic option should be added to not 
use read polling (which does funky stuff in certain cases, since when 
using pipelining, there's data available but the data may actually not 
belong to this request), but still check timeout. I think per 
connection timeout should also be supported by APR. Having these in 
addition to notify() would allow all possible usage scenarios without 
running into funny corner cases.
Just to understand it right event.notify() will call back into the 
endpoint (through an actionhook) and this issues a 
XXXEndpoint.process(socket) so that they the comet servlet has a worker 
thread to piggy back on? (sort of simulate a read event), except the 
event type will be NOTIFY, or the sub type will be NOTIFY.
That sounds good to me, since there are use cases that are very hard to 
do if it is done asynchronously through an external thread.


Basically, to create an "async servlet" the code would simply look like this

a) make sure it is not registered for READ event
b) call event.close()
c) call event.notify() - yields a END or NOTIFY event

this would recycle the connection/req/resp, and voila, we have async 
servlet, AJAX style.

Let me know if I'm on the wrong path here

So in terms of code could we
1. Change "boolean comet =" to "int comet =" or to a list of enum, based 
on if you want to register for a read with the poller or to not have any 
poller interaction
  So reuse the same code we have, and at the end decide what list to 
add the connection too, the Poller.READ or Poller.NOOP (pardon my own 
names:)
  The CometProcessor could use the CometEvent to decide during the 
BEGIN event, whether to register for READ or not.
2. I'd like to expand on available, is it possible to at the very bottom 
InternalXXXInputBuffer.SocketInputBuffer, to issue a non block read, 
that would read data into the first buffer, to see if there even was any 
data. this would solve our non-blocking read issue. Basically the length 
would then have to be kept around so that when a read is issued, and 
there already is some data in the buffer, don't reissue it, and just 
return the length.
3. Still haven't come up with a good/clean idea for non block write, 
next week will open up much more time for this.
  For a while I was thinking of registering the connection for 
Poller.WRITE, to notify the servlet when a write is doable without 
blocking, however, this cause the same concurrency issues as the 
Poller.READ does, so I have put it on the back burner for now.


thoughts on these suggestions? more to come from this corner soon,

Filip





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

Re: svn commit: r534695 - /tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/Http11NioProcessor.java

[Filip Hanik - Dev Lists]

Remy Maucherat wrote:

[EMAIL PROTECTED] wrote:

Author: fhanik
Date: Wed May  2 19:35:56 2007
New Revision: 534695

URL: http://svn.apache.org/viewvc?view=rev&rev=534695
Log:
Same fix as for the APR processor, although wouldn't this flag be set 
on the "recycle" method


Yes, I did not commit the same patch for the NIO connector since it 
was useless there (the flag is reset in recycle, which was not the 
case in the APR connector).
I figured, it's good to be on the same page. Maybe one of these days we 
can actually consolidate a lot of this stuff, TC 6.X+Y :)

Filip


Rémy

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

Re: Proposed new CometEvent.notify method

[Filip Hanik - Dev Lists]

Remy Maucherat wrote:

Remy Maucherat wrote:

Hi,

To more conveniently support some use cases, a new notify method 
could be added to the event. This would do an action callback and 
call a new method in the Poller class would add the socket to a 
structure like the socket add list. The comet poller thread will then 
check if there are sockets in that list, and call an event (as for 
the event type, it could be a regular timeout - it's very similar - 
or a new type which will behave the same as timeout - which would be 
significantly harder since modifications will have to be made to 
accommodate the new event type).


I know how to make this fairly easily with the APR connector, and I'm 
not so sure about the NIO one (most likely it's very similar, 
however). The main thing which is annoying to implement is if the 
fact that there will not be any other concurrent event occurring has 
to be enforced and there are multiple pollers (I think the socket has 
to be removed "just in case" from each poller, which is quite annoying).


Along with it, I think a semi dynamic option should be added to not 
use read polling (which does funky stuff in certain cases, since when 
using pipelining, there's data available but the data may actually not 
belong to this request), but still check timeout. I think per 
connection timeout should also be supported by APR. Having these in 
addition to n.tify() would allow all possible usage scenarios without 
running into funny corner cases.


Oh by the way, before we start doing all this, I'd really like to push 
out another "stable" 6.0. There's been tons of bug fixes, and before we 
put everything on the chopping block again, lets push those out.


Filip



Rémy

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

Re: Proposed new CometEvent.notify method

[Remy Maucherat]

Filip Hanik - Dev Lists wrote:

a) make sure it is not registered for READ event
b) call event.close()
c) call event.notify() - yields a END or NOTIFY event


You need to be doing stuff in your servlet somewhere in between too.

1. Change "boolean comet =" to "int comet =" or to a list of enum, based 
on if you want to register for a read with the poller or to not have any 
poller interaction
  So reuse the same code we have, and at the end decide what list to add 
the connection too, the Poller.READ or Poller.NOOP (pardon my own names:)
  The CometProcessor could use the CometEvent to decide during the BEGIN 
event, whether to register for READ or not.


Unfortunately, I will have to redo the timeout code for APR, since it 
turns out to be too limited (IMO).


2. I'd like to expand on available, is it possible to at the very bottom 
InternalXXXInputBuffer.SocketInputBuffer, to issue a non block read, 
that would read data into the first buffer, to see if there even was any 
data. this would solve our non-blocking read issue. Basically the length 
would then have to be kept around so that when a read is issued, and 
there already is some data in the buffer, don't reissue it, and just 
return the length.


If you do a read, it would be to call 
connector.InputBuffer.realReadBytes, and I'm still not sure about it (I 
think the servlet could be interested in an eventual exception, for 
example). Doing a read at the lower level is not useful as the bytes may 
not be actual data.


3. Still haven't come up with a good/clean idea for non block write, 
next week will open up much more time for this.
  For a while I was thinking of registering the connection for 
Poller.WRITE, to notify the servlet when a write is doable without 
blocking, however, this cause the same concurrency issues as the 
Poller.READ does, so I have put it on the back burner for now.


Write polling is a bit difficult probably.

Rémy


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

svn commit: r534913 - /tomcat/tc6.0.x/trunk/java/org/apache/catalina/startup/Embedded.java

[fhanik]

Author: fhanik
Date: Thu May  3 08:49:09 2007
New Revision: 534913

URL: http://svn.apache.org/viewvc?view=rev&rev=534913
Log:
Ability to create a connector using a custom protocol specification for 
embedded.
Fix for bug 42309

Modified:
tomcat/tc6.0.x/trunk/java/org/apache/catalina/startup/Embedded.java

Modified: tomcat/tc6.0.x/trunk/java/org/apache/catalina/startup/Embedded.java
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/catalina/startup/Embedded.java?view=diff&rev=534913&r1=534912&r2=534913
==
--- tomcat/tc6.0.x/trunk/java/org/apache/catalina/startup/Embedded.java 
(original)
+++ tomcat/tc6.0.x/trunk/java/org/apache/catalina/startup/Embedded.java Thu May 
 3 08:49:09 2007
@@ -427,7 +427,10 @@
 connector = new Connector();
 connector.setScheme("https");
 connector.setSecure(true);
+connector.setProperty("SSLEnabled","true");
 // FIXME  SET SSL PROPERTIES
+} else {
+connector = new Connector(protocol);
 }
 
 if (address != null) {



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

Re: Proposed new CometEvent.notify method

[Remy Maucherat]

Filip Hanik - Dev Lists wrote:
Oh by the way, before we start doing all this, I'd really like to push 
out another "stable" 6.0. There's been tons of bug fixes, and before we 
put everything on the chopping block again, lets push those out.


It's a possibility, but the current svn is still in the tuning process 
at the moment. I don't think there would be that many changes overall 
(with the exception of updating timeout processing for APR).


Rémy

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

Re: Proposed new CometEvent.notify method

[Filip Hanik - Dev Lists]

Remy Maucherat wrote:

Filip Hanik - Dev Lists wrote:

a) make sure it is not registered for READ event
b) call event.close()
c) call event.notify() - yields a END or NOTIFY event


You need to be doing stuff in your servlet somewhere in between too.
yes, that's what I meant, this would be in the "UserServlets that 
implements CometProcessor"


1. Change "boolean comet =" to "int comet =" or to a list of enum, 
based on if you want to register for a read with the poller or to not 
have any poller interaction
  So reuse the same code we have, and at the end decide what list to 
add the connection too, the Poller.READ or Poller.NOOP (pardon my own 
names:)
  The CometProcessor could use the CometEvent to decide during the 
BEGIN event, whether to register for READ or not.


Unfortunately, I will have to redo the timeout code for APR, since it 
turns out to be too limited (IMO).

sure thing


2. I'd like to expand on available, is it possible to at the very 
bottom InternalXXXInputBuffer.SocketInputBuffer, to issue a non block 
read, that would read data into the first buffer, to see if there 
even was any data. this would solve our non-blocking read issue. 
Basically the length would then have to be kept around so that when a 
read is issued, and there already is some data in the buffer, don't 
reissue it, and just return the length.


If you do a read, it would be to call 
connector.InputBuffer.realReadBytes, and I'm still not sure about it 
(I think the servlet could be interested in an eventual exception, for 
example). Doing a read at the lower level is not useful as the bytes 
may not be actual data.

yes, but that's ok. the sequence would be this
a) available() == 1
b) InputStream.read() == 0
c) available() == 0
what this would mean, is that available()==1 means there is data fetched 
from the actual socket, may or may not translate into user data.
In the sequence above, that is such a case, available returned 1, cause 
there was data, read returned 0 cause it didn't translate into user 
data, and further attempts to available() showed that there were no more 
data to be fetched.


When new data comes in, available() (non blocking) again shows up as 1, 
InputStream.read() may or may not return data.


I personally, think this would be an extremely elegant way to do non 
blocking read, as this would also be useful for regular servlets.




3. Still haven't come up with a good/clean idea for non block write, 
next week will open up much more time for this.
  For a while I was thinking of registering the connection for 
Poller.WRITE, to notify the servlet when a write is doable without 
blocking, however, this cause the same concurrency issues as the 
Poller.READ does, so I have put it on the back burner for now.


Write polling is a bit difficult probably.

yes, lets defer it for a bit, its a concurrency nightmare.

Filip


Rémy


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

DO NOT REPLY [Bug 42309] - Request: support for NIO in Embedded Tomcat

[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=42309


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2007-05-03 09:02 ---
Fixed,
just call createConnector with "org.apache.coyote.http11.http11NioProtocol" as
your protocol parameter

-- 
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: Proposed new CometEvent.notify method

[Filip Hanik - Dev Lists]

Remy Maucherat wrote:

Filip Hanik - Dev Lists wrote:
Oh by the way, before we start doing all this, I'd really like to 
push out another "stable" 6.0. There's been tons of bug fixes, and 
before we put everything on the chopping block again, lets push those 
out.


It's a possibility, but the current svn is still in the tuning process 
at the moment. I don't think there would be that many changes overall 
(with the exception of updating timeout processing for APR).
The reason I say, is cause I'm eager to get out fixed memory leaks and 
the executor, as it allows pluggable thread pools, big improvement, and 
works very well

Filip


Rémy

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

Re: Proposed new CometEvent.notify method

[Remy Maucherat]

Filip Hanik - Dev Lists wrote:

Remy Maucherat wrote:

Filip Hanik - Dev Lists wrote:
Oh by the way, before we start doing all this, I'd really like to 
push out another "stable" 6.0. There's been tons of bug fixes, and 
before we put everything on the chopping block again, lets push those 
out.


It's a possibility, but the current svn is still in the tuning process 
at the moment. I don't think there would be that many changes overall 
(with the exception of updating timeout processing for APR).
The reason I say, is cause I'm eager to get out fixed memory leaks and 
the executor, as it allows pluggable thread pools, big improvement, and 
works very well


I think it's too slow, so I don't like executors :(

Rémy

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