gmane.comp.apache.devel

Re: CLOSE_WAIT problem

Andrew Oliver — 2012-05-25T16:09:44

You need to specify a pool size.  Also ask on the users list.

Thanks,

Andrew C. Oliver

On Fri, May 25, 2012 at 5:21 AM, Bongjae Chang <bongjae.chang< at >gmail.com> wrote:

Re: CLOSE_WAIT problem

Bongjae Chang — 2012-05-25T09:21:36

Hi Reindl,

Thank you for the link.

When I read the link, it also said "Faulty scenarios would be like
filedescriptor leak, server not being
execute close() on socket leading to pile up of close_wait sockets".

I raised the very same issue(mod_proxy's backend connection which has been
already closed).

Thanks!

Regards,
Bongjae Chang




On 5/25/12 6:01 PM, "Reindl Harald" <h.reindl< at >thelounge.net> wrote:

Re: CLOSE_WAIT problem

Reindl Harald — 2012-05-25T09:01:21


Am 25.05.2012 10:52, schrieb Bongjae Chang:

as far as i understand this is normal TCP behavior for reusing sockets

http://blogs.technet.com/b/janelewis/archive/2010/03/09/explaining-close-wait.aspx

Re: CLOSE_WAIT problem

Bongjae Chang — 2012-05-25T08:52:14

Hi Eric,

Thank you for your reply.

I commented some below.

Thanks!

Regards,
Bongjae Chang



On 5/25/12 3:38 PM, "Eric Covener" <covener< at >gmail.com> wrote:


Then you mean it doesn't matter if CLOSE_WAITs exist because the case is a
rare example.

As your words, Apache doesn't close the peer connection which has been
already closed though Apache can. Then, could I know the reason by any
chance?(just curious)


Woops. I am sorry for using "NIO" words. :-)



I see.. then I think that it will be useful if mod_proxy will support the
feature later(just my opinion).

Re: CLOSE_WAIT problem

Eric Covener — 2012-05-25T06:38:58

It "can" but it doesn't.


NIO is a java-ism.  mod_proxy is synchronous and nobody is watching
the sockets while a thread isn't handling a request and trying to use
the conn.


There is no thread.

Re: CLOSE_WAIT problem

Bongjae Chang — 2012-05-25T03:04:25

Hi Sridhar,

Thank you for your kind words.

First, I am sorry that I also sent this similar mail to users mailing
again before I received your mail.

I received an answer from Elic that the closed conn will be closed when it
will be reused as your words.

Though I sent the following question to users mailing, I would like to
discuss more if this content is suitable for devs mailing.

IMHO, as soon as connections are closed from backend, if Apache can detect
closed connections of backend and close them explicitly, CLOSE_WAITS can
disappear as soon as possible before Apache tries to reuse them.

And I read the default max number which will be allowed to backend is
ThreadsPerChild directive and users can set the max or ThreadsPerChild to
be a big number. Then, I think many CLOSE_WAITs can be piled up. It's a
waste of Fds.

 
Actually, I was afraid of the following situation.
 

1. Apache has many backend connections(i.g. 8080 backend port)
2. Backend server should be replaced for maintenace
3. So Apache connec

range request support using ap_send_fd

Alex Krohn — 2012-05-25T01:29:58

Hi,

I'm working on a problem where mod_perl doesn't seem to accept range
requests documented here:

    http://www.gossamer-threads.com/lists/modperl/dev/104360

Working with 2.2.22, my issue seems to be the mod_perl sendfile
implementation uess ap_send_fd, and ap_send_fd does not create an EOS
bucket, so in byterange_filter.c:

/*
* Don't attempt to do byte range work if this brigade doesn't
* contain an EOS, or if any of the buckets has an unknown length;
* this avoids the cases where it is expensive to perform
* byteranging (i.e. may require arbitrary amounts of memory).
*/

if (!APR_BUCKET_IS_EOS(e) || clength <= 0) {
ap_remove_output_filter(f);
return ap_pass_brigade(f->next, bb);
} 

we don't handle range requests, and so my mod_perl handler does not work
with range requests.

My question is should ap_send_fd be inserting an eos bucket? i.e.

alex< at >alex ~/httpd-2.2.22 $ diff -u server/protocol.c.orig server/protocol.c
--- server/protocol.c.orig2012-01-24 12:02:19.000000000 -0800
+++ server/protocol.c

post-CVE-2011-4317 (rewrite proxy unintended interpolation) rewrite PR's

Eric Covener — 2012-05-24T15:12:01

There are a couple of PR's going around about people who were using
rewrite to operate on URL's now kicked out of mod_rewrite by default
(IIRC at least proxy:blah and CONNECT arg)

Should we just add a mod_rewrite directive or RewriteOption that opts
in to handling any URL and document the cautions in the directive?  I
don't mind doing that code and doc work to skip the new check to
unblock people before 2.2.23.  Please comment!

Re: CLOSE_WAIT problem

sridhar basam — 2012-05-24T13:42:01

I believe this is normal. Apache keeps a pool of connections to the
backend to re-use. There isn't an active thread going through all of
the connections looking to see if they have been closed by the peer.
The proxy module will check the state of a connection after grabbing
it from a resource pool before it re-uses it so the connection in
close_wait will eventually get closed and re-opened. Worse case,  the
number of close_wait connections would be capped at an upper limit
based on your configs and your upstream server.

 Sridhar

Re: Please unsubscribe me

Tony Stevenson — 2012-05-24T08:49:07

Please send to dev-unsubscribe< at >httpd.apache.org



Harish S Rathod wrote on Thu, May 24, 2012 at 02:17:37PM +0530:

Please unsubscribe me

Harish S Rathod — 2012-05-24T08:47:37

