here is a script posted on the list earlier
#!/bin/sh
#
# This is a quickie helper script to easily build tomcat 5 from source.
# This will create a subdirectory called tc5build and build
# tomcat 5 into it.
#
#
try your same test case with mod_proxy, after that switch to the tomcat
user list
Steve Gaunt wrote:
HI,
Has anyone else had any issue using mod_jk under heavy load..
It seems after a period of time(or large no. opf requests) under heavy load AJP connetor just hangs. It's crazy.
All
out of curiosity, I haven't yet been too much on the 5.5 platform,
is this a new bug introduced, cause we have never seen it on 5.0
Filip
Peter Rossbach wrote:
Hey!
I have changed the cluster message header format long time ago 5.5.10.
In some situations TCP Stack split the message, then
in. Now it is fixed. Every help is welcome.
Peter
Filip Hanik - Dev Lists schrieb:
out of curiosity, I haven't yet been too much on the 5.5 platform,
is this a new bug introduced, cause we have never seen it on 5.0
Filip
Peter Rossbach wrote:
Hey!
I have changed the cluster message header format
to it. I hope to have more time next year.
Filip
Peter Rossbach wrote:
Compression is optional for cluster messages. Very big message can be
set a flag that need compression.
This flag is the header extension.
Peter
Filip Hanik - Dev Lists schrieb:
interesting, why did the protocol header need
why would you replicate session data across contexts? cross context
means different webapps, maybe I'm confused, but an app would never fail
over from one webapp to a different webapp.
Filip
Peter Rossbach wrote:
Hey,
all my clustering fixes are committed. Fine, than I can start to
makes, sense, should be a simple check in the ReplicationValve.java code
base,
thanks for enlightening me
Filip
Remy Maucherat wrote:
Filip Hanik - Dev Lists wrote:
why would you replicate session data across contexts? cross context
means different webapps, maybe I'm confused, but an app
ok. too many tomcat-user questions answered on dev, lets move all those
discussions where they belong
Re: Source for org.apache.coyote.tomcat5.CoyoteConnector
Re: truncated server.xml got when storing config on condition that
more than one vitual host with same application base directory
I can't implement the change you suggest as it could result in a
circular loop,
expire - fire event - last access - isValid() - expire - fire event
- last access
I have added in the missing message for this event, if you are not happy
with that solution, please provide a simple test case for
What are the SocketReplicationListener and the SocketReplicationThread
classes?
seems like we are duplicating functionality. I'm planning on breaking
out the membership and replication logic into a component so that we
don't mix group messaging logic with session replication logic as they
. At async mode we not need a lots of
parallell threads.
Peter
Am 15.02.2006 um 15:51 schrieb Filip Hanik - Dev Lists:
Question, what Linux distributions that run Java 1.4 or higher
(required for 5.5) do not support NIO?
Filip
Peter Rossbach wrote:
It implements aTCP/IP Socket receiver
+1
=)
Reinhard Moosauer wrote:
Hi List,
please somebody explain:
every few days, a strange procedure can be seen on this list.
Somebody asks for improvement, suggests a fix or simply wants to discuss a new
feature.
Few minutes later, there is an answer from somebody, which tells us to
I really try to avoid these threads cause I'm not interested in debates
nor the political aspects of open source projects and how they work,
but the user brings up a good point, with a probable solution, and I
don't see how a non committer response like the one below is even justified.
I'm not
Gentlemen, I am running into a problem right now where the manager for a
distributable webapp is the StandardManager, instead of the
CatalinaCluster.createManager result when the cluster is enabled. I have
a feeling the commit below might be related.
I will continue to debug, but if you could
I reverted the checkin on my local box, and it started to work again, do
you want to handle it, or do you need me to provide you with more info
what the actual cause was?
Filip
Remy Maucherat wrote:
Filip Hanik - Dev Lists wrote:
Gentlemen, I am running into a problem right now where
here is the trace
Name=/replicator
Manager=null
Cluster=null
Distributable=true
as you can see, the cluster reference is null at this point in time.
Filip
Filip Hanik - Dev Lists wrote:
ok, I will dig to the bottom of this :)
Filip
Remy Maucherat wrote:
Filip Hanik - Dev Lists wrote:
I
Peter Rossbach wrote:
I have add the compress flag inside the protocol.
It is usefull to send message with an without compression.
For short messages it is not usefull to compress, it is an overhead.
There is no question whether compression is useful or not.
The compression flag should have
context replication to support
portal development. Please, I do not want to stop the innovation, but
why do we not start the new cluster design at a separate module and
set the current code base at maintaince mode?
Peter Roßbach
Am 23.02.2006 um 12:59 schrieb Filip Hanik - Dev Lists:
Peter
, much needed and a huge improvement on how the
code base looks today.
Filip
Filip Hanik - Dev Lists wrote:
new features and new development has historically always been done
against the head revision.
If you want to put something into maintenance, then that becomes a branch
for example
VERSION
Then simple cluster setup currently not working.
that's ok, I haven't voted +1 stable yet :) I will get to it.
Filip
Peter Rossbach wrote:
Am 23.02.2006 um 15:05 schrieb Filip Hanik - Dev Lists:
Peter Rossbach wrote:
as you might understand, it will take me longer time to explain
Rainer, all are very good thoughts. Here is why I opt we still move forward
1. If we don't primary/secondary will not be available until TC.6
2. TC 6 doesn't have a skeleton nor a date yet.
3. Many people are opting out of clustering today because of lack of
primary/sec. all-to-all is too
enjoy your trip!
Peter Rossbach wrote:
Sounds very great
+1
many thanks and now I can start very relaxed to my short journey :-)
Peter
Am 23.02.2006 um 18:25 schrieb Filip Hanik - Dev Lists:
Sounds like there is a consensus amongst folks. So to summarize
everyones thoughts, let me know
Remy Maucherat wrote:
Filip Hanik - Dev Lists wrote:
+1 from myself
I think one day, I ought to make a proposal and then veto it.
Just wait until age catches up with you, you will! :)
This sounds reasonable.
Lazy consensus, nice.
(http://www.apache.org/foundation/voting.html
Costin Manolache wrote:
I'm curious, do you need anything in server.xml ?
very interesting, and also a possibility. let me think about it, maybe I
will have an epiphany while I work on it.
Filip
-
To unsubscribe,
interesting.
Another thing that DTrace can check is lock contention. So there's
more to come :)
Do you have a working build of groupcom? I could trace some of the
group communication.
I hope you will not sacrifice synchronization correctness for
performance ...
Rainer
Filip Hanik - Dev
its been taken care of, go back and read the thread New clustering
module proposal - WAS: Long rants
Filip
dietmar mueller wrote:
Hello List,
1st: sorry for my bad english.
2nd: you do a great job
3th: the reason for this posting.
I use tomcat for some years in our production environment
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.
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
are all the conf files, startup scripts etc in one place? res?
I was thinking that we still have a src directory, and subdirectories
under that.
trunk/src/java
trunk/src/native
trunk/webapps
etc
Keith Wannamaker wrote:
Yes, this will do nicely.
Keith
Costin Manolache wrote:
We still need
Very interesting, I think the patch would be even better if the caching
policy was configurable.
ie, LRU, MRU, FIFO etc. To take it beyond that, the cache should be
configurable per context (see last note).
your test case is a little out there, (who would map .html to cached
JSPs:) but it
I wrote together a little idea (also emailed to geronimo-dev for
feedback) on how the next generation of session replication should be done.
Today's replication is an all-to-all replication, and within that realm,
its pretty poor. It creates way to much network traffic as each request
results
Yarick, can you open a defect in bugzilla and attach the patch, once we
have a few more developers look at it,
we can apply it,
also let us know if you'd be interested in working with the group to
come up with a per context configurable cache mechanism
Filip
Yaroslav Sokolov wrote:
Leon Rosenberg wrote:
Hello Filip,
very interesting proporsal indeed. May I point you to some importand
use-cases and ask whether your proporsal has solutions for it.
1. Poviding an easy way to customize diffs.
As far as I understand customizable diffs are possible by a) patching
the
for very large clusters, you use the same mechanism, except, instead of
distributing the entire session map, the backup node info is stored in a
cookie.
Filip
If we would store the result-set (list of already created beans) in
the session, we'd have to store them twice, once in the cache
Andy Piper wrote:
Hi Filip
At 04:44 PM 3/3/2006, Filip Hanik - Dev Lists wrote:
3. And the key to this, is that we will have an implementation of a
LazyReplicatedHashMap
The key object in this map is the session Id.
The map entry object is an object that looks like this
ReplicatedEntry
Remy Maucherat wrote:
David Rees wrote:
On 3/7/06, Yaroslav Sokolov [EMAIL PROTECTED] wrote:
Ok, I can make the next conclusions:
1. Tomcat eats resources on first opening of any jsp page and never
returns
them back - servlets just are never unloaded.
2. As it happens in all the versions of
everyone kosher with this change?
Filip
[EMAIL PROTECTED] wrote:
Author: fhanik
Date: Tue Mar 21 09:55:07 2006
New Revision: 387590
URL: http://svn.apache.org/viewcvs?rev=387590view=rev
Log:
In order to make this manager extendable, it should not assume the class of the
session
Modified:
Question, if you remove the lines you mentioned, does the application
get deployed in your local instance, the one where the manager servlet
runs? Cause the line that is removed is where the war is copied to the
appbase of the host.
I haven't had time to run through this patch, but there
aah got it, in that case,
+1
to get this fixed,
will wait a day or two, if no minus one votes come up, I'll apply it for
you, just remind me :)
Filip
Haroon Rafique wrote:
On Today at 4:02pm, FHDL=Filip Hanik - Dev Lists [EMAIL PROTECTED] wrote:
FHDL Question, if you remove the lines you
Haroon Rafique wrote:
/www/apache-tomcat-5.5.16/webapps/sws.war
/www/tomcat/webapps/sws.war
this would turn my vote into -1, based on false information provided
earlier.
That should be explanation enough.
Haroon, you'd need to provide a more solid test case, if the paths
indeed are
Haroon Rafique wrote:
Replace:
copy(localWar, new File(getAppBase(), basename + .war));
with:
File secondCopy = new File(getAppBase(), basename + .war);
if( !localWar.getCanonicalPath().equals(secondCopy.getCanonicalPath()) ) {
copy(localWar, secondCopy);
}
exactly, this or a
when loading a up a JNI profiler, the code freaks out, and the server is
unable to start.
If I could disable APR in the connector string in the server.xml, I
could work around this through configurations.
Filip
Exception in thread main java.lang.reflect.InvocationTargetException
at
patch looks good to me, +1,
if no objections arise, then I can submit, we'll wait until end of week.
Filip
http://issues.apache.org/bugzilla/attachment.cgi?id=17944
Haroon Rafique wrote:
On Today at 2:47pm, HR=Haroon Rafique [EMAIL PROTECTED] wrote:
HR
HR Patch 17943 submitted on bugzilla
lemme try,
Yoav Shapira wrote:
I thought we could already disable it by just using a non-APR
connector class name?
Yoav
On 3/22/06, Filip Hanik - Dev Lists [EMAIL PROTECTED] wrote:
when loading a up a JNI profiler, the code freaks out, and the server is
unable to start.
If I could disable
ladies and gents,
the first rough prototype of primary/secondary replication has been
completed.
For those wish to try it out,
1. To build it, add
cluster-ha=true to container/modules/build.properties
this will build catalina-tribes.jar and catalina-ha.jar instead of
catalina-cluster.jar
Remy Maucherat wrote:
Peter Rossbach wrote:
Cool catch = Use simple data structure, with fine performance
impact. :-)
Believe it or not, but it's just a little bit faster than the stack
(which has the same behavior, except with syncs).
you can only tell true performance improvement on
just a small observation,
working with multiple polling threads is pretty hard, we do it in the
clustering code (NIO), on the receiver side of things,
and it took a while to work out the kinks, and you need a shared place
to lock, since a lot of the operations are not thread safe.
The code
Hi Bela, since the original email was with legal, I better make it
public on the tomcat dev list.
no worries, this implementation is more different than JGroups than
other groupcomm frameworks, like Appia for example
(http://appia.di.fc.ul.pt/ http://appia.di.fc.ul.pt/docs/javadoc/,
changing
try it on the tomcat-user list
Andre Kammerl wrote:
Hi.
Sorry to bother you again with the tester.xml but when I manage to fix one probleme
another one occurs. After modifying the build.xml a little bit the tester.xml is now
working. But when I start the tester.xml in eclipse all tests show
take a look at the PersistentManager
Marc Riehm wrote:
I would like to make a suggestion for a new Tomcat Session Manager.
I've been using Tomcat heavily for 5 years now at my work:
http://www.maptuit.comhttp://www.maptuit.com/. We have multiple Tomcat instances, but
sessions are bound to
It expects there to be a tomcat-native-1.1.3 referenced in the build file
http://archive.apache.org/dist/tomcat/tomcat-connectors/native/
either we change the build to download -current, or publish a
1.1.3.tar.gz file,
anyone up for the task?
thanks
Filip
yep, I'll get this one in
Haroon Rafique wrote:
On Apr 6 at 9:54am, HR=Haroon Rafique [EMAIL PROTECTED] wrote:
HR On Mar 22 at 3:04pm, FHDL=Filip Hanik - Dev Lists [EMAIL PROTECTED]
wrote:
HR
HR FH patch looks good to me, +1,
HR FH if no objections arise, then I can submit, we'll wait
The Apache Tomcat team is pleased to announce the immediate availability
of version 5.5.20 of the Apache Tomcat server.
This release contains dozens of important bug fixes and improvements to
the Tomcat server.
Release Notes: http://tomcat.apache.org/tomcat-5.5-doc/RELEASE-NOTES
Change Log:
I will fix that, thanks for letting us know
FIlip
David Rees wrote:
On 9/28/06, Filip Hanik - Dev Lists [EMAIL PROTECTED] wrote:
The Apache Tomcat team is pleased to announce the immediate availability
of version 5.5.20 of the Apache Tomcat server.
The links to the md5sum files are broken
Remy Maucherat wrote:
[EMAIL PROTECTED] wrote:
Author: mturk
Date: Fri Sep 29 01:23:37 2006
New Revision: 451157
URL: http://svn.apache.org/viewvc?view=revrev=451157
Log:
Introduce keepAliveTimeout to be able to separate
the Keep-Alive and Socket timeout.
The patch enables to have infinite
Remy Maucherat wrote:
Filip Hanik - Dev Lists wrote:
Remy Maucherat wrote:
[EMAIL PROTECTED] wrote:
Author: mturk
Date: Fri Sep 29 01:23:37 2006
New Revision: 451157
URL: http://svn.apache.org/viewvc?view=revrev=451157
Log:
Introduce keepAliveTimeout to be able to separate
the Keep-Alive
Remy Maucherat wrote:
Costin Manolache wrote:
IMO both clustering implementations should be provided as separate
downloads.
No need to put them in sandbox ( since they were released in the
past, it's
'proven' code ).
Not sure if they should be in separate repos or it's ok to have both
of
is anyone from this group gonna attend?
Austin is only 3hours from where I live so I will be there the whole
week (Mon-Fri)
I think it would be neat to get together, maybe during the hackathon or
just for a drink in the bar and b.s. a little.
Filip
you are correct, soTimeout should not, imho, change depending on the
thread count.
if the user sets 20 seconds for soTimeout then it should stay that way.
on blocking io, soTimeout naturally becomes keepAliveTimeout, as when
the request is complete, you go into read() again.
on non blocking io
I like the trick, it's smart, but I believe we could also achieve it
with keep alive request limits, ie, when thread count gets high, turn
off keep alive by mocking maxKeepAliveRequests=1
ie, this way it doesn't affect the servlet and its usage of the stream.
Filip
Remy Maucherat wrote:
Costin Manolache wrote:
On 9/29/06, Remy Maucherat [EMAIL PROTECTED] wrote:
Costin Manolache wrote:
IMO both clustering implementations should be provided as separate
downloads.
No need to put them in sandbox ( since they were released in the past,
it's
'proven' code ).
Not sure if they
[X] I'm for that proposal
[ ] I'm against that proposal
[ ] I don't care
Filip
Mladen Turk wrote:
Hi all,
I would like to propose a simple vote on the thing I consider
as very important. It's probably the first vote ever done for
the commited code, but the reasons are known for the folks
Remy Maucherat wrote:
Yoav Shapira wrote:
It looks the same for Tomcat 5 and Tomcat 6 right now. The default
milestone is --- (three hyphens in a row). Should we add a dummy one
for Tomcat 6, called unspecified or something like that?
Feel free to try anything which could make it work :)
Yoav Shapira wrote:
-0.5, close to -1 on JIRA on philosophical grounds, as it's not a free
and open-source product...
huh? its free for open source projects, I thought JIRA was widely used
within the ASF, why wouldn't we?
Filip
Yoav
On 10/5/06, Filip Hanik - Dev Lists [EMAIL PROTECTED
Remy Maucherat wrote:
Hi,
I think the branch is in a state where builds can start being
released. Some people asked for them earlier, so I don't think anyone
will complain if this actually happens.
Given what changes were made, I expect stability to be reasonable.
Would it be ok to do some
Remy Maucherat wrote:
[EMAIL PROTECTED] wrote:
Author: remm
Date: Fri Oct 13 08:13:57 2006
New Revision: 463702
URL: http://svn.apache.org/viewvc?view=revrev=463702
Log:
- Add a build script to build extras.
- Update the logging documentation.
More funky optional package renamed stuff ;)
I
I would say lets get rid of the 5.5 changelog in 6, as 5.5 will continue
for quite a while, it will become out of sync.
Filip
[EMAIL PROTECTED] wrote:
Author: remm
Date: Mon Oct 16 09:37:32 2006
New Revision: 464554
URL: http://svn.apache.org/viewvc?view=revrev=464554
Log:
- Thanks for
good idea,
Filip
Remy Maucherat wrote:
[EMAIL PROTECTED] wrote:
Author: fhanik
Date: Mon Oct 16 12:23:34 2006
New Revision: 464632
URL: http://svn.apache.org/viewvc?view=revrev=464632
Log:
Fixed manager registration and how manager names are handled. Make
sure the manager has a reference to
overall, could we get rid of the documentation clutter in server.xml,
make it readable on one page, with small comments here and there.
thoughts?
Filip
Filip Hanik - Dev Lists wrote:
good idea,
Filip
Remy Maucherat wrote:
[EMAIL PROTECTED] wrote:
Author: fhanik
Date: Mon Oct 16 12:23:34
gents and ladies,
currently we are doing SSL a little bit differently between APR and the
Java connectors.
The APR connector requires an attribute sslEngine=On to kick in.
I believe this attribute to be useful for two reasons:
1.
Config should be as consistent as possible.
2.
If I use a SSL
knock yourself out :)
Remy Maucherat wrote:
[EMAIL PROTECTED] wrote:
Author: fhanik
Date: Tue Oct 17 09:49:59 2006
New Revision: 464958
URL: http://svn.apache.org/viewvc?view=revrev=464958
Log:
Cleaned up server.xml, added in documentation references so that a
user can navigate from an
Jean-frederic Clere wrote:
Filip Hanik - Dev Lists wrote:
gents and ladies,
currently we are doing SSL a little bit differently between APR and
the Java connectors.
The APR connector requires an attribute sslEngine=On to kick in.
I believe this attribute to be useful for two reasons:
1
Jean-frederic Clere wrote:
Filip Hanik - Dev Lists wrote:
Jean-frederic Clere wrote:
Filip Hanik - Dev Lists wrote:
gents and ladies,
currently we are doing SSL a little bit differently between APR and
the Java connectors.
The APR connector requires an attribute sslEngine=On to kick
ballot
[X] +1
[ ] +0
[ ] -1
/ballot
Filip
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Mladen Turk wrote:
[EMAIL PROTECTED] wrote:
-ssl = endpoint.getSecure();
+ssl = on.equalsIgnoreCase(endpoint.getSSLEngine());
Like Remy said, anything except Off is acceptable.
It can be either On or EngineName (eg, SSLEngine=nuron)
that's for APR, because of
if
Filip Hanik - Dev Lists wrote:
Mladen Turk wrote:
[EMAIL PROTECTED] wrote:
-ssl = endpoint.getSecure();
+ssl = on.equalsIgnoreCase(endpoint.getSSLEngine());
Like Remy said, anything except Off is acceptable.
It can be either On or EngineName (eg, SSLEngine=nuron)
that's
Filip Hanik - Dev Lists wrote:
Filip Hanik - Dev Lists wrote:
Mladen Turk wrote:
[EMAIL PROTECTED] wrote:
-ssl = endpoint.getSecure();
+ssl = on.equalsIgnoreCase(endpoint.getSSLEngine());
Like Remy said, anything except Off is acceptable.
It can be either
does anyone have these, I assume I wouldn't have to sign another
agreement to upgrade TCK, as I already signed the agreement to use TCK
with tomcat 5.5
Filip
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional
Mladen Turk wrote:
Filip Hanik - Dev Lists wrote:
to eager to press send, that way the connector would have only on/off
values, while the actual SSLEngine value neuron would be in the
APRLifeCycleListener,
much cleaner, and all our connectors become consistent on that value
Look
much thanks!
Yoav Shapira wrote:
I don't have them. You don't need to sign antoher agreement I think.
You do simply need to ask Geir ([EMAIL PROTECTED], our JCP liaison) for a
copy, assuming these TCKs already exist, and he will get it for you.
Yoav
On 10/18/06, Filip Hanik - Dev Lists
Mladen Turk wrote:
[EMAIL PROTECTED] wrote:
SSLEngine is an attribute of the APR lifecycle listener to initialize
the native SSL layer once per VM.
I don't get it, really.
:)
Did you read my reply about:
1. scheme=https secure=true
2. scheme=https secure=false
3. scheme=http secure=false
Mladen Turk wrote:
Filip Hanik - Dev Lists wrote:
The scenario we are trying to achieve is this:
Connector port=8443 scheme=https secure=true SSLEnabled=false/
How will in that case behave:
Let me see if I can explain
Connector port=8443 scheme=https secure=false SSLEnabled=false
Mladen Turk wrote:
Remy Maucherat wrote:
It is also a good thing to cleanup the SSLEngine initialization,
which should indeed be a one per VM call.
SSL.initialize is reference counted, so any consecutive call
simply returns OK.
that wasn't the entire problem though, it wasn't clear to the
works for me,
Filip
Remy Maucherat wrote:
Remy Maucherat wrote:
Hi,
The release plan is located here:
http://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk/RELEASE-PLAN-6.0.txt
ballot
[ ] +1
[ ] +0
[ ] -1
/ballot
This calls for a first build to be released by friday, and it will
use the
gentlemen, not sure if you had a chance to look this over, but it is
pretty interesting,
after some very basic tests, I get the NIO connector to perform better
than the blocking io connector
the peak data throughput are
NIO - 36,000KB/s
JIO - 35,000KB/s
APR - 24,000KB/s
basic connector config,
Remy Maucherat wrote:
Filip Hanik - Dev Lists wrote:
gentlemen, not sure if you had a chance to look this over, but it is
pretty interesting,
after some very basic tests, I get the NIO connector to perform
better than the blocking io connector
the peak data throughput are
NIO - 36,000KB/s
JIO
This question belongs to the Tomcat User list. Please direct your future
Tomcat questions there
Answer:1.1.4
Fenlason, Josh wrote:
I'm updating to Tomcat 5.5.20 and I'm not sure what version of the
native APR connector I should be using. The tomcat-native.tar.gz in
apache-tomcat-5.5.20\bin
Lists wrote:
Remy Maucherat wrote:
Filip Hanik - Dev Lists wrote:
gentlemen, not sure if you had a chance to look this over, but it is
pretty interesting,
after some very basic tests, I get the NIO connector to perform
better than the blocking io connector
the peak data throughput are
NIO
This question belongs to the tomcat user list, please direct your future
questions there,
The answer to your question is is conf/web.xml where you can set the
language features for the JSP, just search for 1.4 and change it to 1.5
Filip
Dies Koper wrote:
Hello,
I never doubted that Tomcat
I don't have any preference either way, since we are pretty few active
folks at the moment, the less code is usually better
Filip
Mladen Turk wrote:
Hi,
Beyond the fact that org.apache.jk.* provides a generator for
the mod_jk.conf, is there any reason to have that connector
in parallel with
Remy Maucherat wrote:
Yoav Shapira wrote:
It's on people.apache.org, but I think it might still be hosed. The
upload directions are at:
http://www.apache.org/dev/release-publishing.html#maven-repo
Once we have a formal release (i.e. voted / approved by the PMC), we
can also upload to ibiblio,
Remy Maucherat wrote:
[EMAIL PROTECTED] wrote:
Author: fhanik
Date: Wed Oct 25 15:11:10 2006
New Revision: 467787
URL: http://svn.apache.org/viewvc?view=revrev=467787
Log:
Documented socket properties
Added in the ability to cache bytebuffers based on number of channels
or number of bytes
systems handling 10-20k requests per second one can run into
trouble much faster, than the usual cleanup intervals.
Check with netstat -an if you can see a lot of TIME_WAIT connections
(thousands). If not it's something different :(
Regards,
Rainer
Filip Hanik - Dev Lists schrieb:
Remy
, you
might want to tcpdump to check, if it's really slow on the server side.
you got it, that is the problem.
Filip
Just my 0.9 cents ...
Rainer
Filip Hanik - Dev Lists schrieb:
That's some very good info, it looks like my system never does go over
30k and cleaning it up seems
Remy Maucherat wrote:
[EMAIL PROTECTED] wrote:
Author: fhanik
Date: Wed Oct 25 15:11:10 2006
New Revision: 467787
URL: http://svn.apache.org/viewvc?view=revrev=467787
Log:
Documented socket properties
Added in the ability to cache bytebuffers based on number of channels
or number of bytes
gents, so I finally think I have a stable NIO implementation that is
doing fairly well.
I have an idea for a next generation of the NIO connector that I wanted
to present so that you can comment and if you'd like help out with.
NIO GEN 2
Current Implementation
--
* Non
try to set the property socket.soTrafficClass to some other value,
if it's not working, what JDK are you running, here is the flag
described by SUN
http://java.sun.com/j2se/1.5.0/docs/api/java/net/Socket.html#setTrafficClass(int)
Peter Rossbach wrote:
Hi Filip,
I am starting testing your
)
at java.lang.Thread.run(Thread.java:613)
After this NPE the messages flush to the browser an connection are
closed.
Regards
Peter
Am 30.10.2006 um 15:04 schrieb Filip Hanik - Dev Lists:
try to set the property socket.soTrafficClass to some other value,
if it's not working, what JDK are you
schrieb Filip Hanik - Dev Lists:
try to set the property socket.soTrafficClass to some other value,
if it's not working, what JDK are you running, here is the flag
described by SUN
http://java.sun.com/j2se/1.5.0/docs/api/java/net/Socket.html#setTrafficClass(int)
Peter Rossbach wrote:
Hi
yeah, that fix is not entirely correct and can lead to problems down the
road,
the problem is bigger than that, I have to catch the socket being closed
earlier so that I can unattach the attachment from the key
Filip
Filip Hanik - Dev Lists wrote:
how do you reproduce this? I've added in your
1 - 100 of 1185 matches
Mail list logo
