Re: backlog measurement

[Andrew Skiba]

Hello Filip,

Thank you again for your reply and for the links.

I think that makes sense.

Yes, I will end up with unmeasurable backlog after acceptQueue is full. But
when the queue is empty, which is the normal operating mode, the backlog
will be filled only for few milliseconds of context switch. AcceptRunnable
is only accepting sockets and putting them into the queue, so it's hard for
kernel backlog not to be empty.

Anyway, the purpose of this patch is not to measure backlog size per se, but
to identify a server incapable to handle its load for long periods of time -
tens of minutes, or hours.

You are right, different OSes have tools to monitor this, but it's always
good to have a pure java solution at hand.

In underloaded server this patch will add an overhead of 1 thread per port,
and rarely few extra I/O buffers for short periods of higher load. I
suppose, GC will take care of that, when the load is low again.

If the server is slashdotted, you will know this sooner or later. The worst
situation is when the load is just slightly above the possible to handle. If
I have 10 worker threads and 20 simultaneously stressing clients, the
response time is double of what can be measured on servlets. This patch
allows to figure that out at price of 1 additional thread and 10 extra I/O
buffers. Probably there will be people who are willing to pay this price, so
they will use this connection factory.

Regards,

Andrew.

On 1/10/08, Filip Hanik - Dev Lists <[EMAIL PROTECTED]> wrote:
>
>
>
> hi Andrew, the solution is a bit overkill and you may be
> misunderstanding the backlog concept.
>
> the concept behind the backlog, is when the app is too busy accepting
> connection, the kernel and its TCP stack will handle it for you.
> and by doing this, you can balance the pressure of new connections at
> the kernel level.
>
> for example, if all threads are busy in java handling requests, the
> kernel will handle SYN and TCP handshakes until its backlog is full.
> when the backlog is full, it will simply drop future SYN requests. it
> will not send a RST, ie causing "Connection refused" on the client,
> instead the client will assume the package was lost and retransmit the
> SYN. hopefully, the backlog queue will have cleared up by then.
>
> doing this in java, and by accepting connections by the process running,
> you're doing redundant work, hence it would be overkill.
>
> in terms of backlog reporting, which is the idea behind this, one would
> have to look at the specific OS, and see what it has to offer for that
> kind of info.
>
> a great read to understand the backlog functionality, since its so
> loosely defined is
>
> http://www.amazon.com/Unix-Network-Programming-Addison-Wesley-Professional/dp/0131411551/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=111167&sr=8-1
>
> it explains it fairly well.
>
> in your example, maxThreads=10 acceptCount=30, with your
> implementations, your not measuring the actual backlog, you're only
> measuring the number of actually accepted connections, you still end up
> with unmeasurable backlog. what you instead end up with is 15 extra
> connections, and the TX/RX buffers and the java objects associated with
> it.
>
> does that make sense?
>
> Filip
>
> Andrew Skiba wrote:
> > Hello Filip, thanks for your reply.
> >
> > You are absolutely right.
> >
> > I did this trick when I understood that it's not trivial to measure
> backlog
> > in Java. I called it backlog because a normal system would have backlog
> of
> > this size in the same conditions. For example, for maxThreads=10 and
> > acceptCount=30 and 25 client threads the backlog size will be 15,
> although
> > we cannot measure it.
> >
> > If you use by socket factory in the same conditions, it will report
> > "backlog" size=15. Although now these 15 sockets are in totally
> different
> > state, from logical point of view, my blackbox behaves the same and now
> is
> > able to report this number.
> >
> > About memory consumptions. In normally functioning system I expect
> threads
> > to be blocked on accept() 99% of the time. Backlog is a spare for short
> term
> > spikes. So my implementation will accept a socket and this socket will
> be
> > used by an other thread very soon. Also it's possible to configure a
> half of
> > a usual acceptCount because I create an additional buffer of this size.
> >
> > I intend to use this socket factory to monitor and store the "backlog"
> size
> > once in a few minutes for all my servers. If I see that in last 3 hours
> this
> > size is always above zero, I know there is a problem. Or if users
> complain
> > that between 17:00  and 17:30 my application responded slower than
> usual, I
> > can check what were backlog readings at that time. Currently I can check
> > only timestamps when requests were processed, but requests could be
> delayed
> > in the backlog and I have no way to know.
> >
> > If my solution is an overkill for this problem, can you please advice me
> a
> > more appropriate way.
>

