svn commit: r381594 - in /tomcat/connectors/trunk/jk/java/org/apache/coyote/ajp: AjpAprProcessor.java Constants.java

[mturk]

Author: mturk
Date: Tue Feb 28 00:53:23 2006
New Revision: 381594

URL: http://svn.apache.org/viewcvs?rev=381594&view=rev
Log:
Use constants instead directly hard coded values.
No functional change.

Modified:
tomcat/connectors/trunk/jk/java/org/apache/coyote/ajp/AjpAprProcessor.java
tomcat/connectors/trunk/jk/java/org/apache/coyote/ajp/Constants.java

Modified: 
tomcat/connectors/trunk/jk/java/org/apache/coyote/ajp/AjpAprProcessor.java
URL: 
http://svn.apache.org/viewcvs/tomcat/connectors/trunk/jk/java/org/apache/coyote/ajp/AjpAprProcessor.java?rev=381594&r1=381593&r2=381594&view=diff
==
--- tomcat/connectors/trunk/jk/java/org/apache/coyote/ajp/AjpAprProcessor.java 
(original)
+++ tomcat/connectors/trunk/jk/java/org/apache/coyote/ajp/AjpAprProcessor.java 
Tue Feb 28 00:53:23 2006
@@ -32,7 +32,6 @@
 import org.apache.coyote.Request;
 import org.apache.coyote.RequestInfo;
 import org.apache.coyote.Response;
-import org.apache.jk.common.AjpConstants;
 import org.apache.tomcat.jni.Socket;
 import org.apache.tomcat.jni.Status;
 import org.apache.tomcat.util.buf.ByteChunk;
@@ -78,7 +77,7 @@
 public AjpAprProcessor(AprEndpoint endpoint) {
 
 this.endpoint = endpoint;
-
+
 request = new Request();
 request.setInputBuffer(new SocketInputBuffer());
 
@@ -94,9 +93,9 @@
 }
 
 // Allocate input and output buffers
-inputBuffer = ByteBuffer.allocateDirect(16 * 1024);
+inputBuffer = ByteBuffer.allocateDirect(Constants.MAX_PACKET_SIZE * 2);
 inputBuffer.limit(0);
-outputBuffer = ByteBuffer.allocateDirect(16 * 1024);
+outputBuffer = ByteBuffer.allocateDirect(Constants.MAX_PACKET_SIZE * 
2);
 
 // Cause loading of HexUtils
 int foo = HexUtils.DEC[0];
@@ -131,15 +130,15 @@
 /**
  * Header message. Note that this header is merely the one used during the
  * processing of the first message of a "request", so it might not be a 
request
- * header. It will stay unchanged during the processing of the whole 
request. 
+ * header. It will stay unchanged during the processing of the whole 
request.
  */
-protected AjpMessage requestHeaderMessage = new AjpMessage(); 
+protected AjpMessage requestHeaderMessage = new AjpMessage();
 
 
 /**
- * Message used for response header composition. 
+ * Message used for response header composition.
  */
-protected AjpMessage responseHeaderMessage = new AjpMessage(); 
+protected AjpMessage responseHeaderMessage = new AjpMessage();
 
 
 /**
@@ -147,13 +146,13 @@
  */
 protected AjpMessage bodyMessage = new AjpMessage();
 
-
+
 /**
  * Body message.
  */
 protected MessageBytes bodyBytes = MessageBytes.newInstance();
 
-
+
 /**
  * State flag.
  */
@@ -189,80 +188,80 @@
  * header.
  */
 protected long readTimeout;
-
-
+
+
 /**
  * Temp message bytes used for processing.
  */
 protected MessageBytes tmpMB = MessageBytes.newInstance();
-
-
+
+
 /**
  * Byte chunk for certs.
  */
 protected MessageBytes certificates = MessageBytes.newInstance();
-
-
+
+
 /**
  * End of stream flag.
  */
 protected boolean endOfStream = false;
-
-
+
+
 /**
  * Body empty flag.
  */
 protected boolean empty = true;
-
-
+
+
 /**
  * First read.
  */
 protected boolean first = true;
-
-
+
+
 /**
  * Replay read.
  */
 protected boolean replay = false;
-
-
+
+
 /**
  * Finished response.
  */
 protected boolean finished = false;
-
-
+
+
 /**
  * Direct buffer used for output.
  */
 protected ByteBuffer outputBuffer = null;
-
-
+
+
 /**
  * Direct buffer used for input.
  */
 protected ByteBuffer inputBuffer = null;
-
-
+
+
 /**
  * Direct buffer used for sending right away a get body message.
  */
 protected static final ByteBuffer getBodyMessageBuffer;
-
-
+
+
 /**
  * Direct buffer used for sending right away a pong message.
  */
 protected static final ByteBuffer pongMessageBuffer;
-
-
+
+
 /**
  * End message array.
  */
 protected static final byte[] endMessageArray;
-
-
+
+
 // - Static Initializer
 
 
@@ -274,9 +273,9 @@
 getBodyMessage.appendByte(Constants.JK_AJP13_GET_BODY_CHUNK);
 getBodyMessage.appendInt(Constants.MAX_READ_SIZE);
 getBodyMessage.end();
-getBodyMessageBuffer = 
+getBodyMessageBuffer =
 ByteBuffer.allocateDirect(getBodyMessage.getLen());
-getBodyMessageBuffer.put(getBodyMessage.getBuffer(), 0, 
+getBodyMessageBuffer.put(getBodyMessage.getBuffer(), 0,
 getBodyMessage.

Re: svn commit: r381594 - in /tomcat/connectors/trunk/jk/java/org/apache/coyote/ajp: AjpAprProcessor.java Constants.java

[Remy Maucherat]

[EMAIL PROTECTED] wrote:

Author: mturk
Date: Tue Feb 28 00:53:23 2006
New Revision: 381594

URL: http://svn.apache.org/viewcvs?rev=381594&view=rev
Log:
Use constants instead directly hard coded values.
No functional change.


Can you change your editor, or configure it properly ?

Thanks,
Rémy

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

Re: svn commit: r381594 - in /tomcat/connectors/trunk/jk/java/org/apache/coyote/ajp: AjpAprProcessor.java Constants.java

[Mladen Turk]

Remy Maucherat wrote:

[EMAIL PROTECTED] wrote:

Author: mturk
Date: Tue Feb 28 00:53:23 2006
New Revision: 381594

URL: http://svn.apache.org/viewcvs?rev=381594&view=rev
Log:
Use constants instead directly hard coded values.
No functional change.


Can you change your editor, or configure it properly ?



It is correctly configured, although it removes the empty
lines and trailing spaces.
There were lots of empty lines with couple of spaces
only, so that's probably the reason for that.

Mladen.

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

Re: svn commit: r381594 - in /tomcat/connectors/trunk/jk/java/org/apache/coyote/ajp: AjpAprProcessor.java Constants.java

[Remy Maucherat]

Mladen Turk wrote:

It is correctly configured, although it removes the empty
lines and trailing spaces.
There were lots of empty lines with couple of spaces
only, so that's probably the reason for that.


I am asking to then similarly correctly configure your editor so that it 
does not remove empty lines and trailing spaces, since it is a 
gratuitous change which messes up diffs and makes long term maintenance 
harder.


Rémy

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

DO NOT REPLY [Bug 38804] New: - context path auto detecting problem

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

   Summary: context path auto detecting problem
   Product: Tomcat 5
   Version: Nightly Build
  Platform: All
OS/Version: other
Status: NEW
  Severity: normal
  Priority: P2
 Component: Catalina
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


sorry for poor my english
first of all, thank you your helping

I have a a problem using Tomcat 5.5.15

my webapps name is latte and 
latte has a same name subdirectory latte

webapps/latte/WEB-INF
webapps/latte/latte/test.jsp

latte context path is "", meanig is default 
In server.xml


when I requests "/latte/test.jsp "
browser's response is 404 not found "/test.jsp"

when I used tomcat 4.1.30, that is ok

Maybe tomcat 5.5 detect latte as context path automatically
because latte directory has a subdirectory WEB-INF 
How can I disable auto detection or How can I fixing my configuration

my manager/html/list 

Applications 
Path DisplayName Running Sessions Commands 
/  true 0  Start   Stop   
Reload   Undeploy   
/CVS   true 0  Start   Stop   
Reload   Undeploy   
/adminTomcat Administration Applicationtrue 1  Start   Stop   
Reload   Undeploy   
/latte true 0  Start   Stop   
Reload   Undeploy   
/manager  Tomcat Manager Application   true 0  Start   Stop   
Reload   Undeploy   

If I use rename latte to ROOT then it's clear
but I have 3 different hosts in one tomcat

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

DO NOT REPLY [Bug 38806] New: - Disabled workers in mod_jk are not retried once they get in error state

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

   Summary: Disabled workers in mod_jk are not retried once they get
in error state
   Product: Tomcat 5
   Version: Unknown
  Platform: Other
OS/Version: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: Native:JK
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


I use mod_jk 1.2.15 in a failover configuration with session stickyness:

# List of available workers
worker.list=failover
 
# Master worker
# Take care that the jvmRoute attribute in the Engine tag is set to master
# for the Tomcat addressed by MASTER_HOST and MASTER_PORT
worker.master.port=MASTER_PORT
worker.master.host=MASTER_HOST
worker.master.type=ajp13
worker.master.cachesize=10
worker.master.cache_timeout=600
worker.master.socket_keepalive=1
worker.master.prepost_timeout=300
worker.master.reply_timeout=12
worker.master.recovery_options=3
# redirect to backup if master fails
worker.master.redirect=backup

# Backup worker for failover
# Take care that the jvmRoute attribute in the Engine tag is set to backup
# for the Tomcat addressed by BACKUP_HOST and BACKUP_PORT
worker.backup.port=BACKUP_PORT
worker.backup.host=BACKUP_HOST
worker.backup.type=ajp13
worker.backup.cachesize=10
worker.backup.cache_timeout=600
worker.backup.socket_keepalive=1
worker.backup.prepost_timeout=300
worker.backup.reply_timeout=12
worker.backup.recovery_options=3
# Set worker to disabled. This means it gets only requests in the case that
# - The session route points to this worker
# - In the failover case (see redirect setting for master above)
worker.backup.disabled=1

# Failover worker
worker.failover.type=lb
worker.failover.balanced_workers=master, backup

Once I got a session from the backup worker the session stays on this disabled
worker which is correct and expected. But if the backup server goes into error
state it does not recover from this state as disabled workers are not retried.
This is bad in the case that the disabled worker had been choosen because of
session stickyness. The attached patch fixes this.

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

DO NOT REPLY [Bug 38806] - Disabled workers in mod_jk are not retried once they get in error state

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





--- Additional Comments From [EMAIL PROTECTED]  2006-02-28 13:03 ---
Created an attachment (id=17807)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=17807&action=view)
Patch against 1.2.15


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

DO NOT REPLY [Bug 38806] - Disabled workers in mod_jk are not retried once they get in error state

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


[EMAIL PROTECTED] changed:

   What|Removed |Added

   Keywords||PatchAvailable




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

DO NOT REPLY [Bug 38806] - Disabled workers in mod_jk are not retried once they get in error state

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





--- Additional Comments From [EMAIL PROTECTED]  2006-02-28 13:18 ---
Right, it makes sense to retry the disabled worker also.
Try by changing the 
#define JK_WORKER_IN_ERROR(w) ((w)->in_error_state  && !(w)->is_disabled &&
!(w)->is_busy)
to:
#define JK_WORKER_IN_ERROR(w) ((w)->in_error_state && !(w)->is_busy)

Your patch only addresses the byreq lb methods, while the others should be
treated in the same way.

-- 
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: r381651 - /tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/demos/LoadTest.java

[fhanik]

Author: fhanik
Date: Tue Feb 28 05:17:46 2006
New Revision: 381651

URL: http://svn.apache.org/viewcvs?rev=381651&view=rev
Log:
Fixed measurement, not super accurate, but it gives a hint

Modified:

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

Modified: 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/demos/LoadTest.java
URL: 
http://svn.apache.org/viewcvs/tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/demos/LoadTest.java?rev=381651&r1=381650&r2=381651&view=diff
==
--- 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/demos/LoadTest.java
 (original)
+++ 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/demos/LoadTest.java
 Tue Feb 28 05:17:46 2006
@@ -51,14 +51,39 @@
 static int messageSize = 0;
 
 public static long messagesSent = 0;
-public static long messageSendTime = 0;
+public static long messageStartSendTime = 0;
+public static long messageEndSendTime = 0;
+public static int  threadCount = 0;
+
+public static synchronized void startTest() {
+threadCount++;
+if ( messageStartSendTime == 0 ) messageStartSendTime = 
System.currentTimeMillis();
+}
+
+public static synchronized void endTest() {
+threadCount--;
+if ( messageEndSendTime == 0 && threadCount==0 ) messageEndSendTime = 
System.currentTimeMillis();
+}
+
 