Re: svn commit: r1341930 - /httpd/httpd/trunk/docs/manual/suexec.html.en

André Malo — 2012-05-24T08:19:47

I didn't happen the last 10 years or so ;)

nd

Re: svn commit: r1341930 - /httpd/httpd/trunk/docs/manual/suexec.html.en

Joe Schaefer — 2012-05-23T22:34:20

This won't happen once the docs are migrated to the CMS ;-)



----- Original Message -----

Re: svn commit: r1341930 - /httpd/httpd/trunk/docs/manual/suexec.html.en

Joe Orton — 2012-05-23T22:30:31

Oops, sorry, I'm losing it.  Done in r1342078!

Re: svn commit: r1341930 - /httpd/httpd/trunk/docs/manual/suexec.html.en

André Malo — 2012-05-23T22:22:43


Duh. Am I missing something here or didn't you update the XML file?

nd

Comment system, take two and a half

Daniel Gruno — 2012-05-23T18:07:11

Since people have begun talking about the idea of hosting/using this
system within the ASF, I've added some more kinks to the system now.

Those of you who have created an account (or those who create one and
let me know) will now see a "moderate" link when they are viewing
comments while logged in. This will take them to a new moderator site,
where it's possible to track the latest activity, delete threads and
track specific origins (origin tracking only applies to posts made after
I revamped the moderator system, so old posts can't be tracked).

An origin is basically a digest of an IP address (to both preserve the
privacy policy and get rid of any trouble with IPv4/IPv6 mingling), and
it allows you to either ban an origin from posting, view and delete any
comments made by that origin or simply nuke everything ever posted by
that origin. You can also opt in or out of receiving email notifications
when a new post is being made (and opting in/out on a specific page is
in the works). If you like, you can also

Re: Comment system, take two

Daniel Gruno — 2012-05-23T07:34:10

I didnt say it would do that. If the service doesnt have to run on the
same vhost as the main httpd.a.o site then we could run the service
elsewhere in our infrastructure.
Sorry, yes, what I meant to say was that hosting on httpd.a.o would
likely be a no, which is completely fine, as it doesn't need to be
hosted in any specific location. I've talked to Joe this morning about
the possibility of setting up a place within the Apache space for
hosting it in the future, once the remaining kinks have been sorted out.
I'll keep people apprised of how this progresses.

I've also updated the wiki entry on the comments proposal (
http://wiki.apache.org/httpd/DocsCommentSystem ) to reflect the changes
going on.

Last but not least, I've rolled out the system to the entire trunk (so
there's no more "comments disabled" notices), so let's see how things
work out :)

With regards,
Daniel.

Re: Comment system, take two

Tony Stevenson — 2012-05-23T07:15:39

Daniel Gruno wrote on Wed, May 23, 2012 at 04:47:10AM +0200:

I said running php on the main webservers would very likely with a no, I didnt say it would do that.  If the service doesnt have to run on the same vhost as the main httpd.a.o site then we could run the service elsewhere in our infrastructure.

CLOSE_WAIT problem

Bongjae Chang — 2012-05-23T05:35:08

Hi all,

When I tested mod_proxy + mod_proxy_balancer + (mod_proxy_ajp or
mod_proxy_http) with worker mpm, I always met CLOSE_WAIT state in apache
proxy side.

I tested the following scenario.

- Sending a request at the browser -> apache,  mod proxy -> ajp or http java
server(1)
- Normally, browser received the response correctly and the connection state
was ESTABLISHED.
- And java server closed the ajp or http connection with timeout(Or
terminate java server forcibly).
- Then apache proxy machine always had the CLOSE_WAIT state about the
connection.

It seemed that the apache proxy modules did not try to close the invalid
socket which had been already closed at the peer side(the backend java
server side).

Perhaps is it already the known issue?

Please give me some advice if I am misunderstanding something.

Thanks!

--
apache version: 2.4.2
backend java server: grizzly http/ajp, playframework(maybe it uses netty)
os: Apache(Linux 2.6.18 x86_64), BackendServer(MacOs)
--

Regards,
Bongjae Chang

Re: Comment system, take two

Daniel Gruno — 2012-05-23T02:47:10

Yes, because the text is inserted using Document.CreateTextNode, all
that is injected is pure text - HTML tags and the likes should not be
possible to inject in any way other than as pure text. Special tags like
<, >, \ etc are escaped in advance, but this is just so it will display
the characters and not make them invisible. No HTML should be injectable.

Yup, more than 5 bad attempts will start making it difficult for you to
try logging in.
Gee, what gave it away? ;)
Right now it's written in Lua yes (should anyone be interested in the
source code, I'd be happy to provide a link to it), and run on 2.4.2
with mod_pLua (a distant cousin to mod_lua that offers me a bit more
flexibility as well as access to POST data*hint hint*). One of the nice
things about writing it in Lua is that it is quite easy to port it to
other languages such as php or perl, should this be needed. The scripts
themselves are quite small, since most of the work is done via JavaScript.

I have already asked Tony if we could host this on

Re: Comment system, take two

Rainer Jung — 2012-05-22T21:25:21

=== Sorry, sent again, because I forgot the docs list ===

On 21.05.2012 23:04, Daniel Gruno wrote:

Great!


I like it.

+1

Concerning production readyness, some points come to mind:

- Did you pay attention on escaping problematic input? I saw some 
escaping, but didn't thoroughly test it. We don't want XSS and such.

- Is there some safety against brute force password hacking for the 
registered people, especially the moderators? E.g. locking accounts 
after a few wrong passwords.

- Since we want to host it later inside ASF infra: what are the infra 
requirements? It seems the server part is written in Lua? Is it based on 
httpd 2.4 with mod_lua, or just Lua in CGI scripts or similar?

Thanks!

Rainer