DO NOT REPLY [Bug 44207] - Apache 2.2.4+jk_ajp+Tomcat 5.5.17 Connect Error!

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


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID




--- Additional Comments From [EMAIL PROTECTED]  2008-01-11 03:21 ---
This is not an error. The log level of all messages is "info".

The messages tell us, that when writing back to the client (=browser), mod_jk
detected that it actually couldn't write back. Usually this simply means, that
the browser didn't wait long enough for the response, but the user instead
started another response (clicked another link, or the same link a second time
etc.).

If this happens a lot, it mostly is an indication, that your application
performance is not good, so users get nervous and try something else.

To get an idea about your appps response times, add "%D" to your httpd LogFormat
(microseconds response duration) and maybe also add an access log valve to
Tomcat with a pattern, that includes also "%D" (milliseconds for tomcat).

If you have further questions, please ask 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]

DO NOT REPLY [Bug 44209] New: - JAASRealm loses credentials - principal=null

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

   Summary: JAASRealm loses credentials - principal=null
   Product: Tomcat 5
   Version: 5.5.23
  Platform: Other
OS/Version: Linux
Status: NEW
  Severity: critical
  Priority: P1
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I have a tomcat 5.5.23 running on linux machine communicating with EJBs on a
Jboss server on another linux machine.

I have lots of users connecting on the system and I get lots of errors in the
jboss authentication module saying that the principal received from tomcat is
null. This occurs after the user has logged in and after he/she successfully
managed to call the server multiple times without any problems. It seems that
sometimes the tomcat JAAS module loses the principal of the LoginContext. I have
not managed to figure out when this happens but when this occurs the user has to
logout and login again.

I have also noticed something else that is weird. When the above scenario occurs
the next user that tries to login is picking up the invalid LoginContext that
has a null principal. I managed to reproduce this by doing a LoginContext.login
with invalid credentials and tried to access a server function in order to
receive an authentication exception from the server. When this happens I do not
logout the context. I then try opening a new session with a new browser and
accessing a function with @PermitAll only to find out that tomcat picked up the
invalid loginContext of the other session and tries to validate the user using
the invalid credentials.

Any help will be appreciated.

-- 
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 44215] New: - jkunmount causes apache to throw permission denied error

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

   Summary: jkunmount causes apache to throw permission denied error
   Product: Tomcat 5
   Version: 5.5.25
  Platform: PC
OS/Version: Linux
Status: NEW
  Severity: normal
  Priority: P3
 Component: Native:JK
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I was trying to use JkUnMount directive to have gif files served by apache
instead of tomcat.  The gif files are originally in the
webapps/selfservice/images directory.  I copied them to the
/var/www/html/selfservice/images directory. I am getting apache error message:

**
You don't have permission to access /selfservice/images/welcome.gif on this 
server.
**

However if I add a rewrite rule:

**
RewriteRule ([^\/\.]+)\.(gif|jpg|jpeg|png|wbmp)$ /selfservice/images/$1.$2 [L]
**

it works fine.

My apache conf file is as follows:

**
DocumentRoot /var/www/html