-public static synchronized long addSendStats(long count, long time) {
+public static synchronized long addSendStats(long count) {
 messagesSent+=count;
-messageSendTime+=time;
 return 0l;
 }
 
+private static void printSendStats(long counter, int messageSize) {
+float cnt = (float)counter;
+float size = (float)messageSize;
+float time = (float)(System.currentTimeMillis()-messageStartSendTime) 
/ 1000f;
+log.info("SEND STATS-"+Thread.currentThread().getName()+"*"+
+ "\n\tMessage count:"+counter+
+ "\n\tTotal bytes  :"+(long)(size*cnt)+
+ "\n\tTotal seconds:"+(time)+
+ "\n\tBytes/second :"+(size*cnt/time)+
+ "\n\tMBytes/second:"+(size*cnt/time/1024f/1024f));
+}
+
+
 
 public LoadTest(ManagedChannel channel, 
 boolean send,
@@ -83,8 +108,9 @@
 long counter = 0;
 LoadMessage msg = new LoadMessage();
 int messageSize = LoadTest.messageSize;
-long sendTime = 0;
+
 try {
+startTest();
 while (counter < msgCount) {
 if (channel.getMembers().length == 0 || (!send)) {
 synchronized (mutex) {
@@ -97,12 +123,10 @@
 } else {
 try {
 msg.setMsgNr((int)++counter);
-long start = System.currentTimeMillis();
 if (debug) {
 printArray(msg.getMessage());
 }
 channel.send(null, msg);
-sendTime += (System.currentTimeMillis() - start);
 if ( pause > 0 ) {
 if ( debug) System.out.println("Pausing sender for 
"+pause+" ms.");
 Thread.sleep(pause);
@@ -117,31 +141,22 @@
 }
 if ( (counter % statsInterval) == 0 && (counter > 0)) {
 //add to the global counter
-//counter = sendTime = addSendStats(counter,sendTime);
+counter = addSendStats(counter);
 //print from the global counter
 //printSendStats(LoadTest.messagesSent, 
LoadTest.messageSize, LoadTest.messageSendTime);
-printSendStats(counter, LoadTest.messageSize, sendTime);
+printSendStats(LoadTest.messagesSent, 
LoadTest.messageSize);
 
 }
 
 }
 }catch ( Exception x ) {
 x.printStackTrace();
-printSendStats(counter, messageSize, sendTime);
+printSendStats(LoadTest.messagesSent, LoadTest.messageSize);
 }
+endTest();
 }
 
-private void printSendStats(long counter, int messageSize, long sendTime) {
-float cnt = (float)counter;
-float size = (float)messageSize;
-float time = (float)sendTime / 1000;
-log.info("SEND STATS-"+Thread.currentThread().getName()+"*"+
- "\n\tMessage count:"+counter+
- "\n\tTotal bytes  :"+(long)(size*cnt)+
- "\n\tTotal seconds:"+(time)+
- "\n\tBytes/second :"+(size*cnt/time)+
- "\n\tMBytes/second:"+(size*cnt/time/1024f

Re: New EL - Split Off from Tomcat 6

[Jacob Hookom]

You can't compare a JSR spec to something like commons-logging, plus 
there are people requesting that it's separate for practical use.


Remy Maucherat wrote:


Jacob Hookom wrote:

I would like to suggest splitting EL off as a separate library from 
Tomcat.  The EL-API is expected to rev in it's own specification in 
the future.  It is not have any dependencies on the Servlet API or 
JSP API and can be utilized in the same fashion as the commons-el 
project.



The trend a little earlier was to have all the code for Tomcat 6 in 
one repository, to make it easier to work with. There was no final 
decision, but for sure I would like to not reproduce the 
commons-logging situation (with a fully independent project).


Rémy

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





--
Jacob Hookom  -  Minneapolis

JSF-EG, JSF-RI, EL, Facelets


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

Re: TomCat monitoring

[Peter Rossbach]

Look here

http://tomcat.apache.org/tomcat-5.5-doc/monitoring.html

Peter


Am 24.02.2006 um 19:22 schrieb Michael Gesundheit:


Hi,

  I'm looking for any information concerning TomCat runtime  
monitoring. Resources status, Memory consumption etc.
  I could not find any material about this issue on the official  
web site.


  Any clue?

  Thanks,
  -Michael



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

Re: New EL - Split Off from Tomcat 6

[Remy Maucherat]

Jacob Hookom wrote:
You can't compare a JSR spec to something like commons-logging, plus 
there are people requesting that it's separate for practical use.


I meant commons-el, sorry. Being practical to others is not my problem 
(esp, since it won't change much to them).


Rémy

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

Re: TomCat monitoring

[Filip Hanik - Dev Lists]

take a look at Hyperic

Peter Rossbach wrote:

Look here

http://tomcat.apache.org/tomcat-5.5-doc/monitoring.html

Peter


Am 24.02.2006 um 19:22 schrieb Michael Gesundheit:


Hi,

  I'm looking for any information concerning TomCat runtime 
monitoring. Resources status, Memory consumption etc.
  I could not find any material about this issue on the official web 
site.


  Any clue?

  Thanks,
  -Michael



-
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: TomCat monitoring

[Peter Lin]

jakarta Jmeter also can monitor Tomcat's status page, so that's another
option.

peter lin


On 2/28/06, Peter Rossbach <[EMAIL PROTECTED]> wrote:
>
> Look here
>
> http://tomcat.apache.org/tomcat-5.5-doc/monitoring.html
>
> Peter
>
>
> Am 24.02.2006 um 19:22 schrieb Michael Gesundheit:
>
> > Hi,
> >
> >   I'm looking for any information concerning TomCat runtime
> > monitoring. Resources status, Memory consumption etc.
> >   I could not find any material about this issue on the official
> > web site.
> >
> >   Any clue?
> >
> >   Thanks,
> >   -Michael
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

New build ?

[Remy Maucherat]

Hi,

Because of the critical AJP bugfix found and fixed earlier today, would 
it be possible to plan releasing a new 5.5.16 build soon ?


Sorry for the trouble (once again ...).

Rémy

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

Re: New build ?

[Henri Gomez]

no problem

2006/2/28, Remy Maucherat <[EMAIL PROTECTED]>:
> Hi,
>
> Because of the critical AJP bugfix found and fixed earlier today, would
> it be possible to plan releasing a new 5.5.16 build soon ?
>
> Sorry for the trouble (once again ...).
>
> 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 38806] - Disabled workers in mod_jk are not retried once they get in error state

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





--- Additional Comments From [EMAIL PROTECTED]  2006-02-28 17:05 ---
Ok. I just wasn't sure if adjusting JK_WORKER_IN_ERROR was the right thing to
do, so I limited the change to find_bysession_route. Do we really care about
disabled workers in find_best_byrequests, find_best_bytraffic and
get_most_suitable_worker (here only the one worker case)? I don't think so.

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

Tomcat 6 source organisation

[Remy Maucherat]

Hi,

I think it is time to decide how the source repository is going to be 
organized, with the questions being:
- how many source folders do we need (Costin wanted one, while others 
like Jacob seem to want "modules") ?

- do we continue to use Ant ?
- etc

Any ideas ?

Rémy

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

svn commit: r381687 - in /tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes: ./ demos/ group/ group/interceptors/ io/ mcast/ tcp/

[fhanik]

Author: fhanik
Date: Tue Feb 28 08:14:20 2006
New Revision: 381687

URL: http://svn.apache.org/viewcvs?rev=381687&view=rev
Log:
Added order protocol, created a command line channel creator

Added:

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

tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tcp/ReplicationListener.jbx
Modified:

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

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

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

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

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/GzipInterceptor.java

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

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

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

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

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

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

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

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

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

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

Modified: 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/ChannelMessage.java
URL: 
http://svn.apache.org/viewcvs/tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/ChannelMessage.java?rev=381687&r1=381686&r2=381687&view=diff
==
--- 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/ChannelMessage.java
 (original)
+++ 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/ChannelMessage.java
 Tue Feb 28 08:14:20 2006
@@ -16,6 +16,7 @@
 package org.apache.catalina.tribes;
 
 import java.io.Serializable;
+import org.apache.catalina.tribes.io.XByteBuffer;
 
 /**
  * @author Filip Hanik
@@ -61,11 +62,13 @@
  */
 public byte[] getUniqueId();
 
-public void setMessage(byte[] data);
+public void setMessage(XByteBuffer buf);
 
-public byte[] getMessage();
+public XByteBuffer getMessage();
 
 public int getOptions();
 public void setOptions(int options);
+
+public ChannelMessage clone();
 
 }

Modified: 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/MembershipService.java
URL: 
http://svn.apache.org/viewcvs/tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/MembershipService.java?rev=381687&r1=381686&r2=381687&view=diff
==
--- 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/MembershipService.java
 (original)
+++ 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/MembershipService.java
 Tue Feb 28 08:14:20 2006
@@ -69,6 +69,8 @@
  */
 public boolean hasMembers();
 
+
+public Member getMember(Member mbr);
 /**
  * Returns a list of all the members in the cluster.
  */

Modified: 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/demos/LoadTest.java
URL: 
http://svn.apache.org/viewcvs/tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/demos/LoadTest.java?rev=381687&r1=381686&r2=381687&view=diff
==
--- 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/demos/LoadTest.java
 (original)
+++ 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/demos/LoadTest.java
 Tue Feb 28 08:14:20 2006
@@ -1,3 +1,18 @@
+/*
+ * Copyright 1999,2004-2006 The Apache Software Foundation.
+ * 
+ * Licensed under the Apache License, Version 2.0 (the "License");
+ * you may not use this file except in compliance with the License.
+ 

svn commit: r381688 - /tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/demos/ChannelCreator.java

[fhanik]

Author: fhanik
Date: Tue Feb 28 08:15:14 2006
New Revision: 381688

URL: http://svn.apache.org/viewcvs?rev=381688&view=rev
Log:
Channel creator 

Added:

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

Added: 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/demos/ChannelCreator.java
URL: 
http://svn.apache.org/viewcvs/tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/demos/ChannelCreator.java?rev=381688&view=auto
==
--- 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/demos/ChannelCreator.java
 (added)
+++ 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/demos/ChannelCreator.java
 Tue Feb 28 08:15:14 2006
@@ -0,0 +1,144 @@
+/*
+ * Copyright 1999,2004-2006 The Apache Software Foundation.
+ *
+ * Licensed under the Apache License, Version 2.0 (the "License");
+ * you may not use this file except in compliance with the License.
+ * You may obtain a copy of the License at
+ *
+ *  http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.catalina.tribes.demos;
+
+import org.apache.catalina.tribes.Channel;
+import org.apache.catalina.tribes.tcp.ReplicationListener;
+import org.apache.catalina.tribes.tcp.ReplicationTransmitter;
+import org.apache.catalina.tribes.ManagedChannel;
+import org.apache.catalina.tribes.group.GroupChannel;
+import org.apache.catalina.tribes.mcast.McastService;
+import org.apache.catalina.tribes.group.interceptors.GzipInterceptor;
+
+/**
+ * Title: 
+ *
+ * Description: 
+ *
+ *
+ * Company: 
+ *
+ * @author fhanik
+ * @version 1.0
+ */
+public class ChannelCreator {
+
+public static StringBuffer usage() {
+StringBuffer buf = new StringBuffer();
+buf.append("\n\t\t[-sender pooled|fastasyncqueue]")
+   .append("\n\t\t[-bind tcpbindaddress]")
+   .append("\n\t\t[-tcpselto tcpselectortimeout]") 
+   .append("\n\t\t[-tcpthreads tcpthreadcount]") 
+   .append("\n\t\t[-port tcplistenport]")
+   .append("\n\t\t[-ack true|false]")
+   .append("\n\t\t[-ackto acktimeout]") 
+   .append("\n\t\t[-autoconnect true|false]")
+   .append("\n\t\t[-sync true|false]")
+   .append("\n\t\t[-maddr multicastaddr]")
+   .append("\n\t\t[-mport multicastport]")
+   .append("\n\t\t[-mbind multicastbindaddr]")
+   .append("\n\t\t[-mfreq multicastfrequency]")
+   .append("\n\t\t[-mdrop multicastdroptime]")
+   .append("\n\t\t[-gzip]")
+   ;
+   return buf;
+
+}
+
+public static Channel createChannel(String[] args) {
+String bind = "auto";
+int port = 4001;
+String mbind = null;
+boolean ack = true;
+boolean sync = true;
+boolean gzip = false;
+String sender = "pooled";
+int tcpseltimeout = 100;
+int tcpthreadcount = 4;
+int acktimeout = 15000;
+boolean autoconnect = true;
+String mcastaddr = "228.0.0.5";
+int mcastport = 45565;
+long mcastfreq = 500;
+long mcastdrop = 2000;
+
+for (int i = 0; i < args.length; i++) {
+if ("-bind".equals(args[i])) {
+bind = args[++i];
+} else if ("-sender".equals(args[i])) {
+sender = args[++i];
+} else if ("-port".equals(args[i])) {
+port = Integer.parseInt(args[++i]);
+} else if ("-tcpselto".equals(args[i])) {
+tcpseltimeout = Integer.parseInt(args[++i]);
+} else if ("-tcpthreads".equals(args[i])) {
+tcpthreadcount = Integer.parseInt(args[++i]);
+} else if ("-gzip".equals(args[i])) {
+gzip = true;
+} else if ("-ack".equals(args[i])) {
+ack = Boolean.parseBoolean(args[++i]);
+} else if ("-ackto".equals(args[i])) {
+acktimeout = Integer.parseInt(args[++i]);
+} else if ("-sync".equals(args[i])) {
+sync = Boolean.parseBoolean(args[++i]);
+} else if ("-autoconnect".equals(args[i])) {
+autoconnect = Boolean.parseBoolean(args[++i]);
+} else if ("-maddr".equals(args[i])) {
+mcastaddr = args[++i];
+} else if ("-mport".equals(args[i])) {
+mcastport = Integer.parseInt(args[++i]);
+} else if ("-mfreq".equals(args[i])) {
+mcastfreq = Long.parseLong(args[++i]);
+  

Re: New build ?

[Yoav Shapira]

Are all the fixes for JIRA in?

Yoav

On 2/28/06, Henri Gomez <[EMAIL PROTECTED]> wrote:
> no problem
>
> 2006/2/28, Remy Maucherat <[EMAIL PROTECTED]>:
> > Hi,
> >
> > Because of the critical AJP bugfix found and fixed earlier today, would
> > it be possible to plan releasing a new 5.5.16 build soon ?
> >
> > Sorry for the trouble (once again ...).
> >
> > 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]
>
>


--
Yoav Shapira
Senior Architect
Nimalex LLC
1 Mifflin Place, Suite 310
Cambridge, MA, USA
[EMAIL PROTECTED]

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

Re: Tomcat 6 source organisation

[Yoav Shapira]

Hola,
Ant as opposed to Maven, or to something else?  I like Ant...

Yoav

On 2/28/06, Remy Maucherat <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I think it is time to decide how the source repository is going to be
> organized, with the questions being:
> - how many source folders do we need (Costin wanted one, while others
> like Jacob seem to want "modules") ?
> - do we continue to use Ant ?
> - etc
>
> Any ideas ?
>
> Rémy
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


--
Yoav Shapira
Senior Architect
Nimalex LLC
1 Mifflin Place, Suite 310
Cambridge, MA, USA
[EMAIL PROTECTED]

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

svn commit: r381691 - /tomcat/container/tc5.5.x/webapps/docs/changelog.xml

[remm]

Author: remm
Date: Tue Feb 28 08:25:07 2006
New Revision: 381691

URL: http://svn.apache.org/viewcvs?rev=381691&view=rev
Log:
-Changelog update.

Modified:
tomcat/container/tc5.5.x/webapps/docs/changelog.xml

Modified: tomcat/container/tc5.5.x/webapps/docs/changelog.xml
URL: 
http://svn.apache.org/viewcvs/tomcat/container/tc5.5.x/webapps/docs/changelog.xml?rev=381691&r1=381690&r2=381691&view=diff
==
--- tomcat/container/tc5.5.x/webapps/docs/changelog.xml (original)
+++ tomcat/container/tc5.5.x/webapps/docs/changelog.xml Tue Feb 28 08:25:07 2006
@@ -23,6 +23,9 @@
   
 Required tcnative library version upgraded to 1.1.2 (remm)
   
+  
+Update to Eclipse JDT 3.1.2 (remm)
+  
 
   
   
@@ -80,6 +83,9 @@
 Slightly modify the timing of the manager start, so that it is not 
started by a
 listener (remm)
   
+  
+Refresh loggers used by the digester (remm)
+  
 
   
   
@@ -115,6 +121,10 @@
 38726: Remove duplicate request group field causing blank 
statistics for the
 HTTP connector (remm) 
   
+  
+Fix invalid length used by some AJP packets for the AJP APR connector, 
which could cause 
+corruption, submitted by Rudiger Plum (jim)
+  
 
   
   
@@ -126,6 +136,9 @@
   
 Add some useful hints to jasper-howto. (pero).
   
+  
+38776: Fix source file attribute, submitted by Olivier 
Thomann (remm)
+  
 
   
   



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

Re: Tomcat 6 source organisation

[Remy Maucherat]

Yoav Shapira wrote:

Hola,
Ant as opposed to Maven, or to something else?  I like Ant...


Yes, I meant it as Ant vs Maven 2, indeed.

Rémy

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

Re: Tomcat 6 source organisation

[Costin Manolache]

Why would you want to change ant ???

Re. source folders versus modules - we can have both of them, it's not
exclusive.
Single source tree makes it easy to navigate, more IDE-friendly, etc.
The build file can compile as many modules as needed - either by compiling a
subset of the tree, or by compiling the entire tree and generating
several modules.

IMO it is a bad practice to scatter sources around without very good reason.
JDK sources don't seem to be scattered in modules like 'io', 'net',
but in packages,
and modules for platform-specific stuff.

Having a single source tree would also greatly simplify the ant file,
and with eclipse
it can completely skip the compilation task ( i.e. if the ant file
uses the same build/classes
dir as eclipse, it'll detect the already-compiled classes and just
create the jars, while
eclipse can keep the source updated on save ).

Costin

On 2/28/06, Remy Maucherat <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I think it is time to decide how the source repository is going to be
> organized, with the questions being:
> - how many source folders do we need (Costin wanted one, while others
> like Jacob seem to want "modules") ?
> - do we continue to use Ant ?
> - etc
>
> Any ideas ?
>
> 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: Tomcat 6 source organisation

[Keith Wannamaker]

+1 for consolidating into a single module/src folder.

maven has matured since I last looked.  It seems the biggest advantages 
for us would be dependency management and a common build layout.  I 
don't have a feel for how much work it would take to convert, but it 
doesn't seem like we would loose much if that approach were taken.


Keith


Remy Maucherat wrote:

Hi,

I think it is time to decide how the source repository is going to be 
organized, with the questions being:
- how many source folders do we need (Costin wanted one, while others 
like Jacob seem to want "modules") ?

- do we continue to use Ant ?
- etc

Any ideas ?

Rémy



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

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

[fhanik]

Author: fhanik
Date: Tue Feb 28 08:51:07 2006
New Revision: 381703

URL: http://svn.apache.org/viewcvs?rev=381703&view=rev
Log:
Fixed buffer usage

Modified:

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

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

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/OrderInterceptor.java

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

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

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

Modified: 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/demos/ChannelCreator.java
URL: 
http://svn.apache.org/viewcvs/tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/demos/ChannelCreator.java?rev=381703&r1=381702&r2=381703&view=diff
==
--- 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/demos/ChannelCreator.java
 (original)
+++ 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/demos/ChannelCreator.java
 Tue Feb 28 08:51:07 2006
@@ -22,6 +22,7 @@
 import org.apache.catalina.tribes.group.GroupChannel;
 import org.apache.catalina.tribes.mcast.McastService;
 import org.apache.catalina.tribes.group.interceptors.GzipInterceptor;
+import org.apache.catalina.tribes.group.interceptors.OrderInterceptor;
 
 /**
  * Title: 
@@ -53,6 +54,7 @@
.append("\n\t\t[-mfreq multicastfrequency]")
.append("\n\t\t[-mdrop multicastdroptime]")
.append("\n\t\t[-gzip]")
+   .append("\n\t\t[-order]")
;
return buf;
 
@@ -74,6 +76,7 @@
 int mcastport = 45565;
 long mcastfreq = 500;
 long mcastdrop = 2000;
+boolean order = false;
 
 for (int i = 0; i < args.length; i++) {
 if ("-bind".equals(args[i])) {
@@ -88,6 +91,8 @@
 tcpthreadcount = Integer.parseInt(args[++i]);
 } else if ("-gzip".equals(args[i])) {
 gzip = true;
+} else if ("-order".equals(args[i])) {
+order = true;
 } else if ("-ack".equals(args[i])) {
 ack = Boolean.parseBoolean(args[++i]);
 } else if ("-ackto".equals(args[i])) {
@@ -137,6 +142,7 @@
 channel.setMembershipService(service);
 
 if (gzip) channel.addInterceptor(new GzipInterceptor());
+if (order) channel.addInterceptor(new OrderInterceptor());
 return channel;
 
 }

Modified: 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/demos/LoadTest.java
URL: 
http://svn.apache.org/viewcvs/tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/demos/LoadTest.java?rev=381703&r1=381702&r2=381703&view=diff
==
--- 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/demos/LoadTest.java
 (original)
+++ 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/demos/LoadTest.java
 Tue Feb 28 08:51:07 2006
@@ -121,12 +121,13 @@
 public void run() {
 
 long counter = 0;
+long total = 0;
 LoadMessage msg = new LoadMessage();
 int messageSize = LoadTest.messageSize;
 
 try {
 startTest();
-while (counter < msgCount) {
+while (total < msgCount) {
 if (channel.getMembers().length == 0 || (!send)) {
 synchronized (mutex) {
 try {
@@ -137,7 +138,8 @@
 }
 } else {
 try {
-msg.setMsgNr((int)++counter);
+msg.setMsgNr((int)++total);
+counter++;
 if (debug) {
 printArray(msg.getMessage());
 }
@@ -334,6 +336,7 @@
 threads = Integer.parseInt(args[++i]);
 } else if ("-count".equals(args[i])) {
 count = Integer.parseInt(args[++i]);
+System.out.println("Sending "+count+" messages.");
 } else if ("-pause".equals(args[i])) {
 pause = Long.parseLong(args[++i])*1000;
 } else if ("-break".equals(args[i])) {
@@ -345,7 +348,7 @@
 if ( "receive".equals(args[++i]) ) send = false;
 } else if ("-debug".equals(args[i])) {
   

DO NOT REPLY [Bug 38806] - Disabled workers in mod_jk are not retried once they get in error state

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


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |ASSIGNED




--- Additional Comments From [EMAIL PROTECTED]  2006-02-28 17:57 ---
Right, we don't care about disabled workers for a single worker
cause it's an oxymoron.

Anyhow, adjusting JK_WORKER_IN_ERROR should do the trick.
I really can not remember why I put that check at the first place.

-- 
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: Tomcat 6 source organisation

[Ian Darwin]

Costin Manolache wrote:

Re. source folders versus modules - we can have both of them, it's not
exclusive.
Single source tree makes it easy to navigate, more IDE-friendly, etc.
The build file can compile as many modules as needed - either by compiling a
subset of the tree, or by compiling the entire tree and generating
several modules.

...

Having a single source tree would also greatly simplify the ant file,
and with eclipse
it can completely skip the compilation task ( i.e. if the ant file
uses the same build/classes
dir as eclipse, it'll detect the already-compiled classes and just
create the jars, while
eclipse can keep the source updated on save ).
  

I agree - single top-level directory, everything in place under that,
much easier to build with an IDE, and the benefit Costin mentioned
about saving compile time (since Eclipse by default saves a .class
when you save (and for each imported)  .java file...

Ian

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

DO NOT REPLY [Bug 38810] New: - When using SSL configured in a servlet web application, screens sometimes appear as unreadable characters

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

   Summary: When using SSL configured in a servlet web application,
screens sometimes appear as unreadable characters
   Product: Tomcat 5
   Version: 5.5.14
  Platform: PC
OS/Version: Windows Server 2003
Status: NEW
  Severity: normal
  Priority: P2
 Component: Unknown
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


When using SSL configured in a servlet web application, screens sometimes 
appear as unreadable characters.  The java web application uses servlets and 
GZIPs the output stream if the client supports GZIP.

When a single user makes a lot of concurrent requests that all open new 
windows, some of the screens return as completely unreadable characters.

Partial example:
‹   å=ýSÛH²?‡¿bV[/˜Zð_`®H /ܑ„쥮’TJ–ƶYòI2Äëóÿþº
{>4’5Æ&d÷º,Íôt÷ôô·ÄÑ †ÇkGîúðOd!?>ñ²à.È&ìmfq29jˆûkGCž¹le£-
þÏqp×q„§óâ(ãQÖq¶Zƒè–%<ì8×Ù$äé€óÌaÙdÄ;NÆ¿e
/…Iƒ„÷:\62î]ÏãiZÇ' !õ’`”±4ñ:Îoicœaý7xrÔO懼vCùnbºQìö
¿ºwî5݄…Ö‚ô}
œ½Às³ ŽX‡Eüž$‰;©m¼,=ýÔjîí¾Ø>øòdÌ«žo·^à󞦶
û Ø3 ¬Ý¹  Ò_G>Œˆúù¼?
pïø;àÐU|à¾w‡<-R³&n~j"tç<

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

DO NOT REPLY [Bug 38810] - When using SSL configured in a servlet web application, screens sometimes appear as unreadable characters

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





--- Additional Comments From [EMAIL PROTECTED]  2006-02-28 18:09 ---
Created an attachment (id=17808)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=17808&action=view)
Screen shot of issue


-- 
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: r381713 - in /tomcat/connectors/trunk/jk: native/common/jk_lb_worker.c xdocs/changelog.xml

[mturk]

Author: mturk
Date: Tue Feb 28 09:19:50 2006
New Revision: 381713

URL: http://svn.apache.org/viewcvs?rev=381713&view=rev
Log:
Fix bug 38806 by retrying all workers that are
in error state.

Modified:
tomcat/connectors/trunk/jk/native/common/jk_lb_worker.c
tomcat/connectors/trunk/jk/xdocs/changelog.xml

Modified: tomcat/connectors/trunk/jk/native/common/jk_lb_worker.c
URL: 
http://svn.apache.org/viewcvs/tomcat/connectors/trunk/jk/native/common/jk_lb_worker.c?rev=381713&r1=381712&r2=381713&view=diff
==
--- tomcat/connectors/trunk/jk/native/common/jk_lb_worker.c (original)
+++ tomcat/connectors/trunk/jk/native/common/jk_lb_worker.c Tue Feb 28 09:19:50 
2006
@@ -42,7 +42,7 @@
 /*
  * Time to wait before retry...
  */
-#define JK_WORKER_IN_ERROR(w) ((w)->in_error_state  && !(w)->is_disabled && 
!(w)->is_busy)
+#define JK_WORKER_IN_ERROR(w) ((w)->in_error_state  && !(w)->is_busy)
 #define JK_WORKER_USABLE(w)   (!(w)->in_error_state && !(w)->is_stopped && 
!(w)->is_disabled && !(w)->is_busy)
 
 struct lb_endpoint
@@ -665,7 +665,7 @@
  * on each consequtive attempt.
  */
 if (attempt > (int)p->worker->num_of_workers)
-jk_sleep_def();
+jk_sleep_def();
 continue;
 }
 if (service_stat == JK_FALSE) {

Modified: tomcat/connectors/trunk/jk/xdocs/changelog.xml
URL: 
http://svn.apache.org/viewcvs/tomcat/connectors/trunk/jk/xdocs/changelog.xml?rev=381713&r1=381712&r2=381713&view=diff
==
--- tomcat/connectors/trunk/jk/xdocs/changelog.xml (original)
+++ tomcat/connectors/trunk/jk/xdocs/changelog.xml Tue Feb 28 09:19:50 2006
@@ -26,6 +26,10 @@
   
 
   
+  38806: Reclycle worker even if it is disabled.
+  This fixes hot-standby workers in error state. (mturk)
+  
+  
   ISAPI plugin (isapi_redirect.dll) did not provide correct request data
   for IIS
  to include in the IIS log. (markt)
@@ -100,19 +104,19 @@
   
   Added lock directive for load balancer that allows more acurate
   load balancing in case of burst load. (mturk)
-
+  
   
   Added worker.maintain directive to allow customizing default 10
   second timeout. On busy servers this value needs to be set on
   higher value. (mturk)
-
+  
   
   Fix for NetWare compiler to deal with different types between AP13
   and AP2 SDKs. (fuankg)
   
   
   Emit much more legible user.dmp crash analysis output for WIN32. (wrowe)
-
+  
  
  34558: Fix first failover request. (mturk)
  
@@ -127,12 +131,12 @@
   
   Added ForwardLocallAddres JkOptions flag for passing local instead remote
   address. Useful for remote addr valve. (mturk)
-
+  
  Fix that worker not used, when stopped flag is true. (pero)
  
   
   Add loadbalance default worker secret attribute to the documentation 
(pero)
-
+  
 
   
 
@@ -148,9 +152,9 @@
   
   
   Add worker secret attribute to the documentation (pero)
-
+  
   
-  Add a stopped flag to worker configuration. Set flag True and 
+  Add a stopped flag to worker configuration. Set flag True and
   complete traffic to worker is stopped.
   Also update the Ant JkStatusUpdateTask at Tomcat 5.5.10 release.
   Only usefull in a replicated session cluster.(pero)
@@ -192,7 +196,7 @@
   
   
 Add --enable-prefork to the documentation (pero)
-
+  
 
   
 



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

DO NOT REPLY [Bug 38806] - Disabled workers in mod_jk are not retried once they get in error state

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


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2006-02-28 18:21 ---
Fixed in the SVN.
Thanks for spotting that.

-- 
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: New build ?

[Remy Maucherat]

Yoav Shapira wrote:

Are all the fixes for JIRA in?


Yes, it seems so. Getting production testing for AJP APR and the other 
new components has been good.


Rémy

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

Re: Tomcat 6 source organisation

[Remy Maucherat]

Costin Manolache wrote:

Why would you want to change ant ???


I don't, I am asking questions.


Re. source folders versus modules - we can have both of them, it's not
exclusive.
Single source tree makes it easy to navigate, more IDE-friendly, etc.
The build file can compile as many modules as needed - either by compiling a
subset of the tree, or by compiling the entire tree and generating
several modules.


Yes, I know.


IMO it is a bad practice to scatter sources around without very good reason.
JDK sources don't seem to be scattered in modules like 'io', 'net',
but in packages,
and modules for platform-specific stuff.

Having a single source tree would also greatly simplify the ant file,
and with eclipse
it can completely skip the compilation task ( i.e. if the ant file
uses the same build/classes
dir as eclipse, it'll detect the already-compiled classes and just
create the jars, while
eclipse can keep the source updated on save ).


Obviously, the build script would be far far simpler. Personally, I am 
also in favor of a single source tree, since it's simply much easier to 
work with.


Rémy

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

Re: New build ?

[Yoav Shapira]

OK, then, how does the weekend look for a Tomcat release?  That'll
give everyone a few days to maybe close out some other Bugzilla
issue...

Yoav

On 2/28/06, Remy Maucherat <[EMAIL PROTECTED]> wrote:
> Yoav Shapira wrote:
> > Are all the fixes for JIRA in?
>
> Yes, it seems so. Getting production testing for AJP APR and the other
> new components has been good.
>
> Rémy
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


--
Yoav Shapira
Senior Architect
Nimalex LLC
1 Mifflin Place, Suite 310
Cambridge, MA, USA
[EMAIL PROTECTED]

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

Re: Tomcat 6 source organisation

[Yoav Shapira]

Overall, I'm +1 on Ant (-0.5 on Maven), and +0 to a single source tree
and other consolidations / clarifications / improvements that'll make
it easier to work with Tomcat's source...

Yoav

On 2/28/06, Remy Maucherat <[EMAIL PROTECTED]> wrote:
> Costin Manolache wrote:
> > Why would you want to change ant ???
>
> I don't, I am asking questions.
>
> > Re. source folders versus modules - we can have both of them, it's not
> > exclusive.
> > Single source tree makes it easy to navigate, more IDE-friendly, etc.
> > The build file can compile as many modules as needed - either by compiling a
> > subset of the tree, or by compiling the entire tree and generating
> > several modules.
>
> Yes, I know.
>
> > IMO it is a bad practice to scatter sources around without very good reason.
> > JDK sources don't seem to be scattered in modules like 'io', 'net',
> > but in packages,
> > and modules for platform-specific stuff.
> >
> > Having a single source tree would also greatly simplify the ant file,
> > and with eclipse
> > it can completely skip the compilation task ( i.e. if the ant file
> > uses the same build/classes
> > dir as eclipse, it'll detect the already-compiled classes and just
> > create the jars, while
> > eclipse can keep the source updated on save ).
>
> Obviously, the build script would be far far simpler. Personally, I am
> also in favor of a single source tree, since it's simply much easier to
> work with.
>
> Rémy
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


--
Yoav Shapira
Senior Architect
Nimalex LLC
1 Mifflin Place, Suite 310
Cambridge, MA, USA
[EMAIL PROTECTED]

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

Re: Tomcat 6 source organisation

[Mladen Turk]

Remy Maucherat wrote:

Costin Manolache wrote:


Having a single source tree would also greatly simplify the ant file,


Obviously, the build script would be far far simpler. Personally, I am 
also in favor of a single source tree, since it's simply much easier to 
work with.




I hope this will lead to have the connectors in the same source tree
without the need to go to the separate repository.

Of course, I'm not speaking about mod_jk here :)

Regards,
Mladen.

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

Re: Tomcat 6 source organisation

[Remy Maucherat]

Yoav Shapira wrote:

Overall, I'm +1 on Ant (-0.5 on Maven), and +0 to a single source tree
and other consolidations / clarifications / improvements that'll make
it easier to work with Tomcat's source...


Ok, this sounds good to me.


Yoav Shapira
Senior Architect
Nimalex LLC
1 Mifflin Place, Suite 310
Cambridge, MA, USA
[EMAIL PROTECTED]


I see your signature has changed all of a sudden.

Rémy

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

Re: New build ?

[Remy Maucherat]

Yoav Shapira wrote:

OK, then, how does the weekend look for a Tomcat release?  That'll
give everyone a few days to maybe close out some other Bugzilla
issue...


+1

Rémy

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

Re: Tomcat 6 source organisation

[Costin Manolache]

On 2/28/06, Keith Wannamaker <[EMAIL PROTECTED]> wrote:
> +1 for consolidating into a single module/src folder.
>
> maven has matured since I last looked.  It seems the biggest advantages
> for us would be dependency management and a common build layout.  I
> don't have a feel for how much work it would take to convert, but it
> doesn't seem like we would loose much if that approach were taken.

Well, 'make' is also mature - it doesn't mean we should switch to it -
or to any tool
that happens to 'mature'.

I'm -0.99 on switching to maven. We already have dependency download  and we
can use a more modern version -  I think there are several options
that don't come with a framework attached. As for 'common build
layout' - that's up to us to decide :-)

Costin




>
> Keith
>
>
> Remy Maucherat wrote:
> > Hi,
> >
> > I think it is time to decide how the source repository is going to be
> > organized, with the questions being:
> > - how many source folders do we need (Costin wanted one, while others
> > like Jacob seem to want "modules") ?
> > - do we continue to use Ant ?
> > - etc
> >
> > Any ideas ?
> >
> > 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: New EL - Split Off from Tomcat 6

[Costin Manolache]

The most important question IMO is 'who is going to maintain it'. For
example - AFAIK
 we are the main users and maintainer of modeler, so IMO it would make
sense to move
it back into tomcat source tree.

If EL has a lot of indepenent developers who are not interested in the
rest of tomcat ( so
it doesn't make sense to add them to tomcat project ) - then yes, +1
on splitting it
to a separate sub-project or jakarta-commons.

Until this happens - I think it should be in the same source tree with
everything else.

The fact that it has it's own specification or deps is not an issue -
each component
of tomcat has it's own evolution and might be released independently
or with the bundle.
We made this argument for connector, jasper, container, etc - I don't think it
helped in any way to have each of them as a separate module, and I
don't think it helped
anyone to have modeler in jakarta-commons.

Again - we can release any package we want, and we should start doing that.

Right now we release few packaging variations of jakarta-tomcat - IMO
we should start
releasing things like 'el', modeler, maybe standalone jasper compiler,
maybe standalone connector, cluster module, etc.


Costin

On 2/27/06, Jacob Hookom <[EMAIL PROTECTED]> wrote:
> I would like to suggest splitting EL off as a separate library from
> Tomcat.  The EL-API is expected to rev in it's own specification in the
> future.  It is not have any dependencies on the Servlet API or JSP API
> and can be utilized in the same fashion as the commons-el project.
>
> --
> Jacob Hookom  -  Minneapolis
> 
> JSF-EG, JSF-RI, EL, Facelets
>
>
> -
> 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: Tomcat 6 source organisation

[Peter Rossbach]

We can have maven2 dependency management without use maven2 complete.

see. http://maven.apache.org/ant-tasks.html

I thing maven is good for standard prepare/compile/test, but is heavy  
to use with spezial things like the current tomcat release build. I  
have heard that some "go back to ant" discussion start at the  
jetspeed project.


Peter



Am 28.02.2006 um 17:50 schrieb Keith Wannamaker:


+1 for consolidating into a single module/src folder.

maven has matured since I last looked.  It seems the biggest  
advantages for us would be dependency management and a common build  
layout.  I don't have a feel for how much work it would take to  
convert, but it doesn't seem like we would loose much if that  
approach were taken.


Keith


Remy Maucherat wrote:

Hi,
I think it is time to decide how the source repository is going to  
be organized, with the questions being:
- how many source folders do we need (Costin wanted one, while  
others like Jacob seem to want "modules") ?

- do we continue to use Ant ?
- etc
Any ideas ?
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: New build ?

[Peter Rossbach]

I also check at weekend the current cluster base again my test case.

Peter


Am 28.02.2006 um 18:30 schrieb Yoav Shapira:


OK, then, how does the weekend look for a Tomcat release?  That'll
give everyone a few days to maybe close out some other Bugzilla
issue...

Yoav

On 2/28/06, Remy Maucherat <[EMAIL PROTECTED]> wrote:

Yoav Shapira wrote:

Are all the fixes for JIRA in?


Yes, it seems so. Getting production testing for AJP APR and the  
other

new components has been good.

Rémy

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





--
Yoav Shapira
Senior Architect
Nimalex LLC
1 Mifflin Place, Suite 310
Cambridge, MA, USA
[EMAIL PROTECTED]

-
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: Tomcat 6 source organisation

[Costin Manolache]

On 2/28/06, Peter Rossbach <[EMAIL PROTECTED]> wrote:
> We can have maven2 dependency management without use maven2 complete.
>
> see. http://maven.apache.org/ant-tasks.html

I have no problem with using maven or similar tasks for downloading
the deps, if they
can provide the same functionality with our build hacks, or at least
use them for the simple
cases.

I'm just -1 on using a framework that forces a particular way to do
things ( nothing personal
with maven, same -1 for any other framework :-). I know people have
religious ideas about
right and wrong, and frameworks is an expression of this - I just hope
I won't see this in tomcat...

It may be good to look at what other options exists for download and
pick one that is easy to use and fits well - maven might be the best
or not, that's one benefit of picking components and tools instead of
'they know better' frameworks.

Costin

>
> I thing maven is good for standard prepare/compile/test, but is heavy
> to use with spezial things like the current tomcat release build. I
> have heard that some "go back to ant" discussion start at the
> jetspeed project.
>
> Peter
>
>
>
> Am 28.02.2006 um 17:50 schrieb Keith Wannamaker:
>
> > +1 for consolidating into a single module/src folder.
> >
> > maven has matured since I last looked.  It seems the biggest
> > advantages for us would be dependency management and a common build
> > layout.  I don't have a feel for how much work it would take to
> > convert, but it doesn't seem like we would loose much if that
> > approach were taken.
> >
> > Keith
> >
> >
> > Remy Maucherat wrote:
> >> Hi,
> >> I think it is time to decide how the source repository is going to
> >> be organized, with the questions being:
> >> - how many source folders do we need (Costin wanted one, while
> >> others like Jacob seem to want "modules") ?
> >> - do we continue to use Ant ?
> >> - etc
> >> Any ideas ?
> >> 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]
>
>

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

RE: New EL - Split Off from Tomcat 6

[Bill Barker]

 

> -Original Message-
> From: Costin Manolache [mailto:[EMAIL PROTECTED] 
> Sent: Tuesday, February 28, 2006 9:58 AM
> To: Tomcat Developers List
> Subject: Re: New EL - Split Off from Tomcat 6
> 
> The most important question IMO is 'who is going to maintain it'. For
> example - AFAIK
>  we are the main users and maintainer of modeler, so IMO it would make
> sense to move
> it back into tomcat source tree.
> 

IMHO, 'maintainer' is an over statement ;-).  However, it's probably true
that it would have trouble getting it's 3 +1s for a release in commons
(since even commons-logging can't manage that :).  I'd be +1 to branching it
back into Tomcat.

> If EL has a lot of indepenent developers who are not interested in the
> rest of tomcat ( so
> it doesn't make sense to add them to tomcat project ) - then yes, +1
> on splitting it
> to a separate sub-project or jakarta-commons.
> 

You could try putting a copy of EL in the Jakarta commons-sandbox, and see
if it gets a community.  If it does, than that's probably better for
everyone.  If it doesn't, then there would never be a release of it
independent of Tomcat anyway.

> Until this happens - I think it should be in the same source tree with
> everything else.
> 
> The fact that it has it's own specification or deps is not an issue -
> each component
> of tomcat has it's own evolution and might be released independently
> or with the bundle.
> We made this argument for connector, jasper, container, etc - 
> I don't think it
> helped in any way to have each of them as a separate module, and I
> don't think it helped
> anyone to have modeler in jakarta-commons.
> 
> Again - we can release any package we want, and we should 
> start doing that.
> 
> Right now we release few packaging variations of jakarta-tomcat - IMO
> we should start
> releasing things like 'el', modeler, maybe standalone jasper compiler,
> maybe standalone connector, cluster module, etc.
> 

Well, a couple of projects use Jasper independently of Tomcat.  For the
others, I don't really see the point (and Jasper is a bit under-maintained
at the moment :).
> 
> Costin
> 
> On 2/27/06, Jacob Hookom <[EMAIL PROTECTED]> wrote:
> > I would like to suggest splitting EL off as a separate library from
> > Tomcat.  The EL-API is expected to rev in it's own 
> specification in the
> > future.  It is not have any dependencies on the Servlet API 
> or JSP API
> > and can be utilized in the same fashion as the commons-el project.
> >
> > --
> > Jacob Hookom  -  Minneapolis
> > 
> > JSF-EG, JSF-RI, EL, Facelets
> >
> >
> > 
> -
> > 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]
> 
> 
> 



This message is intended only for the use of the person(s) listed above as the 
intended recipient(s), and may contain information that is PRIVILEGED and 
CONFIDENTIAL.  If you are not an intended recipient, you may not read, copy, or 
distribute this message or any attachment. If you received this communication 
in error, please notify us immediately by e-mail and then delete all copies of 
this message and any attachments.

In addition you should be aware that ordinary (unencrypted) e-mail sent through 
the Internet is not secure. Do not send confidential or sensitive information, 
such as social security numbers, account numbers, personal identification 
numbers and passwords, to us via ordinary (unencrypted) e-mail.


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

svn commit: r381732 - /tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/group/interceptors/OrderInterceptor.java

[fhanik]

Author: fhanik
Date: Tue Feb 28 10:38:31 2006
New Revision: 381732

URL: http://svn.apache.org/viewcvs?rev=381732&view=rev
Log:
finished the order protocol. still to do is to fix the expiration, and add in a 
reset of the counter, when such happens

Modified:

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

Modified: 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/group/interceptors/OrderInterceptor.java
URL: 
http://svn.apache.org/viewcvs/tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/group/interceptors/OrderInterceptor.java?rev=381732&r1=381731&r2=381732&view=diff
==
--- 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/group/interceptors/OrderInterceptor.java
 (original)
+++ 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/group/interceptors/OrderInterceptor.java
 Tue Feb 28 10:38:31 2006
@@ -55,8 +55,8 @@
 processIncoming(order);
 //getPrevious().messageReceived(msg);
 }
-
 public synchronized void processIncoming(MessageOrder order) {
+int val = order.getMsgNr();
 Member member = order.getMessage().getAddress();
 Counter cnt = getInCounter(member);
 
@@ -64,9 +64,14 @@
 if ( tmp != null ) {
 order = MessageOrder.add(tmp,order);
 }
-while ( (order!=null) && (order.getMsgNr() == cnt.getCounter()) ) {
+
+//if ( order.getMsgNr() != cnt.getCounter() ) {
+//System.out.println("Found out of order message.");
+//}
+
+while ( (order!=null) && (order.getMsgNr() <= cnt.getCounter()) ) {
 //we are right on target. process orders
-cnt.inc();
+if ( order.getMsgNr() == cnt.getCounter() ) cnt.inc();
 super.messageReceived(order.getMessage());
 order.setMessage(null);
 order = order.next;
@@ -76,20 +81,22 @@
 tmp = order;
 while ( tmp != null ) {
 //process expired messages
+//TODO, when a message expires, what do we do?
+//just send one?
 if ( tmp.isExpired(expire) ) {
-System.out.println("Found expired message");
 //reset the head
 if ( tmp == head ) head = tmp.next;
 if ( getForwardExpired() ) 
super.messageReceived(tmp.getMessage());
 tmp.setMessage(null);
 tmp = tmp.next;
-if ( prev != null ) prev.next = tmp;
+if ( prev != null ) prev.next = tmp;
 } else {
 prev = tmp;
+tmp = tmp.next;
 }
 }
 if ( head == null ) incoming.remove(member);
-else incoming.put(member,head);
+else incoming.put(member, head);
 }
 
 public void memberAdded(Member member) {
@@ -137,6 +144,10 @@
 return value;
 }
 
+public synchronized void setCounter(int counter) {
+this.value = counter;
+}
+
 public synchronized int inc() {
 return ++value;
 }
@@ -171,16 +182,23 @@
 return next;
 }
 
+public int count() {
+int counter = 1;
+MessageOrder tmp = next;
+while ( tmp != null ) {
+counter++;
+tmp = tmp.next;
+}
+return counter;
+}
+
 public static MessageOrder add(MessageOrder head, MessageOrder add) {
 if ( head == null ) return add;
 if ( add == null ) return head;
 if ( head == add ) return add;
 
 if ( head.getMsgNr() > add.getMsgNr() ) {
-//add before
-MessageOrder tmp = add.next;
 add.next = head;
-head.next = tmp;
 return add;
 }
 
@@ -202,6 +220,7 @@
 } else {
 throw new ArithmeticException("Message added has the same 
counter, synchronization bug. Disable the order interceptor");
 }
+
 return head;
 }
 



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

DO NOT REPLY [Bug 22295] - Catalina is not able to stop on the first time: it just stops on the second

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


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |




--- Additional Comments From [EMAIL PROTECTED]  2006-02-28 19:44 ---
I observed this bug running jakarta-tomcat-5.0.28. I have observed it on 
Windows 2003 Enterprise running with JDK 1.4.1_10. I have also observed it a 
server running Windows XP Professional, Version 2002, Service Pack 2 using the 
JRE that is installed with tomcat. 
These are the only two OS's that I tested.  The bug occurred on 4 out of 4 
servers which I tested. 

The bug is relatively easy to reproduce. Simply start and stop the Apache 
Tomcat service using the Windows Service Control GUI. i.e. Right click on My 
Computer. Select  Manage => Services and Applications => Services.  Set 
the "startup type" to manual. Then start and stop the tomcat service. I always 
wait until the progress indicator show that the service is stopped or started. 
In about 1 out of 10 attempts, the service takes several minutes to stop, as 
indicated by the progress bar. In the other attempts to start or stop, the 
service stops/starts within a few seconds. 

Below is an excerpt from the "stdout.txt" log under ...\Tomcat 5.0\logs

Feb 27, 2006 5:51:39 PM org.apache.catalina.core.StandardHostDeployer install
INFO: Installing web application at context path /tomcat-docs from URL 
file:C:\Program Files\Apache Software Foundation\Tomcat 5.0\webapps\tomcat-docs
Feb 27, 2006 5:51:39 PM org.apache.catalina.core.StandardHostDeployer install
INFO: Installing web application at context path /webdav from URL 
file:C:\Program Files\Apache Software Foundation\Tomcat 5.0\webapps\webdav
Catalina.stop: java.net.ConnectException: Connection refused: connect
java.net.ConnectException: Connection refused: connect
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(Unknown Source)
at java.net.PlainSocketImpl.connectToAddress(Unknown Source)
at java.net.PlainSocketImpl.connect(Unknown Source)
at java.net.SocksSocketImpl.connect(Unknown Source)
at java.net.Socket.connect(Unknown Source)
at java.net.Socket.connect(Unknown Source)
at java.net.Socket.(Unknown Source)
at java.net.Socket.(Unknown Source)
at org.apache.catalina.startup.Catalina.stopServer(Catalina.java:410)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.apache.catalina.startup.Bootstrap.stopServer(Bootstrap.java:336)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:427)


When tomcat fails to stop promptly, Windows service control throws up a 
dialogue box
with the text
===
Services

Could not stop Apache Tomcat service on Local computer.

Error 1053: The service did not respond to the start or control request in a 
timely
fashion


If you have any questions, you may contact me at [EMAIL PROTECTED]



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

DO NOT REPLY [Bug 22295] - Catalina is not able to stop on the first time: it just stops on the second

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





--- Additional Comments From [EMAIL PROTECTED]  2006-02-28 19:47 ---
P.S. Both tests were run just using bare tomcat without any additional classes 
loaded in WEB-INF.

-- 
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: r381740 - /tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/group/interceptors/OrderInterceptor.java

[fhanik]

Author: fhanik
Date: Tue Feb 28 10:47:46 2006
New Revision: 381740

URL: http://svn.apache.org/viewcvs?rev=381740&view=rev
Log:
Completed the order protocol

Modified:

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

Modified: 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/group/interceptors/OrderInterceptor.java
URL: 
http://svn.apache.org/viewcvs/tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/group/interceptors/OrderInterceptor.java?rev=381740&r1=381739&r2=381740&view=diff
==
--- 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/group/interceptors/OrderInterceptor.java
 (original)
+++ 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/group/interceptors/OrderInterceptor.java
 Tue Feb 28 10:47:46 2006
@@ -52,11 +52,25 @@
 int msgnr = 
XByteBuffer.toInt(msg.getMessage().getBytesDirect(),msg.getMessage().getLength()-4);
 msg.getMessage().trim(4);
 MessageOrder order = new MessageOrder(msgnr,msg);
-processIncoming(order);
+if ( processIncoming(order) ) processLeftOvers(msg.getAddress(),false);
 //getPrevious().messageReceived(msg);
 }
-public synchronized void processIncoming(MessageOrder order) {
-int val = order.getMsgNr();
+
+public synchronized void processLeftOvers(Member member, boolean force) {
+MessageOrder tmp = (MessageOrder)incoming.get(member);
+if ( force ) {
+Counter cnt = getInCounter(member);
+cnt.setCounter(Integer.MAX_VALUE);
+}
+if ( tmp!= null ) processIncoming(tmp);
+}
+/**
+ * 
+ * @param order MessageOrder
+ * @return boolean - true if a message expired and was processed
+ */
+public synchronized boolean processIncoming(MessageOrder order) {
+boolean result = false;
 Member member = order.getMessage().getAddress();
 Counter cnt = getInCounter(member);
 
@@ -86,10 +100,12 @@
 if ( tmp.isExpired(expire) ) {
 //reset the head
 if ( tmp == head ) head = tmp.next;
+cnt.setCounter(tmp.getMsgNr()+1);
 if ( getForwardExpired() ) 
super.messageReceived(tmp.getMessage());
 tmp.setMessage(null);
 tmp = tmp.next;
-if ( prev != null ) prev.next = tmp;
+if ( prev != null ) prev.next = tmp;  
+result = true;
 } else {
 prev = tmp;
 tmp = tmp.next;
@@ -97,6 +113,7 @@
 }
 if ( head == null ) incoming.remove(member);
 else incoming.put(member, head);
+return result;
 }
 
 public void memberAdded(Member member) {
@@ -110,6 +127,8 @@
 //notify upwards
 outcounter.remove(member);
 incounter.remove(member);
+//clear the remaining queue
+processLeftOvers(member,true);
 super.memberDisappeared(member);
 }
 



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

RE: Tomcat 6 source organisation

[Bill Barker]

 

> -Original Message-
> From: Costin Manolache [mailto:[EMAIL PROTECTED] 
> Sent: Tuesday, February 28, 2006 10:24 AM
> To: Tomcat Developers List
> Subject: Re: Tomcat 6 source organisation
> 
> On 2/28/06, Peter Rossbach <[EMAIL PROTECTED]> wrote:
> > We can have maven2 dependency management without use maven2 
> complete.
> >
> > see. http://maven.apache.org/ant-tasks.html
> 

We've had some problems with the  tasks over in Gump-land.

> I have no problem with using maven or similar tasks for downloading
> the deps, if they
> can provide the same functionality with our build hacks, or at least
> use them for the simple
> cases.
> 

I'm not sure that Maven could handle the current tomcat-dbcp task well, and
I don't really see a use-case for a mixed dependency management system
myself.

> I'm just -1 on using a framework that forces a particular way to do
> things ( nothing personal
> with maven, same -1 for any other framework :-). I know people have
> religious ideas about
> right and wrong, and frameworks is an expression of this - I just hope
> I won't see this in tomcat...
> 

Also my personal opinion.  Also, Gump doesn't currently support Maven2, so
we'd loose Gump by going to Maven2 (which, some people might think is
a-good-thing :).

> It may be good to look at what other options exists for download and
> pick one that is easy to use and fits well - maven might be the best
> or not, that's one benefit of picking components and tools instead of
> 'they know better' frameworks.
> 
> Costin
> 
> >
> > I thing maven is good for standard prepare/compile/test, 
> but is heavy
> > to use with spezial things like the current tomcat release build. I
> > have heard that some "go back to ant" discussion start at the
> > jetspeed project.
> >
> > Peter
> >
> >
> >
> > Am 28.02.2006 um 17:50 schrieb Keith Wannamaker:
> >
> > > +1 for consolidating into a single module/src folder.
> > >
> > > maven has matured since I last looked.  It seems the biggest
> > > advantages for us would be dependency management and a 
> common build
> > > layout.  I don't have a feel for how much work it would take to
> > > convert, but it doesn't seem like we would loose much if that
> > > approach were taken.
> > >
> > > Keith
> > >
> > >
> > > Remy Maucherat wrote:
> > >> Hi,
> > >> I think it is time to decide how the source repository 
> is going to
> > >> be organized, with the questions being:
> > >> - how many source folders do we need (Costin wanted one, while
> > >> others like Jacob seem to want "modules") ?
> > >> - do we continue to use Ant ?
> > >> - etc
> > >> Any ideas ?
> > >> 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]
> >
> >
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> 



This message is intended only for the use of the person(s) listed above as the 
intended recipient(s), and may contain information that is PRIVILEGED and 
CONFIDENTIAL.  If you are not an intended recipient, you may not read, copy, or 
distribute this message or any attachment. If you received this communication 
in error, please notify us immediately by e-mail and then delete all copies of 
this message and any attachments.

In addition you should be aware that ordinary (unencrypted) e-mail sent through 
the Internet is not secure. Do not send confidential or sensitive information, 
such as social security numbers, account numbers, personal identification 
numbers and passwords, to us via ordinary (unencrypted) e-mail.


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

DO NOT REPLY [Bug 38804] - context path auto detecting problem

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


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID




--- Additional Comments From [EMAIL PROTECTED]  2006-02-28 19:57 ---
Bugzilla is not a support forum. This is a question for the users list.

-- 
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: Tomcat 6 source organisation

[Peter Rossbach]

Yes!

I also thing we don't use maven2.

+1 to use ant

Peter


Am 28.02.2006 um 19:49 schrieb Bill Barker:





-Original Message-
From: Costin Manolache [mailto:[EMAIL PROTECTED]
Sent: Tuesday, February 28, 2006 10:24 AM
To: Tomcat Developers List
Subject: Re: Tomcat 6 source organisation

On 2/28/06, Peter Rossbach <[EMAIL PROTECTED]> wrote:

We can have maven2 dependency management without use maven2

complete.


see. http://maven.apache.org/ant-tasks.html




We've had some problems with the  tasks over in Gump-land.


I have no problem with using maven or similar tasks for downloading
the deps, if they
can provide the same functionality with our build hacks, or at least
use them for the simple
cases.



I'm not sure that Maven could handle the current tomcat-dbcp task  
well, and

I don't really see a use-case for a mixed dependency management system
myself.


I'm just -1 on using a framework that forces a particular way to do
things ( nothing personal
with maven, same -1 for any other framework :-). I know people have
religious ideas about
right and wrong, and frameworks is an expression of this - I just  
hope

I won't see this in tomcat...



Also my personal opinion.  Also, Gump doesn't currently support  
Maven2, so

we'd loose Gump by going to Maven2 (which, some people might think is
a-good-thing :).


It may be good to look at what other options exists for download and
pick one that is easy to use and fits well - maven might be the best
or not, that's one benefit of picking components and tools instead of
'they know better' frameworks.

Costin



I thing maven is good for standard prepare/compile/test,

but is heavy

to use with spezial things like the current tomcat release build. I
have heard that some "go back to ant" discussion start at the
jetspeed project.

Peter



Am 28.02.2006 um 17:50 schrieb Keith Wannamaker:


+1 for consolidating into a single module/src folder.

maven has matured since I last looked.  It seems the biggest
advantages for us would be dependency management and a

common build

layout.  I don't have a feel for how much work it would take to
convert, but it doesn't seem like we would loose much if that
approach were taken.

Keith


Remy Maucherat wrote:

Hi,
I think it is time to decide how the source repository

is going to

be organized, with the questions being:
- how many source folders do we need (Costin wanted one, while
others like Jacob seem to want "modules") ?
- do we continue to use Ant ?
- etc
Any ideas ?
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]




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







This message is intended only for the use of the person(s) listed  
above as the intended recipient(s), and may contain information  
that is PRIVILEGED and CONFIDENTIAL.  If you are not an intended  
recipient, you may not read, copy, or distribute this message or  
any attachment. If you received this communication in error, please  
notify us immediately by e-mail and then delete all copies of this  
message and any attachments.


In addition you should be aware that ordinary (unencrypted) e-mail  
sent through the Internet is not secure. Do not send confidential  
or sensitive information, such as social security numbers, account  
numbers, personal identification numbers and passwords, to us via  
ordinary (unencrypted) e-mail.



-
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: r381747 - in /tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes: demos/ChannelCreator.java group/interceptors/OrderInterceptor.java

[fhanik]

Author: fhanik
Date: Tue Feb 28 11:14:54 2006
New Revision: 381747

URL: http://svn.apache.org/viewcvs?rev=381747&view=rev
Log:
Documented the OrderInterceptor that guarantees ordering for messages sent and 
received.

Modified:

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

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

Modified: 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/demos/ChannelCreator.java
URL: 
http://svn.apache.org/viewcvs/tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/demos/ChannelCreator.java?rev=381747&r1=381746&r2=381747&view=diff
==
--- 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/demos/ChannelCreator.java
 (original)
+++ 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/demos/ChannelCreator.java
 Tue Feb 28 11:14:54 2006
@@ -55,7 +55,7 @@
.append("\n\t\t[-mdrop multicastdroptime]")
.append("\n\t\t[-gzip]")
.append("\n\t\t[-order]")
-   ;
+   .append("\n\t\t[-ordersize maxorderqueuesize]");
return buf;
 
 }
@@ -77,6 +77,7 @@
 long mcastfreq = 500;
 long mcastdrop = 2000;
 boolean order = false;
+int ordersize = Integer.MAX_VALUE;
 
 for (int i = 0; i < args.length; i++) {
 if ("-bind".equals(args[i])) {
@@ -93,6 +94,9 @@
 gzip = true;
 } else if ("-order".equals(args[i])) {
 order = true;
+} else if ("-ordersize".equals(args[i])) {
+ordersize = Integer.parseInt(args[++i]);
+System.out.println("Setting 
OrderInterceptor.maxQueue="+ordersize);
 } else if ("-ack".equals(args[i])) {
 ack = Boolean.parseBoolean(args[++i]);
 } else if ("-ackto".equals(args[i])) {
@@ -142,7 +146,11 @@
 channel.setMembershipService(service);
 
 if (gzip) channel.addInterceptor(new GzipInterceptor());
-if (order) channel.addInterceptor(new OrderInterceptor());
+if (order) {
+OrderInterceptor oi = new OrderInterceptor();
+oi.setMaxQueue(ordersize);
+channel.addInterceptor(oi);
+}
 return channel;
 
 }

Modified: 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/group/interceptors/OrderInterceptor.java
URL: 
http://svn.apache.org/viewcvs/tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/group/interceptors/OrderInterceptor.java?rev=381747&r1=381746&r2=381747&view=diff
==
--- 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/group/interceptors/OrderInterceptor.java
 (original)
+++ 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/group/interceptors/OrderInterceptor.java
 Tue Feb 28 11:14:54 2006
@@ -28,6 +28,24 @@
 
 /**
  *
+ * The order interceptor guarantees that messages are received in the same 
order they were 
+ * sent.
+ * This interceptor works best with the ack=true setting. 
+ * There is no point in 
+ * using this with the replicationMode="fastasynchqueue" as this mode 
guarantees ordering.
+ * If you are using the mode ack=false replicationMode=pooled, and have a lot 
of concurrent threads,
+ * this interceptor can really slow you down, as many messages will be 
completely out of order
+ * and the queue might become rather large. If this is the case, then you 
might want to set 
+ * the value OrderInterceptor.maxQueue = 25 (meaning that we will never keep 
more than 25 messages in our queue)
+ * Configuration Options
+ * OrderInteceptor.expire= - if a message arrives out of order, 
how long before we act on it default=3000ms
+ * OrderInteceptor.maxQueue= - how much can the queue grow to 
ensure ordering. 
+ *   This setting is useful to avoid 
OutOfMemoryErrorsdefault=Integer.MAX_VALUE
+ * OrderInterceptor.forwardExpired= - this flag tells the interceptor 
what to 
+ * do when a message has expired or the queue has grown larger than the 
maxQueue value.
+ * true means that the message is sent up the stack to the receiver that will 
receive and out of order message
+ * false means, forget the message and reset the message counter. 
default=true
+ * 
  * 
  * @author Filip Hanik
  * @version 1.0
@@ -38,6 +56,7 @@
 private HashMap incoming = new HashMap();
 private long expire = 3000;
 private boolean forwardExpired = true;
+private int maxQueue = Integer.MAX_VALUE;
 
 public void sendMessage(Member[] destination, ChannelMessage msg, 
InterceptorPayload payload) throws ChannelException {
 for ( int i=0; i

Re: Tomcat 6 source organisation

[Filip Hanik - Dev Lists]

+1 on the easier source tree

+0 on maven.

Since I personally don't know Maven, I would want to say no to that. 
Cause if someone says Maven 2 rocks, then I would be happy to learn it 
and use it here. But I couldn't provide much help integrating it.


Filip


Peter Rossbach wrote:

Yes!

I also thing we don't use maven2.

+1 to use ant

Peter


Am 28.02.2006 um 19:49 schrieb Bill Barker:





-Original Message-
From: Costin Manolache [mailto:[EMAIL PROTECTED]
Sent: Tuesday, February 28, 2006 10:24 AM
To: Tomcat Developers List
Subject: Re: Tomcat 6 source organisation

On 2/28/06, Peter Rossbach <[EMAIL PROTECTED]> wrote:

We can have maven2 dependency management without use maven2

complete.


see. http://maven.apache.org/ant-tasks.html




We've had some problems with the  tasks over in Gump-land.


I have no problem with using maven or similar tasks for downloading
the deps, if they
can provide the same functionality with our build hacks, or at least
use them for the simple
cases.



I'm not sure that Maven could handle the current tomcat-dbcp task 
well, and

I don't really see a use-case for a mixed dependency management system
myself.


I'm just -1 on using a framework that forces a particular way to do
things ( nothing personal
with maven, same -1 for any other framework :-). I know people have
religious ideas about
right and wrong, and frameworks is an expression of this - I just hope
I won't see this in tomcat...



Also my personal opinion.  Also, Gump doesn't currently support 
Maven2, so

we'd loose Gump by going to Maven2 (which, some people might think is
a-good-thing :).


It may be good to look at what other options exists for download and
pick one that is easy to use and fits well - maven might be the best
or not, that's one benefit of picking components and tools instead of
'they know better' frameworks.

Costin



I thing maven is good for standard prepare/compile/test,

but is heavy

to use with spezial things like the current tomcat release build. I
have heard that some "go back to ant" discussion start at the
jetspeed project.

Peter



Am 28.02.2006 um 17:50 schrieb Keith Wannamaker:


+1 for consolidating into a single module/src folder.

maven has matured since I last looked.  It seems the biggest
advantages for us would be dependency management and a

common build

layout.  I don't have a feel for how much work it would take to
convert, but it doesn't seem like we would loose much if that
approach were taken.

Keith


Remy Maucherat wrote:

Hi,
I think it is time to decide how the source repository

is going to

be organized, with the questions being:
- how many source folders do we need (Costin wanted one, while
others like Jacob seem to want "modules") ?
- do we continue to use Ant ?
- etc
Any ideas ?
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]




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







This message is intended only for the use of the person(s) listed 
above as the intended recipient(s), and may contain information that 
is PRIVILEGED and CONFIDENTIAL.  If you are not an intended 
recipient, you may not read, copy, or distribute this message or any 
attachment. If you received this communication in error, please 
notify us immediately by e-mail and then delete all copies of this 
message and any attachments.


In addition you should be aware that ordinary (unencrypted) e-mail 
sent through the Internet is not secure. Do not send confidential or 
sensitive information, such as social security numbers, account 
numbers, personal identification numbers and passwords, to us via 
ordinary (unencrypted) e-mail.



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





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

Re: Tomcat 6 source organisation

[Mark Thomas]

Remy Maucherat wrote:
> Hi,
> 
> I think it is time to decide how the source repository is going to be
> organized, with the questions being:
> - how many source folders do we need (Costin wanted one, while others
> like Jacob seem to want "modules") ?
> - do we continue to use Ant ?
> - etc

I am +0 on any changes.

Assuming some changes are made, there needs to be some thought given
to where in the source tree we put the trunk/branch/tag structure
before we start moving things around.

There have also been various comments made that different components
may be released on different release cycles. If this route is
followed, there needs to be a reasonably clear idea of what these
components might be as this will also have an impact on the best way
to structure the source.

Mark


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

Re: Tomcat 6 source organisation

[Costin Manolache]

On 2/28/06, Mark Thomas <[EMAIL PROTECTED]> wrote:
> Remy Maucherat wrote:
> > Hi,
> >
> > I think it is time to decide how the source repository is going to be
> > organized, with the questions being:
> > - how many source folders do we need (Costin wanted one, while others
> > like Jacob seem to want "modules") ?
> > - do we continue to use Ant ?
> > - etc
>
> I am +0 on any changes.
>
> Assuming some changes are made, there needs to be some thought given
> to where in the source tree we put the trunk/branch/tag structure
> before we start moving things around.


Well, single source tree means all source will be in one svn repo.

My understanding is that you can label/tag/branch subdirs - and that a
tag is cheap enough that you can do it for the entire tree.

I think it's better to tag the entire tree - not just the component,
so it's easier to reproduce ( since it has deps, etc ). That seems the
current practice.






> There have also been various comments made that different components
> may be released on different release cycles. If this route is
> followed, there needs to be a reasonably clear idea of what these
> components might be as this will also have an impact on the best way
> to structure the source.
>

I don't think the source structure should be related to release structure.

>From one source tree you can generate as many jars and packages as you
want, in any structure or variation.

Things like 'el' or 'jspc' or maybe cluster could chose to release -
either as a jar, or as a .tar.gz or anything else. Or maybe not - that
should be an independent decision from source tree layout or build
mechanism.

Costin

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

Re: New EL - Split Off from Tomcat 6

[Costin Manolache]

On 2/28/06, Bill Barker <[EMAIL PROTECTED]> wrote:
>
>
> > -Original Message-
> > From: Costin Manolache [mailto:[EMAIL PROTECTED]
> > Sent: Tuesday, February 28, 2006 9:58 AM
> > To: Tomcat Developers List
> > Subject: Re: New EL - Split Off from Tomcat 6
> >
> > The most important question IMO is 'who is going to maintain it'. For
> > example - AFAIK
> >  we are the main users and maintainer of modeler, so IMO it would make
> > sense to move
> > it back into tomcat source tree.
> >
>
> IMHO, 'maintainer' is an over statement ;-).  However, it's probably true
> that it would have trouble getting it's 3 +1s for a release in commons
> (since even commons-logging can't manage that :).  I'd be +1 to branching it
> back into Tomcat.

That's what I meant :-)


>
> > If EL has a lot of indepenent developers who are not interested in the
> > rest of tomcat ( so
> > it doesn't make sense to add them to tomcat project ) - then yes, +1
> > on splitting it
> > to a separate sub-project or jakarta-commons.
> >
>
> You could try putting a copy of EL in the Jakarta commons-sandbox, and see
> if it gets a community.  If it does, than that's probably better for
> everyone.  If it doesn't, then there would never be a release of it
> independent of Tomcat anyway.

+1 - as long as developement continues in tomcat ( i.e. the branch
that can be released )

>
> > Right now we release few packaging variations of jakarta-tomcat - IMO
> > we should start
> > releasing things like 'el', modeler, maybe standalone jasper compiler,
> > maybe standalone connector, cluster module, etc.
> >
>
> Well, a couple of projects use Jasper independently of Tomcat.  For the
> others, I don't really see the point (and Jasper is a bit under-maintained
> at the moment :).

The point for cluster and other add-on style modules would be to
reduce the size and complexity of tomcat releases, i.e. simpler is
better :-)  IMO jk could also be a separate module - i.e. have the
base tomcat only include the basic http connector, if someone is using
apache he could get the extra module.

Having independent releases of jasper / el / jspc might help if they
can be used in other projects, or if they need a more frequent release
cycle ( bug fixes, etc )

I'm just suggesting options - I'm not saying we should do it now, but
think about it for future, when it makes sense.

Costin

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

Re: Tomcat 6 source organisation

[Filip Hanik - Dev Lists]

I would prefer to keep the module source tree separate.
For example, the "ha" module (cluster2) uses the same classes as the 
"cluster", but they are being enhanced for performance and modularity.

merging all this into one tree would be a pain in the neck.

Filip


Costin Manolache wrote:

On 2/28/06, Mark Thomas <[EMAIL PROTECTED]> wrote:
  

Remy Maucherat wrote:


Hi,

I think it is time to decide how the source repository is going to be
organized, with the questions being:
- how many source folders do we need (Costin wanted one, while others
like Jacob seem to want "modules") ?
- do we continue to use Ant ?
- etc
  

I am +0 on any changes.

Assuming some changes are made, there needs to be some thought given
to where in the source tree we put the trunk/branch/tag structure
before we start moving things around.




Well, single source tree means all source will be in one svn repo.

My understanding is that you can label/tag/branch subdirs - and that a
tag is cheap enough that you can do it for the entire tree.

I think it's better to tag the entire tree - not just the component,
so it's easier to reproduce ( since it has deps, etc ). That seems the
current practice.






  

There have also been various comments made that different components
may be released on different release cycles. If this route is
followed, there needs to be a reasonably clear idea of what these
components might be as this will also have an impact on the best way
to structure the source.




I don't think the source structure should be related to release structure.

>From one source tree you can generate as many jars and packages as you
want, in any structure or variation.

Things like 'el' or 'jspc' or maybe cluster could chose to release -
either as a jar, or as a .tar.gz or anything else. Or maybe not - that
should be an independent decision from source tree layout or build
mechanism.

Costin

-
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: r381798 - in /tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes: ChannelInterceptor.java ChannelSender.java demos/ChannelCreator.java group/interceptors/Fragme

[fhanik]

Author: fhanik
Date: Tue Feb 28 14:26:50 2006
New Revision: 381798

URL: http://svn.apache.org/viewcvs?rev=381798&view=rev
Log:
Completed the fragmentation interceptor

Modified:

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

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

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

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

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

Modified: 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/ChannelInterceptor.java
URL: 
http://svn.apache.org/viewcvs/tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/ChannelInterceptor.java?rev=381798&r1=381797&r2=381798&view=diff
==
--- 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/ChannelInterceptor.java
 (original)
+++ 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/ChannelInterceptor.java
 Tue Feb 28 14:26:50 2006
@@ -26,7 +26,7 @@
  * Abstract class for the interceptor base class.
  * @author Filip Hanik
  * @version $Revision: 304032 $, $Date: 2005-07-27 10:11:55 -0500 (Wed, 27 Jul 
2005) $
- */
+ */   
 
 public interface ChannelInterceptor extends MembershipListener {
 

Modified: 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/ChannelSender.java
URL: 
http://svn.apache.org/viewcvs/tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/ChannelSender.java?rev=381798&r1=381797&r2=381798&view=diff
==
--- 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/ChannelSender.java
 (original)
+++ 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/ChannelSender.java
 Tue Feb 28 14:26:50 2006
@@ -22,7 +22,7 @@
  * @author Filip Hanik
  * @version $Revision: 303950 $, $Date: 2005-06-09 15:38:30 -0500 (Thu, 09 Jun 
2005) $
  *
- */
+ */
 public interface ChannelSender
 {
 

Modified: 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/demos/ChannelCreator.java
URL: 
http://svn.apache.org/viewcvs/tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/demos/ChannelCreator.java?rev=381798&r1=381797&r2=381798&view=diff
==
--- 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/demos/ChannelCreator.java
 (original)
+++ 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/demos/ChannelCreator.java
 Tue Feb 28 14:26:50 2006
@@ -23,6 +23,7 @@
 import org.apache.catalina.tribes.mcast.McastService;
 import org.apache.catalina.tribes.group.interceptors.GzipInterceptor;
 import org.apache.catalina.tribes.group.interceptors.OrderInterceptor;
+import org.apache.catalina.tribes.group.interceptors.FragmentationInterceptor;
 
 /**
  * Title: 
@@ -55,7 +56,9 @@
.append("\n\t\t[-mdrop multicastdroptime]")
.append("\n\t\t[-gzip]")
.append("\n\t\t[-order]")
-   .append("\n\t\t[-ordersize maxorderqueuesize]");
+   .append("\n\t\t[-ordersize maxorderqueuesize]")
+   .append("\n\t\t[-frag]")
+   .append("\n\t\t[-fragsize maxmsgsize]");
return buf;
 
 }
@@ -78,6 +81,8 @@
 long mcastdrop = 2000;
 boolean order = false;
 int ordersize = Integer.MAX_VALUE;
+boolean frag = false;
+int fragsize = 1024;
 
 for (int i = 0; i < args.length; i++) {
 if ("-bind".equals(args[i])) {
@@ -97,6 +102,11 @@
 } else if ("-ordersize".equals(args[i])) {
 ordersize = Integer.parseInt(args[++i]);
 System.out.println("Setting 
OrderInterceptor.maxQueue="+ordersize);
+} else if ("-frag".equals(args[i])) {
+frag = true;
+} else if ("-fragsize".equals(args[i])) {
+fragsize = Integer.parseInt(args[++i]);
+System.out.println("Setting 
FragmentationInterceptor.maxSize="+fragsize);
 } else if ("-ack".equals(args[i])) {
 ack = Boolean.parseBoolean(args[++i]);
 } else if ("-ackto".equals(args[i])) {
@@ -146,6 +156,11 @@
 channel.setMembershipService(service);
 
 if (gzip) channel.addInterceptor(new GzipInterceptor());
+if ( frag ) {
+FragmentationInterceptor fi = new FragmentationInterceptor();
+fi.setMaxSize(fragsize);
+

Re: Tomcat 6 source organisation

[Costin Manolache]

Of course, this is a case where you need a separate module.

IMHO it is a bad sign when you have to do this - maybe you could use a
different
package name instead of same class names, or refactor a bit so you don't depend
on the class name.
But if for any reason you have to use the same classname, then use a
different module for
that code. JDK does this for platform-specific things in IO, awt, etc.

I think this should be the exception, not the rule.

Costin

On 2/28/06, Filip Hanik - Dev Lists <[EMAIL PROTECTED]> wrote:
> I would prefer to keep the module source tree separate.
> For example, the "ha" module (cluster2) uses the same classes as the
> "cluster", but they are being enhanced for performance and modularity.
> merging all this into one tree would be a pain in the neck.
>
> Filip
>
>
> Costin Manolache wrote:
> > On 2/28/06, Mark Thomas <[EMAIL PROTECTED]> wrote:
> >
> >> Remy Maucherat wrote:
> >>
> >>> Hi,
> >>>
> >>> I think it is time to decide how the source repository is going to be
> >>> organized, with the questions being:
> >>> - how many source folders do we need (Costin wanted one, while others
> >>> like Jacob seem to want "modules") ?
> >>> - do we continue to use Ant ?
> >>> - etc
> >>>
> >> I am +0 on any changes.
> >>
> >> Assuming some changes are made, there needs to be some thought given
> >> to where in the source tree we put the trunk/branch/tag structure
> >> before we start moving things around.
> >>
> >
> >
> > Well, single source tree means all source will be in one svn repo.
> >
> > My understanding is that you can label/tag/branch subdirs - and that a
> > tag is cheap enough that you can do it for the entire tree.
> >
> > I think it's better to tag the entire tree - not just the component,
> > so it's easier to reproduce ( since it has deps, etc ). That seems the
> > current practice.
> >
> >
> >
> >
> >
> >
> >
> >> There have also been various comments made that different components
> >> may be released on different release cycles. If this route is
> >> followed, there needs to be a reasonably clear idea of what these
> >> components might be as this will also have an impact on the best way
> >> to structure the source.
> >>
> >>
> >
> > I don't think the source structure should be related to release structure.
> >
> > >From one source tree you can generate as many jars and packages as you
> > want, in any structure or variation.
> >
> > Things like 'el' or 'jspc' or maybe cluster could chose to release -
> > either as a jar, or as a .tar.gz or anything else. Or maybe not - that
> > should be an independent decision from source tree layout or build
> > mechanism.
> >
> > Costin
> >
> > -
> > 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]
>
>

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

Re: Tomcat 6 source organisation

[Remy Maucherat]

Costin Manolache wrote:

Of course, this is a case where you need a separate module.

IMHO it is a bad sign when you have to do this - maybe you could use a
different
package name instead of same class names, or refactor a bit so you don't depend
on the class name.
But if for any reason you have to use the same classname, then use a
different module for
that code. JDK does this for platform-specific things in IO, awt, etc.

I think this should be the exception, not the rule.


Right, I favor using different package names too in this sort of situation.

Rémy

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

Re: Tomcat 6 source organisation

[Filip Hanik - Dev Lists]

good idea, I will refactor that.

Filip

Remy Maucherat wrote:

Costin Manolache wrote:

Of course, this is a case where you need a separate module.

IMHO it is a bad sign when you have to do this - maybe you could use a
different
package name instead of same class names, or refactor a bit so you 
don't depend

on the class name.
But if for any reason you have to use the same classname, then use a
different module for
that code. JDK does this for platform-specific things in IO, awt, etc.

I think this should be the exception, not the rule.


Right, I favor using different package names too in this sort of 
situation.


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: New build ?

[Jean-frederic Clere]

Remy Maucherat wrote:


Hi,

Because of the critical AJP bugfix found and fixed earlier today, 
would it be possible to plan releasing a new 5.5.16 build soon ?


+1... I have something not working when deploying an application with 
the 5.5.15 and using trunk helps ;-)


Cheers

Jean-Frederic



Sorry for the trouble (once again ...).

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: Tomcat 6 source organisation

[Remy Maucherat]

Mark Thomas wrote:

Remy Maucherat wrote:

Hi,

I think it is time to decide how the source repository is going to be
organized, with the questions being:
- how many source folders do we need (Costin wanted one, while others
like Jacob seem to want "modules") ?
- do we continue to use Ant ?
- etc


I am +0 on any changes.

Assuming some changes are made, there needs to be some thought given
to where in the source tree we put the trunk/branch/tag structure
before we start moving things around.

There have also been various comments made that different components
may be released on different release cycles. If this route is
followed, there needs to be a reasonably clear idea of what these
components might be as this will also have an impact on the best way
to structure the source.


At this point, I don't think there's a big need to decide on these 
components. From what I understand, the general opinion is to have a 
"src" folder containing all the source, with a target that builds 
everything, and then have subtargets for packaging individual components.


Rémy

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

svn commit: r381827 - in /tomcat/container/tc5.5.x/modules/groupcom: src/share/org/apache/catalina/tribes/group/interceptors/FragmentationInterceptor.java to-do.txt

[fhanik]

Author: fhanik
Date: Tue Feb 28 15:31:26 2006
New Revision: 381827

URL: http://svn.apache.org/viewcvs?rev=381827&view=rev
Log:
Cleaned up synchronization for the frag interceptor, only need to synchronize 
on write to the map, not read.


Modified:

tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/group/interceptors/FragmentationInterceptor.java
tomcat/container/tc5.5.x/modules/groupcom/to-do.txt

Modified: 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/group/interceptors/FragmentationInterceptor.java
URL: 
http://svn.apache.org/viewcvs/tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/group/interceptors/FragmentationInterceptor.java?rev=381827&r1=381826&r2=381827&view=diff
==
--- 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/group/interceptors/FragmentationInterceptor.java
 (original)
+++ 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/group/interceptors/FragmentationInterceptor.java
 Tue Feb 28 15:31:26 2006
@@ -24,6 +24,9 @@
 import org.apache.catalina.tribes.Member;
 import org.apache.catalina.tribes.group.ChannelInterceptorBase;
 import org.apache.catalina.tribes.io.XByteBuffer;
+import java.util.Collection;
+import java.util.ArrayList;
+import java.util.Set;
 
 /**
  *
@@ -39,6 +42,8 @@
  * @version 1.0
  */
 public class FragmentationInterceptor extends ChannelInterceptorBase {
+private static org.apache.commons.logging.Log log = 
org.apache.commons.logging.LogFactory.getLog( FragmentationInterceptor.class );
+
 protected HashMap fragpieces = new HashMap();
 private int maxSize = 1024*100;
 private long expire = 1000 * 60; //one minute expiration
@@ -68,16 +73,21 @@
 }
 
 
-public synchronized FragCollection getFragCollection(FragKey key, 
ChannelMessage msg) {
+public FragCollection getFragCollection(FragKey key, ChannelMessage msg) {
 FragCollection coll = (FragCollection)fragpieces.get(key);
 if ( coll == null ) {
-coll = new FragCollection(msg);
-fragpieces.put(key,coll);
+synchronized (fragpieces) {
+coll = (FragCollection)fragpieces.get(key);
+if ( coll == null ) {
+coll = new FragCollection(msg);
+fragpieces.put(key, coll);
+}
+}
 } 
 return coll;
 }
 
-public synchronized void removeFragCollection(FragKey key) {
+public void removeFragCollection(FragKey key) {
 fragpieces.remove(key);
 }
 
@@ -120,6 +130,23 @@
 for ( int i=0; ihttp://svn.apache.org/viewcvs/tomcat/container/tc5.5.x/modules/groupcom/to-do.txt?rev=381827&r1=381826&r2=381827&view=diff
==
--- tomcat/container/tc5.5.x/modules/groupcom/to-do.txt (original)
+++ tomcat/container/tc5.5.x/modules/groupcom/to-do.txt Tue Feb 28 15:31:26 2006
@@ -1,24 +1,25 @@
 To Do:
+===
+
+Documentation:
+===
 
-Tasks:
-4. ChannelMessage.getMessage should return streamable, that way we can wrap,
-pass it around and all those good things without having to copy byte arrays
-left and right
-5. NIO and IO DataSender, since the IO is blocking
 
-Interceptors to create
-1. OrderInterceptor - guarantees the order of messages
-2. WaitForCompletionInterceptor - waits for the message to get processed by 
all receivers before returning
+Code Tasks:
+===
+
+6. NIO and IO DataSender, since the IO is blocking
+
+8. WaitForCompletionInterceptor - waits for the message to get processed by 
all receivers before returning
   (This is useful when synchronized=false and waitForAck=false, to improve
 parallel processing, but you want to have all messages sent in parallel and
 don't return until all have been processed on the remote end.)
-3. FragmentationInterceptor - splits up messages that are larger than X bytes.
-4. CoordinatorInterceptor - manages the selection of a cluster coordinator
-5. VirtualSynchronyInterceptor - not sure we want to build this one, it would 
be
-pretty slow, but it would guarantee that all messages were received, to the
-members in that group in that time.
+
+9. CoordinatorInterceptor - manages the selection of a cluster coordinator
+10. Xa2PhaseCommitInterceptor - make sure the message doesn't reach the 
receiver unless all members got it
 
 Tasks Completed
+===
 1. True synchronized/asynchronized replication enabled using flags
 Sender.sendAck/Receiver.waitForAck/Receiver.synchronized 
 Task Desc: waitForAck - should only mean, we received the message, not for the
@@ -27,9 +28,22 @@
 Status: Complete
 Notes: 
 
-
 2. Unique id, send i

Re: Tomcat 6 source organisation

[Yoav Shapira]

> At this point, I don't think there's a big need to decide on these
> components. From what I understand, the general opinion is to have a
> "src" folder containing all the source, with a target that builds
> everything, and then have subtargets for packaging individual components.

Yeah.

Yoav

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

svn commit: r381814 - in /tomcat/container/tc5.5.x: catalina/src/share/org/apache/catalina/startup/ClusterRuleSetFactory.java modules/ha/build.xml

[fhanik]

Author: fhanik
Date: Tue Feb 28 15:08:57 2006
New Revision: 381814

URL: http://svn.apache.org/viewcvs?rev=381814&view=rev
Log:
Refactored cluster1 vs cluster2


Modified:

tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/startup/ClusterRuleSetFactory.java
tomcat/container/tc5.5.x/modules/ha/build.xml

Modified: 
tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/startup/ClusterRuleSetFactory.java
URL: 
http://svn.apache.org/viewcvs/tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/startup/ClusterRuleSetFactory.java?rev=381814&r1=381813&r2=381814&view=diff
==
--- 
tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/startup/ClusterRuleSetFactory.java
 (original)
+++ 
tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/startup/ClusterRuleSetFactory.java
 Tue Feb 28 15:08:57 2006
@@ -29,29 +29,49 @@
 public static Log log = LogFactory.getLog(ClusterRuleSetFactory.class);
 
 public static RuleSetBase getClusterRuleSet(String prefix) {
+
+//OLD CLUSTER 1
 //first try the same classloader as this class server/lib
 try {
-return 
loadRuleSet(prefix,ClusterRuleSetFactory.class.getClassLoader());
+return 
loadRuleSet(prefix,"org.apache.catalina.cluster.ClusterRuleSet",ClusterRuleSetFactory.class.getClassLoader());
 } catch ( Exception x ) {
 //display warning
 if ( log.isWarnEnabled() ) log.warn("Unable to load 
ClusterRuleSet, falling back on context classloader",x);
 }
 //try to load it from the context class loader
 try {
-return 
loadRuleSet(prefix,Thread.currentThread().getContextClassLoader());
+return 
loadRuleSet(prefix,"org.apache.catalina.cluster.ClusterRuleSet",Thread.currentThread().getContextClassLoader());
 } catch ( Exception x ) {
 //display warning
-if ( log.isWarnEnabled() ) log.warn("Unable to load 
ClusterRuleSet, falling back on DefaultClusterRuleSet",x);
+if ( log.isWarnEnabled() ) log.warn("Unable to load 
ClusterRuleSet, will try to load the HA cluster",x);
 }
+
+//NEW CLUSTER 2
+//first try the same classloader as this class server/lib
+try {
+return 
loadRuleSet(prefix,"org.apache.catalina.ha.ClusterRuleSet",ClusterRuleSetFactory.class.getClassLoader());
+} catch ( Exception x ) {
+//display warning
+if ( log.isWarnEnabled() ) log.warn("Unable to load HA 
ClusterRuleSet, falling back on context classloader",x);
+}
+//try to load it from the context class loader
+try {
+return 
loadRuleSet(prefix,"org.apache.catalina.ha.ClusterRuleSet",Thread.currentThread().getContextClassLoader());
+} catch ( Exception x ) {
+//display warning
+if ( log.isWarnEnabled() ) log.warn("Unable to load HA 
ClusterRuleSet, falling back on DefaultClusterRuleSet",x);
+}
+
+
 return new DefaultClusterRuleSet(prefix);
 }
 
 
-protected static RuleSetBase loadRuleSet(String prefix, ClassLoader cl) 
+protected static RuleSetBase loadRuleSet(String prefix, String className, 
ClassLoader cl) 
 throws ClassNotFoundException, InstantiationException, 
NoSuchMethodException,IllegalAccessException,
InvocationTargetException {
-Class clazz = 
Class.forName("org.apache.catalina.cluster.ClusterRuleSet",true,cl);
+Class clazz = Class.forName(className,true,cl);
 Constructor cons = clazz.getConstructor(new Class[] {String.class});
 return (RuleSetBase)cons.newInstance(new String[] {prefix});
 }

Modified: tomcat/container/tc5.5.x/modules/ha/build.xml
URL: 
http://svn.apache.org/viewcvs/tomcat/container/tc5.5.x/modules/ha/build.xml?rev=381814&r1=381813&r2=381814&view=diff
==
--- tomcat/container/tc5.5.x/modules/ha/build.xml (original)
+++ tomcat/container/tc5.5.x/modules/ha/build.xml Tue Feb 28 15:08:57 2006
@@ -92,16 +92,16 @@
>
 
 
-
-
-
-
-
+
+
+
+
+

 
 
@@ -138,7 +138,7 @@
 
 
-   
+   


 



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

svn commit: r381861 - in /tomcat/container/tc5.5.x/modules: groupcom/etc/ groupcom/src/share/org/apache/catalina/tribes/tcp/ ha/etc/

[fhanik]

Author: fhanik
Date: Tue Feb 28 17:25:07 2006
New Revision: 381861

URL: http://svn.apache.org/viewcvs?rev=381861&view=rev
Log:
Simple modifications, got rid of the SocketSender class, it aint doing nothing 

Removed:

tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tcp/SocketSender.java
Modified:
tomcat/container/tc5.5.x/modules/groupcom/etc/cluster-server.xml

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

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

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

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

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

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

tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tcp/ThreadPool.java
tomcat/container/tc5.5.x/modules/ha/etc/cluster-server.xml

Modified: tomcat/container/tc5.5.x/modules/groupcom/etc/cluster-server.xml
URL: 
http://svn.apache.org/viewcvs/tomcat/container/tc5.5.x/modules/groupcom/etc/cluster-server.xml?rev=381861&r1=381860&r2=381861&view=diff
==
--- tomcat/container/tc5.5.x/modules/groupcom/etc/cluster-server.xml (original)
+++ tomcat/container/tc5.5.x/modules/groupcom/etc/cluster-server.xml Tue Feb 28 
17:25:07 2006
@@ -1,4 +1,4 @@
-
+
 
 
@@ -10,21 +10,15 @@
  define subcomponents such as "Valves" or "Loggers" at this level.
  -->
 
-
+
 
+  
+  
+  
+  
+  
 
-  
-  
-  
-  
-  
   
   
 
@@ -35,18 +29,9 @@
  UserDatabaseRealm to authenticate users -->
 
-
-
-  
-factory
-org.apache.catalina.users.MemoryUserDatabaseFactory
-  
-  
-pathname
-conf/tomcat-users.xml
-  
-
+   description="User database that can be updated and saved"
+   factory="org.apache.catalina.users.MemoryUserDatabaseFactory"
+  pathname="conf/tomcat-users.xml" />
 
   
 
@@ -60,7 +45,7 @@
-->
 
   
-  
+  
 
 
 
-
-
+
+
 
+ to 0 -->
+   
+   
 
-
+
 
 
-
-
+
+
 
 
 
 
 
@@ -130,12 +116,12 @@
  analyzes the HTTP headers included with the request, and passes them
  on to the appropriate Host (virtual host). -->
 
- 
  
 
-
+
 
   
 
-  
-  
-
   
 
   
   
+ resourceName="UserDatabase"/>
 
   
@@ -179,7 +160,7 @@
stored in a database and accessed via JDBC -->
 
   
 
   
 
   
 
-  
-  
-   
-
+  
+  
+
  
- 
-
-
-
 
+
+
+
+
+
+
+
+
+
+
+
+
 
-
+
+   
+
+  
+
+
+
 
-  
-  
 
-
-
 
 
 
-
+
 
 
-
-
-
-
+
+
+
+ This valve use NIO direct Byte Buffer to asynchornously store the
+ log.
+-->
 
-
 
   
 

Modified: 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tcp/DataSender.java
URL: 
http://svn.apache.org/viewcvs/tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tcp/DataSender.java?rev=381861&r1=381860&r2=381861&view=diff
==
--- 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tcp/DataSender.java
 (original)
+++ 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/tcp/DataSender.java
 Tue Feb 28 17:25:07 2006
@@ -213,7 +213,9 @@
  * After failure make a resend
  */
 private boolean resend = false ;
-
+private int rxBufSize = 1024;
+private int txBufSize = 4096;
+
 // - 
Constructor
 
 public DataSender(String domain,InetAddress host, int port) {
@@ -228,6 +230,12 @@
 this(domain,host,port);
 if ( state != null ) this.senderState = state;
 }
+public DataSender(String domain,InetAddress host, int port, SenderState 
state, int rxBufSize, int txBufSize) {
+this(domain,host,port,state);
+this.rxBufSize = rxBufSize;
+this.txBufSize = txBufSize;
+}
+
 // ---

DO NOT REPLY [Bug 36853] - https

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





--- Additional Comments From [EMAIL PROTECTED]  2006-03-01 06:36 ---
I am also running into the same problem.  

The connector starts correctly but somehow the secure connection does not get 
established.  If I try http://localhost:443/ then I get to see the page but 
without the secure encryption.  If I try https://localhost or 
https://localhost:443 I get the Usual ie6 "The page cannot be displayed"

There is the revelant part of my catalina indiating that the protocol started:

1-Mar-2006 12:28:36 AM org.apache.coyote.http11.Http11AprProtocol start
INFO: Starting Coyote HTTP/1.1 on http-443

Also, the Manager server status shows the connections when going unsecure but 
not any of the failed connections when trying https...

Any idea anyone?



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

DO NOT REPLY [Bug 36853] - https

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





--- Additional Comments From [EMAIL PROTECTED]  2006-03-01 06:40 ---
Created an attachment (id=17810)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=17810&action=view)
Plain Vanilla server.xml NOT working with ssl enabled


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

DO NOT REPLY [Bug 37455] - https/sll hangs with tcnative-1.dll

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


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |




--- Additional Comments From [EMAIL PROTECTED]  2006-03-01 06:55 ---
So,  For the uninitiated noob like me, what ought a https connector look like?



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

DO NOT REPLY [Bug 37455] - https/sll hangs with tcnative-1.dll

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





--- Additional Comments From [EMAIL PROTECTED]  2006-03-01 06:56 ---
And is keytool still useable?  

In Short, Will the SSL Howto be rewritten?

-- 
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: r381924 - /tomcat/container/tc5.5.x/webapps/docs/changelog.xml

[billbarker]

Author: billbarker
Date: Tue Feb 28 22:22:41 2006
New Revision: 381924

URL: http://svn.apache.org/viewcvs?rev=381924&view=rev
Log:
Catch up the change log

Modified:
tomcat/container/tc5.5.x/webapps/docs/changelog.xml

Modified: tomcat/container/tc5.5.x/webapps/docs/changelog.xml
URL: 
http://svn.apache.org/viewcvs/tomcat/container/tc5.5.x/webapps/docs/changelog.xml?rev=381924&r1=381923&r2=381924&view=diff
==
--- tomcat/container/tc5.5.x/webapps/docs/changelog.xml (original)
+++ tomcat/container/tc5.5.x/webapps/docs/changelog.xml Tue Feb 28 22:22:41 2006
@@ -86,6 +86,12 @@
   
 Refresh loggers used by the digester (remm)
   
+  
+Use sendError instead of setStatus to send the 401 code. (billbarker)
+  
+  
+Don't append the port for an SSL redirect if it is the default port. 
(billbarker)
+  
 
   
   
@@ -124,6 +130,16 @@
   
 Fix invalid length used by some AJP packets for the AJP APR connector, 
which could cause 
 corruption, submitted by Rudiger Plum (jim)
+  
+  
+Fix problems with request.getReader().readLine(). 
+patch by Rainer Jung (billbarker)
+  
+  
+Don't write out the shutdown secret file if shutdown is disabled (the 
default) (billbarker)
+  
+  
+Fix NPE when no sink is supplied. (billbarker)
   
 
   



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