DO NOT REPLY [Bug 34939] New: - Wrong path to configure in jk/BUILD.txt
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=34939. 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=34939 Summary: Wrong path to configure in jk/BUILD.txt Product: Tomcat 5 Version: Unknown Platform: Other OS/Version: other Status: NEW Severity: trivial Priority: P2 Component: Native:JK AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] The path to configure in the exemple given in the file jk/BUILD.txt for jtc-jk-1.2.13 should be './configure' instead of '../configure'. -- 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]
cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net AprEndpoint.java
remm2005/05/17 05:20:20
Modified:util/java/org/apache/tomcat/util/net AprEndpoint.java
Log:
- Add javadocs.
- Fix sync on the arrylist for sendfile (in the case where stuff is added to
the
array list, which I haven't seen happen yet).
Revision ChangesPath
1.27 +62 -24
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net/AprEndpoint.java
Index: AprEndpoint.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net/AprEndpoint.java,v
retrieving revision 1.26
retrieving revision 1.27
diff -u -r1.26 -r1.27
--- AprEndpoint.java 14 May 2005 15:42:30 - 1.26
+++ AprEndpoint.java 17 May 2005 12:20:20 - 1.27
@@ -727,6 +727,10 @@
protected long[] addP;
protected int addCount = 0;
+/**
+ * Create the poller. With some versions of APR, the maximum poller
size will
+ * be 62 (reocmpiling APR is necessary to remove this limitation).
+ */
protected synchronized void init() {
pool = Pool.create(serverSockPool);
try {
@@ -751,10 +755,22 @@
addP = new long[pollerSize];
}
+/**
+ * Destroy the poller.
+ */
protected void destroy() {
Pool.destroy(pool);
}
+/**
+ * Add specified socket and associated pool to the poller. The
socket will
+ * be added to a temporary array, and polled first after a maximum
amount
+ * of time equal to pollTime (in most cases, latency will be much
lower,
+ * however).
+ *
+ * @param socket to add to the poller
+ * @param pool reprenting the memory used for the socket
+ */
public void add(long socket, long pool) {
synchronized (addS) {
// Add socket to the list. Newly added sockets will wait
@@ -1018,6 +1034,10 @@
protected ArrayList addS;
+/**
+ * Create the sendfile poller. With some versions of APR, the
maximum poller size will
+ * be 62 (reocmpiling APR is necessary to remove this limitation).
+ */
protected void init() {
pool = Pool.create(serverSockPool);
try {
@@ -1041,11 +1061,24 @@
addS = new ArrayList();
}
+/**
+ * Destroy the poller.
+ */
protected void destroy() {
sendfileData.clear();
Pool.destroy(pool);
}
+/**
+ * Add the sendfile data to the sendfile poller. Note that in most
cases,
+ * the initial non blocking calls to sendfile will return right
away, and
+ * will be handled asynchronously inside the kernel. As a result,
+ * the poller will never be used.
+ *
+ * @param data containing the reference to the data which should be
snet
+ * @return true if all the data has been sent right away, and false
+ * otherwise
+ */
public boolean add(SendfileData data) {
// Initialize fd from data given
try {
@@ -1091,16 +1124,19 @@
return false;
}
-public void remove(long socket) {
-synchronized (this) {
-int rv = Poll.remove(sendfilePollset, socket);
-if (rv == Status.APR_SUCCESS) {
-sendfileCount--;
-}
-// Set the socket to blocking mode again
-Socket.optSet(socket, Socket.APR_SO_NONBLOCK, 0);
-sendfileData.remove(new Long(socket));
-}
+/**
+ * Remove socket from the poller.
+ *
+ * @param data the sendfile data which should be removed
+ */
+protected void remove(SendfileData data) {
+int rv = Poll.remove(sendfilePollset, data.socket);
+if (rv == Status.APR_SUCCESS) {
+sendfileCount--;
+}
+// Set the socket to blocking mode again
+Socket.optSet(data.socket, Socket.APR_SO_NONBLOCK, 0);
+sendfileData.remove(data);
}
/**
@@ -1132,19 +1168,21 @@
try {
// Add socket to the poller
if (addS.size() 0) {
-for (int i = 0; i addS.size(); i++) {
-SendfileData data = (SendfileData) addS.get(i);
-int rv = Poll.add(sendfilePollset, data.socket,
0, Poll.APR_POLLOUT);
-if (rv == Status.APR_SUCCESS) {
-
Re: JK 1.2.13 TAGGED
Hi Mladen, JK 1.2.13 has been taggeded as we agreed last week, and the tarballs are available at: http://www.apache.org/dist/jakarta/tomcat-connectors/jk/source/jk-1.2.13/ any particular reason why you didnt tag my last commit on jk_connect.c? http://cvs.apache.org/viewcvs.cgi/jakarta-tomcat-connectors/jk/native/common/jk_connect.c?rev=1.59view=log now we can again not build for AP13 on NetWare without patching. I thought you said last time that you are fine with the patch? Guenter. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
APR support
Hi, After optimizing JNI invocations with NIO, I got the benchmark results I wanted from APR. The performance of the HTTP APR connector is now the same as the regular HTTP connector (at least on Windows). Since stability seems good as well (barring programming errors on my part; this is obviously not a big surprise as a certain other project did all the testing already), I now feel comfortable taking sides and advocating APR as the next gen IO API for use in Tomcat. As I said, stability seems quite good overall, so I think the HTTP support should become an official part of the next release. Mladen is currently adding SSL support, while I am working on APRizing AJP (which would provide benefits for only certain specific use cases - sendfile isn't going to be available, for example). Note: The main other contending API is NIO, but APR now seems to me a far better choice, as it features a simpler objectless API, as well as flexible blocking mode handling (NIO forces to be all the time in non blocking mode, which has important performance costs for a server like Tomcat). It seems to have all the benefits without any drawbacks besides installation. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JK 1.2.13 TAGGED - ws_write call to ap_rflush in mod_jk.c
Jean-Jacques Clar wrote: re-sending : Am I missing details? Calling ap_rflush() at the end of ws_write() in mod_jk.c is causing me problems when doing downloads from the server to a client. Performance degradation and, less importantly, memory usage, are the problems. Seems we are the only module out there that calls the apr_rflush in Apache2. Althought I said 'no more features' I propose that we make a config option that will be in the form of: JkFlush (On|Off|size) with On as default for each packet write. That way we'd be able to flush after each write, flush after each 'size' bytes or not flush at all. How that sounds? Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 34693] - Tomcat infinite wait on noised network
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=34693. 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=34693 [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | --- Additional Comments From [EMAIL PROTECTED] 2005-05-17 19:05 --- Hi Remy, I have executed some other test and I have discovered that if I force the client-side (ie the internet browser) to use ONLY HTTP 1.0 (and NOT use HTTP 1.1) the problem disappears at all! In my opinion this is the evidence that the problem isn't in network-stack (excluding both of OS or java.net.*) . Regards, Roberto Colmegna -- 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]
Anne-Sophie Brichard/EUZ/ChubbMail is out of the office.
I will be out of the office starting 18/05/2005 and will not return until 30/05/2005. En cas d'urgence, merci de bien vouloir contacter Sandra Boutboul ([EMAIL PROTECTED]) au 01 70 36 65 90 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