LoadModule jk_module modules/mod_jk.so
JkWorkersFile "/etc/httpd/workers.properties"
JkLogFile "/var/log/httpd/mod_jk.log"
JkLogLevel debug
JkAutoAlias /usr/share/tomcat5/webapps
JkMount /selfservice/* worker1
JkUnMount /selfservice/*.html worker1
JkUnMount /selfservice/*.jpg  worker1
JkUnMount /selfservice/*.gif  worker1


ServerName  www.examples.com
ServerAlias examples
DocumentRoot /var/www/html



The version of mod_jk is 1.2.21, apache is 2.0.52, tomcat is 5.5.25.

-- 
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 42282] - SSL not working with native libraries

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





--- Additional Comments From [EMAIL PROTECTED]  2008-01-11 12:07 ---
Workaround:  rename /bin/tcnative-1.dll to /bin/tcnative-1.dll.disable to use 
Java SSL Connector instead of APR native. 

-- 
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: svn commit: r609294 - in /tomcat/tc6.0.x/trunk: STATUS.txt conf/catalina.policy webapps/docs/changelog.xml

[Larry Isaacs]

> -Original Message-
> From: Remy Maucherat [mailto:[EMAIL PROTECTED]
> Sent: Thursday, January 10, 2008 5:39 PM
> To: Tomcat Developers List
> Subject: Re: svn commit: r609294 - in /tomcat/tc6.0.x/trunk: STATUS.txt
> conf/catalina.policy webapps/docs/changelog.xml
>
> On Thu, 2008-01-10 at 20:07 +, Mark Thomas wrote:
> > Remy Maucherat wrote:
> > >
> > > On my platform [Linux + IcedTea], with the new policy in place, I
> get an
> > > error initializing a timestamp used by the FileHandler (why such a
> class
> > > ends up using a file like this is a mystery):
> >
> > Can you turn on the debugging so we can figure out which file it is.
> I'd
> > rather add a specific permission, or at least a limited one, rather
> than a
> > default read permission for java_home and every file below it
> (assuming
> > that is where the file it is trying to read is located).
>
> I used java.security.debug=failure. The NPE isn't visible without it
> (and nothing gets logged). I also did try adding various file
> permissions, without much success.
>
> Rémy
>

If I recall correctly, the "failure" option unfortunately doesn't do
anything by itself.  I believe you have to have "access" enabled before
it will include any failures, i.e "java.security.debug=access,failure".
There's no avoiding the huge log file. :(

Cheers,
Larry

>
>
> -
> 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: svn commit: r609294 - in /tomcat/tc6.0.x/trunk: STATUS.txt conf/catalina.policy webapps/docs/changelog.xml

[Remy Maucherat]

On Fri, 2008-01-11 at 13:27 -0500, Larry Isaacs wrote:
> > I used java.security.debug=failure. The NPE isn't visible without it
> > (and nothing gets logged). I also did try adding various file
> > permissions, without much success.
> >
> > Rémy
> >
> 
> If I recall correctly, the "failure" option unfortunately doesn't do
> anything by itself.  I believe you have to have "access" enabled before
> it will include any failures, i.e "java.security.debug=access,failure".
> There's no avoiding the huge log file. :(

Actually, it's quite funny since the NPEs do not occur with
"access,failure", and no accesses are reported as denied (but of course,
there's still no logging).

Rémy



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

DO NOT REPLY [Bug 44216] New: - Don't reuse session ID even if emptySessionPath=true

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

   Summary: Don't reuse session ID even if emptySessionPath=true
   Product: Tomcat 5
   Version: Unknown
  Platform: Other
OS/Version: other
Status: NEW
  Severity: enhancement
  Priority: P2
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Context:
- I want my webapp to use "nice" URL for a user's homepage (e.g.
"http://server/user";) which is then redirected server side to the real URL (e.g.
"http://server/servlet/home?user=user";). This requires to use 
"emptySessionPath".
- I'm using a load-balancer with two Tomcat servers (say T1 and T2) with sticky
sessions (xxx.t1, yyy.t2, ...).
- Because some http client don't support cookies or are started by another http
client (e.g. progressive video download in Media Player started by clicking in
link in Firefox), some links have the session id in the URL (e.g.
http://server/servlet/stream/yyy.t2/music.mp3).

Broken case:
- The user navigates to the website and get the session "yyy.t2"from T2.
- He then bookmarks a URL with session id in it like the one above.
- The next day, he navigates to the website again and get the session "xxx.t1"
from T1.
- He then selects bookmarked URL.
=> The request is redirected to T2. The session is invalid so a new one is
created. But because of the cookie, the session id is "xxx.t1".

So now we have a session created on T2 with a jvmRoute t1. So the following
requests will be send to T1 instead of T2 with an inconsistent (or even expired)
session.

There should be two independent options:
- emptySessionPath which only change the path of the session cookie but nothing 
else
- reuseSessionID which will reuse the session id from the cookie if available

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