Re: [RELEASE CANDIDATE] Apache-Test-1.29 RC2, [was typo 1.27 RC2]
Hi All, Deepest apologies. The correct version is 1.29-RC2 not 1.27-RC2 which I mistyped in the subject and part of the E-Mail text. The URL and tarball were/are correct as they stand. Again, apologies especially for the SPAM. Philip M. Gollucci wrote: A release candidate for Apache-Test 1.27 is now available. http://people.apache.org/~pgollucci/at/Apache-Test-1.29-rc2.tar.gz Please take the time to exercise the candidate through all your existing applications that use Apache-Test and report back successes or failures. Changes since 1.29-rc1: http://svn.apache.org/viewvc?view=rev&revision=469617 Cygwin - Legacy CGYWIN ifs removed http://svn.apache.org/viewvc?view=rev&rev=470824 Fix http://rt.cpan.org/Ticket/Display.html?id=22748 and related http://svn.apache.org/viewvc?view=rev&rev=471132 need_module() documenation tweaks http://svn.apache.org/viewvc?view=rev&rev=471900 License text update per ASF board resolution. -- Philip M. Gollucci ([EMAIL PROTECTED]) 323.219.4708 Consultant / http://p6m7g8.net/Resume/resume.shtml Senior Software Engineer - TicketMaster - http://ticketmaster.com 1024D/A79997FA F357 0FDD 2301 6296 690F 6A47 D55A 7172 A799 97F I never had a dream come true 'Til the day that I found you. Even though I pretend that I've moved on You'll always be my baby. I never found the words to say You're the one I think about each day And I know no matter where life takes me to A part of me will always be... A part of me will always be with you.
[RELEASE CANDIDATE] Apache-Test-1.27 RC2
A release candidate for Apache-Test 1.27 is now available. http://people.apache.org/~pgollucci/at/Apache-Test-1.29-rc2.tar.gz Please take the time to exercise the candidate through all your existing applications that use Apache-Test and report back successes or failures. Changes since 1.29-rc1: http://svn.apache.org/viewvc?view=rev&revision=469617 Cygwin - Legacy CGYWIN ifs removed http://svn.apache.org/viewvc?view=rev&rev=470824 Fix http://rt.cpan.org/Ticket/Display.html?id=22748 and related http://svn.apache.org/viewvc?view=rev&rev=471132 need_module() documenation tweaks http://svn.apache.org/viewvc?view=rev&rev=471900 License text update per ASF board resolution. -- Philip M. Gollucci ([EMAIL PROTECTED]) 323.219.4708 Consultant / http://p6m7g8.net/Resume/resume.shtml Senior Software Engineer - TicketMaster - http://ticketmaster.com 1024D/A79997FA F357 0FDD 2301 6296 690F 6A47 D55A 7172 A799 97F I never had a dream come true 'Til the day that I found you. Even though I pretend that I've moved on You'll always be my baby. I never found the words to say You're the one I think about each day And I know no matter where life takes me to A part of me will always be... A part of me will always be with you.
[jira] Resolved: (MODPYTHON-195) Possible leaking of Win32 event handles when Apache restarted.
[ http://issues.apache.org/jira/browse/MODPYTHON-195?page=all ]
Graham Dumpleton resolved MODPYTHON-195.
Resolution: Fixed
Haven't been able to validate this first hand, but have accepted the following
change in python_init() to stop Win32 parent process performing global mutex
and Python initialisation.
#ifdef WIN32
/* No need to run python_init() in Win32 parent processes as
* the lack of fork on Win32 means we get no benefit as far as
* inheriting a preinitialized Python interpreter. Further,
* upon a restart on Win32 platform the python_init() function
* will be called again in the parent process but without some
* resources allocated by the previous call having being
* released properly, resulting in memory and Win32 resource
* leaks.
*/
if (!getenv("AP_PARENT_PID"))
return OK;
#endif /* WIN32 */
See MODPYTHON-195 thread at:
http://mail-archives.apache.org/mod_mbox/httpd-python-dev/200611.mbox/thread
starting with:
http://mail-archives.apache.org/mod_mbox/httpd-python-dev/200611.mbox/[EMAIL
PROTECTED]
> Possible leaking of Win32 event handles when Apache restarted.
> --
>
> Key: MODPYTHON-195
> URL: http://issues.apache.org/jira/browse/MODPYTHON-195
> Project: mod_python
> Issue Type: Bug
> Components: core
>Affects Versions: 3.2.10
>Reporter: Graham Dumpleton
> Assigned To: Graham Dumpleton
> Fix For: 3.3
>
>
> Jeff Robins in:
>
> http://mail-archives.apache.org/mod_mbox/httpd-python-dev/200610.mbox/[EMAIL
> PROTECTED]
> indicates a belief that when an Apache restart is performed on Windows that
> there are a number of Win32 event handles leaked. His belief is that this
> seems to be linked to mod_python.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Work started: (MODPYTHON-195) Possible leaking of Win32 event handles when Apache restarted.
[ http://issues.apache.org/jira/browse/MODPYTHON-195?page=all ] Work on MODPYTHON-195 started by Graham Dumpleton. > Possible leaking of Win32 event handles when Apache restarted. > -- > > Key: MODPYTHON-195 > URL: http://issues.apache.org/jira/browse/MODPYTHON-195 > Project: mod_python > Issue Type: Bug > Components: core >Affects Versions: 3.2.10 >Reporter: Graham Dumpleton > Assigned To: Graham Dumpleton > Fix For: 3.3 > > > Jeff Robins in: > > http://mail-archives.apache.org/mod_mbox/httpd-python-dev/200610.mbox/[EMAIL > PROTECTED] > indicates a belief that when an Apache restart is performed on Windows that > there are a number of Win32 event handles leaked. His belief is that this > seems to be linked to mod_python. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (MODPYTHON-195) Possible leaking of Win32 event handles when Apache restarted.
[ http://issues.apache.org/jira/browse/MODPYTHON-195?page=all ] Graham Dumpleton reassigned MODPYTHON-195: -- Assignee: Graham Dumpleton > Possible leaking of Win32 event handles when Apache restarted. > -- > > Key: MODPYTHON-195 > URL: http://issues.apache.org/jira/browse/MODPYTHON-195 > Project: mod_python > Issue Type: Bug > Components: core >Affects Versions: 3.2.10 >Reporter: Graham Dumpleton > Assigned To: Graham Dumpleton > Fix For: 3.3 > > > Jeff Robins in: > > http://mail-archives.apache.org/mod_mbox/httpd-python-dev/200610.mbox/[EMAIL > PROTECTED] > indicates a belief that when an Apache restart is performed on Windows that > there are a number of Win32 event handles leaked. His belief is that this > seems to be linked to mod_python. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[STATUS] (httpd-trunk) Wed Nov 8 23:50:46 2006
APACHE 2.3 STATUS: -*-text-*-
Last modified at [$Date: 2006-08-22 16:41:03 -0400 (Tue, 22 Aug 2006) $]
The current version of this file can be found at:
* http://svn.apache.org/repos/asf/httpd/httpd/trunk/STATUS
Documentation status is maintained seperately and can be found at:
* docs/STATUS in this source tree, or
* http://svn.apache.org/repos/asf/httpd/httpd/trunk/docs/STATUS
Consult the following STATUS files for information on related projects:
* http://svn.apache.org/repos/asf/apr/apr/trunk/STATUS
* http://svn.apache.org/repos/asf/apr/apr-util/trunk/STATUS
Patches considered for backport are noted in their branches' STATUS:
* http://svn.apache.org/repos/asf/httpd/httpd/branches/1.3.x/STATUS
* http://svn.apache.org/repos/asf/httpd/httpd/branches/2.0.x/STATUS
* http://svn.apache.org/repos/asf/httpd/httpd/branches/2.2.x/STATUS
Release history:
[NOTE that x.{odd}.z versions are strictly Alpha/Beta releases,
while x.{even}.z versions are Stable/GA releases.]
2.3.0 : in development
Contributors looking for a mission:
* Just do an egrep on "TODO" or "XXX" in the source.
* Review the bug database at: http://issues.apache.org/bugzilla/
* Review the "PatchAvailable" bugs in the bug database:
https://issues.apache.org/bugzilla/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&product=Apache+httpd-2&keywords=PatchAvailable
After testing, you can append a comment saying "Reviewed and tested".
* Open bugs in the bug database.
CURRENT RELEASE NOTES:
RELEASE SHOWSTOPPERS:
* Handling of non-trailing / config by non-default handler is broken
http://marc.theaimsgroup.com/?l=apache-httpd-dev&m=105451701628081&w=2
jerenkrantz asks: Why should this block a release?
wsanchez agrees: this may be a change in behavior, but isn't
clearly wrong, and even if so, it doesn't seem like a
showstopper.
* the edge connection filter cannot be removed
http://marc.theaimsgroup.com/?l=apache-httpd-dev&m=105366252619530&w=2
jerenkrantz asks: Why should this block a release?
stas replies: because it requires a rewrite of the filters stack
implementation (you have suggested that) and once 2.2 is
released you can't do that anymore.
CURRENT VOTES:
* If the parent process dies, should the remaining child processes
"gracefully" self-terminate. Or maybe we should make it a runtime
option, or have a concept of 2 parent processes (one being a
"hot spare").
See: Message-ID: <[EMAIL PROTECTED]>
Self-destruct: Ken, Martin, Lars
Not self-destruct: BrianP, Ian, Cliff, BillS
Make it runtime configurable: Aaron, jim, Justin, wrowe, rederpj, nd
/* The below was a concept on *how* to handle the problem */
Have 2 parents: +1: jim
-1: Justin, wrowe, rederpj, nd
+0: Lars, Martin (while standing by, could it do
something useful?)
* Make the worker MPM the default MPM for threaded Unix boxes.
+1: Justin, Ian, Cliff, BillS, striker, wrowe, nd
+0: BrianP, Aaron (mutex contention is looking better with the
latest code, let's continue tuning and testing), rederpj, jim
-0: Lars
pquerna: Do we want to change this for 2.2?
RELEASE NON-SHOWSTOPPERS BUT WOULD BE REAL NICE TO WRAP THESE UP:
* Patches submitted to the bug database:
http://issues.apache.org/bugzilla/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&product=Apache+httpd-2&keywords=PatchAvailable
* Filter stacks and subrequests, redirects and fast redirects.
There's at least one PR that suffers from the current unclean behaviour
(which lets the server send garbage): PR 17629
nd says: Every subrequest should get its own filter stack with the
subreq_core filter as bottom-most. That filter does two things:
- swallow EOS buckets
- redirect the data stream to the upper request's (rr->main)
filter chain directly after the subrequest's starting
point.
Once we have a clean solution, we can try to optimize
it, so that the server won't be slow down too much.
* RFC 2616 violations.
Closed PRs: 15857.
Open PRs: 15852, 15859, 15861, 15864, 15865, 15866, 15868, 15869,
15870, 16120, 16125, 16126, 16133, 16135, 16136, 16137,
16138, 16139, 16140, 16142, 16518, 16520, 16521,
jerenkrantz says: need to decide how many we need to backport and/or
if these rise to showstopper status.
wrowe suggests: it would be nice to see "MUST" v.s. "SHOULD" v.s. "MAY"
out of this list, without reviewing them individually.
* There is a bug i
[STATUS] (httpd-2.0) Wed Nov 8 23:51:40 2006
APACHE 2.0 STATUS: -*-text-*- Last modified at [$Date: 2006-09-13 15:45:30 -0400 (Wed, 13 Sep 2006) $] The current version of this file can be found at: * http://svn.apache.org/repos/asf/httpd/httpd/branches/2.0.x/STATUS Documentation status is maintained seperately and can be found at: * docs/STATUS in this source tree, or * http://svn.apache.org/repos/asf/httpd/httpd/branches/2.0.x/docs/STATUS Consult the following STATUS files for information on related projects: * http://svn.apache.org/repos/asf/apr/apr/branches/0.9.x/STATUS * http://svn.apache.org/repos/asf/apr/apr-util/branches/0.9.x/STATUS Consult the trunk/ for all new development and documentation efforts: * http://svn.apache.org/repos/asf/httpd/httpd/trunk/STATUS * http://svn.apache.org/repos/asf/httpd/httpd/trunk/docs/STATUS Release history: 2.0.60 : in maintenance 2.0.59 : tagged July 27, 2006 2.0.58 : released May 1, 2006 as GA. 2.0.57 : tagged April 19, 2006, not released. 2.0.56 : tagged April 16, 2006, not released. 2.0.55 : released October 16, 2005 as GA. 2.0.54 : released April 17, 2005 as GA. 2.0.53 : released February 7, 2005 as GA. 2.0.52 : released September 28, 2004 as GA. 2.0.51 : released September 15, 2004 as GA. 2.0.50 : released June 30, 2004 as GA. 2.0.49 : released March 19, 2004 as GA. 2.0.48 : released October 29, 2003 as GA. 2.0.47 : released July 09, 2003 as GA. 2.0.46 : released May 28, 2003 as GA. 2.0.45 : released April 1, 2003 as GA. 2.0.44 : released January 20, 2003 as GA. 2.0.43 : released October 3, 2002 as GA. 2.0.42 : released September 24, 2002 as GA. 2.0.41 : rolled September 16, 2002. not released. 2.0.40 : released August 9, 2002 as GA. 2.0.39 : released June 17, 2002 as GA. 2.0.38 : rolled June 16, 2002. not released. 2.0.37 : rolled June 11, 2002. not released. 2.0.36 : released May 6, 2002 as GA. 2.0.35 : released April 5, 2002 as GA. 2.0.34 : tagged March 26, 2002. 2.0.33 : tagged March 6, 2002. not released. 2.0.32 : released Feburary 16, 2002 as beta. 2.0.31 : rolled Feburary 1, 2002. not released. 2.0.30 : tagged January 8, 2002. not rolled. 2.0.29 : tagged November 27, 2001. not rolled. 2.0.28 : released November 13, 2001 as beta. 2.0.27 : rolled November 6, 2001 2.0.26 : tagged October 16, 2001. not rolled. 2.0.25 : rolled August 29, 2001 2.0.24 : rolled August 18, 2001 2.0.23 : rolled August 9, 2001 2.0.22 : rolled July 29, 2001 2.0.21 : rolled July 20, 2001 2.0.20 : rolled July 8, 2001 2.0.19 : rolled June 27, 2001 2.0.18 : rolled May 18, 2001 2.0.17 : rolled April 17, 2001 2.0.16 : rolled April 4, 2001 2.0.15 : rolled March 21, 2001 2.0.14 : rolled March 7, 2001 2.0a9 : released December 12, 2000 2.0a8 : released November 20, 2000 2.0a7 : released October 8, 2000 2.0a6 : released August 18, 2000 2.0a5 : released August 4, 2000 2.0a4 : released June 7, 2000 2.0a3 : released April 28, 2000 2.0a2 : released March 31, 2000 2.0a1 : released March 10, 2000 Contributors looking for a mission: * Just do an egrep on "TODO" or "XXX" in the source. * Review the bug database at: http://issues.apache.org/bugzilla/ * Review the "PatchAvailable" bugs in the bug database: http://issues.apache.org/bugzilla/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&product=Apache+httpd-2.0&keywords=PatchAvailable After testing, you can append a comment saying "Reviewed and tested". * Open bugs in the bug database. CURRENT RELEASE NOTES: * Forward binary compatibility is expected of Apache 2.0.x releases, such that no MMN major number changes will occur. Such changes can only be made in the trunk. * All commits to branches/2.0.x must be reflected in SVN trunk, as well, if they apply. Logical progression is commit to trunk, get feedback and votes on list or in STATUS, then merge into branches/2.2.x, and finally merge into branches/2.0.x, as applicable. RELEASE SHOWSTOPPERS: PATCHES ACCEPTED TO BACKPORT FROM TRUNK: [ start all new proposals below, under PATCHES PROPOSED. ] PATCHES PROPOSED TO BACKPORT FROM TRUNK: [ please place SVN revisions from trunk here, so it is easy to identify exactly what the proposed changes are! Add all new proposals to the end of this list. ] *) Reverse Proxy fixes: bug and Cookie support Patch is at http://people.apache.org/~colm/httpd-2.0-reverse-proxy-cookie.patch and is in production with Clients. +1: niq, wrowe wrowe adds; looks good, no way to apply this without a minor bump *) Backport 102870; PR 17217; stop linking OpenSSL .so's to support/* binaries (especi
Re: Version 2.0.59 missing in bugzilla.
On Wed, 08 Nov 2006 22:19:28 +0100 Ruediger Pluem <[EMAIL PROTECTED]> wrote: > Could someone please add version 2.0.59 to bugzilla for the product > Apache httpd-2? Good point. That keeps happening. 'Twould be a Good Thing if updating bugzilla were integrated into the release process. -- Nick Kew Application Development with Apache - the Apache Modules Book http://www.apachetutor.org/
[jira] Created: (MODPYTHON-202) Allow mechanism used by global mutex locks to be specified.
Allow mechanism used by global mutex locks to be specified. --- Key: MODPYTHON-202 URL: http://issues.apache.org/jira/browse/MODPYTHON-202 Project: mod_python Issue Type: New Feature Components: core Affects Versions: 3.2.10 Reporter: Graham Dumpleton When using experimental Apache ITK MPM, described at: http://home.samfundet.no/~sesse/mpm-itk/ global mutex locks will fail if Apache used semaphores because requests against different virtual hosts run as different users and user will not have permission to access the semaphore to lock it. See: http://www.modpython.org/pipermail/mod_python/2006-November/022536.html for original mailing list post about this from Sam Morris. A suggested fix of finding a specific mechanism that works rather than default used by Apache, seems to work: http://www.modpython.org/pipermail/mod_python/2006-November/022537.html http://www.modpython.org/pipermail/mod_python/2006-November/022538.html http://www.modpython.org/pipermail/mod_python/2006-November/022539.html If available MPMs with such constraints are going to appear, may make sense to have an option to configure which allows one to override at compile time the default mechanism used for global mutex locks so that it can be made to match what may be required for a specific MPM that Apache is compiled to use. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Version 2.0.59 missing in bugzilla.
On Nov 8, 2006, at 3:19 PM, Ruediger Pluem wrote: Could someone please add version 2.0.59 to bugzilla for the product Apache httpd-2? Done. S. -- [EMAIL PROTECTED]http://www.temme.net/sander/ PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF smime.p7s Description: S/MIME cryptographic signature
Re: Apache BUG: 36495 : ajp_proxy_connect_backend failure
On 11/08/2006 10:28 PM, Ruediger Pluem wrote: > > On 11/08/2006 08:18 AM, Benjamin Cuthbert wrote: > >>This happens when i have one connection to the tomcat jboss server. > > > Sorry for a possible confusion I might create. As the patch Mladen talks about > was backported today you can checkout the latest 2.2.x branch via > svn export http://svn.apache.org/repos/asf/httpd/httpd/branches/2.2.x > httpd-2.2.x Argh. Sorry I confused some patches. Forget about what I just said. This code is only in trunk. Sorry for the confusiion created. Regards Rüdiger
Re: Is ap_pass_brigade sychronous
On 11/08/2006 07:30 PM, Joachim Zobel wrote: > Hi. > > I would like to know if ap_pass_brigade is and will remain synchronous > on all mpms. Can I assume that all memory used by the passed buckets can > be freed after calling ap_pass_brigade? I cannot predict the future for major releases, but for the current stable releases I would say: yes. If filters down in the chain do not want to process (parts of) a brigade immediately, they should set these parts aside in a temporary brigade (see also ap_save_brigade). Regards Rüdiger
Re: Apache BUG: 36495 : ajp_proxy_connect_backend failure
On 11/08/2006 08:18 AM, Benjamin Cuthbert wrote: > This happens when i have one connection to the tomcat jboss server. Sorry for a possible confusion I might create. As the patch Mladen talks about was backported today you can checkout the latest 2.2.x branch via svn export http://svn.apache.org/repos/asf/httpd/httpd/branches/2.2.x httpd-2.2.x With this you are closer to what you actual use with 2.2.0 then with the trunk. And 2.2.4 does not seem to be far away :-). Regards Rüdiger
Version 2.0.59 missing in bugzilla.
Could someone please add version 2.0.59 to bugzilla for the product Apache httpd-2? Thanks and regards Rüdiger
Re: mod_wombat
On 11/08/2006 07:16 PM, Paul Querna wrote: > > I am personally interested in it because I believe it could be one of > the paths taken for an httpd 3.0 in which Lua was embedded, replacing > the config system and other large areas of C code. What is bad about the C code? Regards Rüdiger
Re: mod_wombat
On 11/08/2006 07:31 PM, Brian McCallister wrote: > > On Nov 8, 2006, at 10:27 AM, Nick Kew wrote: > >> Just to be clear about it: presumably you're proposing it have >> a similar kind of status to mod_perl or mod_python? > > > Yes. +1 for this if it is a subproject like mod_perl or mod_python. It may go into the core or not in the future, but I think its dependency on libapreq2 which is *currently* not part of the core makes it impossible at the *current* point of time to add it to the core. Regards Rüdiger
Re: Time for 2.2.4?
On Nov 8, 2006, at 1:47 PM, Joe Orton wrote: On Wed, Nov 08, 2006 at 12:27:31PM -0500, Jim Jagielski wrote: Mladen Turk wrote: Jim Jagielski wrote: Looking over CHANGES and STATUS, I think we should start thinking about a 2.2.4 release. Comments? I would like to propose the backport of proxy alternate is_socket_connected. This is IMHO very crucial for AJP to work. Without that the loadbalancer is unusable for most platforms. I know that Bill is looking at a release of APR and that alternate method would, I think, be better implemented in APR than directly in httpd... Eww, no thanks. AFAIK the same results can be achieved using existing APR interfaces: a non-blocking apr_socket_recv() passing the MSG_PEEK flag, as I mentioned this on [EMAIL PROTECTED] already. I was referring to an APR apr_is_socket_connected() function. Seems to me that it's a common enough network "test" that providing it directly with an APR call is niceness.
Re: Time for 1.2.8, was Re: Time for 2.2.4?
Scroll back a half hour :)
Seriously - do folks need the extra day - or does anyone object to Friday
midday?
Paul Querna wrote:
> Jim Jagielski wrote:
>> Looking over CHANGES and STATUS, I think we should
>> start thinking about a 2.2.4 release. Comments?
>> I offer to be RM.
>
> I think we should start thinking about it too. I think we should also
> consider requesting that APR{,-Util} 1.2.8 gets done by the APR
> developers...
>
> With the APR hat on, I volunteer to RM a 1.2.x release of APR and
> APR-Util. How does this Saturday as a release cut time sound for everyone?
>
> -Paul
>
>
> .
>
Re: Time for 2.2.4?
On Wed, Nov 08, 2006 at 12:27:31PM -0500, Jim Jagielski wrote: > Mladen Turk wrote: > > > > Jim Jagielski wrote: > > > Looking over CHANGES and STATUS, I think we should > > > start thinking about a 2.2.4 release. Comments? > > > > I would like to propose the backport of proxy alternate > > is_socket_connected. This is IMHO very crucial > > for AJP to work. Without that the loadbalancer is > > unusable for most platforms. > > > > I know that Bill is looking at a release of APR and > that alternate method would, I think, be better > implemented in APR than directly in httpd... Eww, no thanks. AFAIK the same results can be achieved using existing APR interfaces: a non-blocking apr_socket_recv() passing the MSG_PEEK flag, as I mentioned this on [EMAIL PROTECTED] already. joe
Re: mod_wombat
On 11/8/06, Brian McCallister <[EMAIL PROTECTED]> wrote: Yes. I had thought it would be a good labs project, but as there is already outside interest, I think a lab wouldn't be the right path for it. I figured as much. If there are people who aren't yet ASF committers of some sort who are interested in the project, then clearly it's already beyond the "labs" stage ;-) -garrett
Re: mod_wombat
On Nov 8, 2006, at 10:24 AM, Garrett Rooney wrote: Seriously though, I want to see mod_lua here at the ASF eventually. I agree ;-) I had originally thought of it as a good example of a labs type project (assuming that labs.apache.org gets off the ground), but it certainly has the potential to grow into something more than that (with an actual community, releases, etc), and if that's the path that Brian wants to head down, the best home for it seems to be in the HTTP Server PMC. Yes. I had thought it would be a good labs project, but as there is already outside interest, I think a lab wouldn't be the right path for it. -Brian
Re: mod_wombat
Nick Kew wrote: On Wed, 08 Nov 2006 10:16:33 -0800 Paul Querna <[EMAIL PROTECTED]> wrote: Brian has expressed interest in brining mod_wombat to the ASF. Is there interest in this PMC to bring it in under us? Just to be clear about it: presumably you're proposing it have a similar kind of status to mod_perl or mod_python? I don't know. I am personally divided on the problem of sub-projects vs including things in the core. I think to start, it would be a separate project in release terms, but use [EMAIL PROTECTED], rather than spawning its own mailing lists? What do you think? -Paul
Re: mod_wombat
On Nov 8, 2006, at 10:27 AM, Nick Kew wrote: Just to be clear about it: presumably you're proposing it have a similar kind of status to mod_perl or mod_python? Yes. -Brian
Is ap_pass_brigade sychronous
Hi. I would like to know if ap_pass_brigade is and will remain synchronous on all mpms. Can I assume that all memory used by the passed buckets can be freed after calling ap_pass_brigade? Thx, Joachim
Re: mod_wombat
On 11/8/06, Garrett Rooney <[EMAIL PROTECTED]> wrote: Seriously though, I want to see mod_lua here at the ASF eventually. Oops, s/mod_lua/mod_wombat/ -garrett
Re: Time for 2.2.4?
Jim Jagielski wrote: Mladen Turk wrote: Anyhow, mod_jk works on all the platforms with the exact code like a charm ;) With my non-devil's-advocate hat on, the code itself is pretty basic Steven's anyway... It might be, not sure, but as Ferengi Rule 31 states: Never make fun of a Ferengi's mother ... insult something he cares about instead. Regards, Mladen.
Re: mod_wombat
On Wed, 08 Nov 2006 10:16:33 -0800 Paul Querna <[EMAIL PROTECTED]> wrote: > Brian has expressed interest in brining mod_wombat to the ASF. > > Is there interest in this PMC to bring it in under us? Just to be clear about it: presumably you're proposing it have a similar kind of status to mod_perl or mod_python? -- Nick Kew Application Development with Apache - the Apache Modules Book http://www.apachetutor.org/
Re: mod_wombat
On 11/8/06, Paul Querna <[EMAIL PROTECTED]> wrote: Thoughts? Big +1 from me, although you probably saw that coming ;-) Seriously though, I want to see mod_lua here at the ASF eventually. I had originally thought of it as a good example of a labs type project (assuming that labs.apache.org gets off the ground), but it certainly has the potential to grow into something more than that (with an actual community, releases, etc), and if that's the path that Brian wants to head down, the best home for it seems to be in the HTTP Server PMC. -garrett
mod_wombat
Brian has expressed interest in brining mod_wombat to the ASF. Is there interest in this PMC to bring it in under us? The overview of mod_wombat: mod_wombat ( https://svn.i-want-a-pony.com/repos/wombat/trunk/ ) was written primarily by Brian McCallister with random bits of help from Garrett Rooney and myself. It integrates the Lua scripting language into an Apache module. In the simplest form, you could call it just a 'mod_lua' that happens to be 100 times better than the existing 1.3 only mod_lua. However, it has started down the path of more 'deep' integration, beyond just a handler. The README contains more info, and a simple handler example of what it can do today: https://svn.i-want-a-pony.com/repos/wombat/trunk/README I am personally interested in it because I believe it could be one of the paths taken for an httpd 3.0 in which Lua was embedded, replacing the config system and other large areas of C code. Thoughts? -Paul
Re: Time for 2.2.4?
Mladen Turk wrote: > > Anyhow, mod_jk works on all the platforms with the > exact code like a charm ;) > With my non-devil's-advocate hat on, the code itself is pretty basic Steven's anyway... -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ "If you can dodge a wrench, you can dodge a ball."
Re: Time for 2.2.4?
I'd be willing to test the tarballs on win x64 (32-bit and 64-bit) and on vista (32-bit).
Re: Time for 2.2.4?
Jim Jagielski wrote: In any case, I don't see a backport in STATUS so it's all academic anyway ;) Sure, like said, I'd like to propose... Anyhow the code was tested on 2.4 and 2.6, Solaris 9+ and Windows. On those platforms it works. Could not tell for things like Netware, OS2 etc... Anyhow, mod_jk works on all the platforms with the exact code like a charm ;) Regards, Mladen.
Re: Time for 1.2.8, was Re: Time for 2.2.4?
while we are on the subject to of apr...May i ask why the lib's have a 1 appended to it in 2.2.x? Most (read nearly all) 3rd party modules link to the old filename.JorgeOn 11/8/06,
Paul Querna <[EMAIL PROTECTED]> wrote:
Jim Jagielski wrote:> Looking over CHANGES and STATUS, I think we should> start thinking about a 2.2.4 release. Comments?> I offer to be RM.I think we should start thinking about it too. I think we should also
consider requesting that APR{,-Util} 1.2.8 gets done by the APRdevelopers...With the APR hat on, I volunteer to RM a 1.2.x release of APR andAPR-Util. How does this Saturday as a release cut time sound for everyone?
-Paul-- ~Jorge
Re: Time for 2.2.4?
On Wed, 8 Nov 2006 08:34:27 -0500 Jim Jagielski <[EMAIL PROTECTED]> wrote: > Looking over CHANGES and STATUS, I think we should > start thinking about a 2.2.4 release. Comments? > I offer to be RM. Fairy nuff. I have some significant updates I'd like to add (stop mod_dbd generating bogus errors when unconfigured), but I guess that can wait for 2.2.5 if necessary. I'll try and find time to review other people's STATUS entries:-) And my comment on the PCRE thing: since it's not a regression from what we have already, you can take it as a -1 vote, not veto. -- Nick Kew Application Development with Apache - the Apache Modules Book http://www.apachetutor.org/
Re: Time for 2.2.4?
In any case, I don't see a backport in STATUS so it's all academic anyway ;)
Re: Time for 2.2.4?
Mladen Turk wrote: > > Jim Jagielski wrote: > > I know that Bill is looking at a release of APR and > > that alternate method would, I think, be better > > implemented in APR than directly in httpd... > > > > Sure it can be done, but in that case it would require at > least a minor version bump. > I have a proto that uses > APR_SO_DISCONNECTED inside the apr_socket_opt_get. > It's used on win32 only, an only for sendfile. > Anyhow, I have a proposal that will solve that even. > > Even if we port the APR_SO_DISCONNECTED to APR 1.2.8, > we would need to depend on that APR version, because > previous versions would behave in a different way. > > Think that portback of is_socket_connected would > impose less problems. > Except that it has not be as widely tested as I think we would like... Does it work with ANY system that defines LINUX, for example? Regardless of kernel level? We do have a "better" implementation of the old is_socket_connected() than in 2.2.3 in 2.2.4... Maybe a compile time flag? I'd like some easy way for someone to disable it if need be... For APR, I was simply thinking of apr_is_socket_connected() and yeah, 2.2.4 would require that version of APR... -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ "If you can dodge a wrench, you can dodge a ball."
Re: Time for 2.2.4?
On Nov 8, 2006, at 5:34 AM, Jim Jagielski wrote: Looking over CHANGES and STATUS, I think we should start thinking about a 2.2.4 release. Comments? I offer to be RM. I'll put your tarball code up on ajax and people if Joe doesn't beat me to it. S. -- [EMAIL PROTECTED]http://www.temme.net/sander/ PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF smime.p7s Description: S/MIME cryptographic signature
Time for 1.2.8, was Re: Time for 2.2.4?
Jim Jagielski wrote:
Looking over CHANGES and STATUS, I think we should
start thinking about a 2.2.4 release. Comments?
I offer to be RM.
I think we should start thinking about it too. I think we should also
consider requesting that APR{,-Util} 1.2.8 gets done by the APR
developers...
With the APR hat on, I volunteer to RM a 1.2.x release of APR and
APR-Util. How does this Saturday as a release cut time sound for everyone?
-Paul
Re: Time for 2.2.4?
Jim Jagielski wrote: I know that Bill is looking at a release of APR and that alternate method would, I think, be better implemented in APR than directly in httpd... Sure it can be done, but in that case it would require at least a minor version bump. I have a proto that uses APR_SO_DISCONNECTED inside the apr_socket_opt_get. It's used on win32 only, an only for sendfile. Anyhow, I have a proposal that will solve that even. Even if we port the APR_SO_DISCONNECTED to APR 1.2.8, we would need to depend on that APR version, because previous versions would behave in a different way. Think that portback of is_socket_connected would impose less problems. Regards, Mladen.
Re: Time for 2.2.4?
Mladen Turk wrote: > > Jim Jagielski wrote: > > Looking over CHANGES and STATUS, I think we should > > start thinking about a 2.2.4 release. Comments? > > I would like to propose the backport of proxy alternate > is_socket_connected. This is IMHO very crucial > for AJP to work. Without that the loadbalancer is > unusable for most platforms. > I know that Bill is looking at a release of APR and that alternate method would, I think, be better implemented in APR than directly in httpd... -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ "If you can dodge a wrench, you can dodge a ball."
Re: Time for 2.2.4?
Jim Jagielski wrote: Looking over CHANGES and STATUS, I think we should start thinking about a 2.2.4 release. Comments? I would like to propose the backport of proxy alternate is_socket_connected. This is IMHO very crucial for AJP to work. Without that the loadbalancer is unusable for most platforms. I offer to be RM. +1 Regards, Mladen.
Re: Time for 2.2.4?
Jim Jagielski wrote: > Looking over CHANGES and STATUS, I think we should > start thinking about a 2.2.4 release. Comments? > I offer to be RM. Yes - we need to, +1, and I'd offered to RM APR... we've been whittling down the apr bug list (primarily platform-by-platform quirks.) I can have APR tarball to vote on this friday (discuss @ APR) if you would like to roll with the next APR bump.
Time for 2.2.4?
Looking over CHANGES and STATUS, I think we should start thinking about a 2.2.4 release. Comments? I offer to be RM.
Re: MODPYTHON-195
On 07/11/2006, at 10:51 PM, Jeff Robbins wrote:
Graham,
The problem on Win32 is that (I believe) we never want to
initialize Python in the persistent parent process. All the web
action is in the child process which is long-lived and it is this
child process that maintains the thread pool which services web
requests.
FWIW, in UNIX the initialisation of Python in the parent process is a
good thing
as it means it is only done once no matter how many child processes
there
are. This is because child processes are created as a fork of the
parent process
and so they inherit the already initialised Python interpreter,
thereby meaning
initialisation of the child process is quicker.
Since Win32 doesn't have an equivalent of fork, when the child process
is created the full Python initialisation is done anyway. Thus
avoiding the
initialisation of Python in the parent is probably reasonable.
The parent process as far as I can tell sits there to support
restarting the child process and support the Win32 Service Control
Manager (SCM) which has a protocol for how a process must respond
to certain messages in order to be a service on Win32.
I do not know how to use flags alone to distinguish the two
processes. The code I put in is not trying to restrict a call to
python_init() to only happen once in the parent process. It is
preventing python_init() from initializing Python in the parent
process.
I hope this clarifies things somewhat.
I want to note here that mpm_winnt.c line 1108 looks like this:
/* AP_PARENT_PID is only valid in the child */
pid = getenv("AP_PARENT_PID");
if (pid)
{
/* This is the child */
This environmental is how it knows to run certain code only in the
child process.
In summary,
if we do not want to run python_init() in the special Win32 parent
process, we need a way to distinguish this parent process from the
child process in which we DO want to run python_init(). The code
which maintains this dual process architecture (undoubtedly in
support of the Win32 service architecture) uses an environmental
that it purposefull creates and injects into the child process
"AP_PARENT_PID". I don't see how we can do better than use this
same distinguishing characterisic to know not to run python_init()
in the parent process.
As it stands I just may have to take you word on this as I don't have
first hand
access to Win32 platform (and don't want to) to experiment. The
AP_PARENT_PID
environment variable is at least present in all Apache 2.0 and 2.2
versions that
we support, so at least okay for a while if we rely on that. In the
future, if Apache
changes this, we will just need to accommodate any new/official way
of determining
it.
Anyway, is the following what you are expecting and is it placed
where you expect
it within the python_init() function?
static int initialized = 0;
#ifdef WIN32
/* No need to run python_init() in Win32 parent processes as
* the lack of fork on Win32 means we get no benefit as far as
* inheriting a preinitialized Python interpreter. Further,
* upon a restart on Win32 platform the python_init() function
* will be called again in the parent process but without some
* resources allocated by the previous call having being
* released properly, resulting in memory and Win32 resource
* leaks.
*/
if (!getenv("AP_PARENT_PID"))
return OK;
#endif /* WIN32 */
apr_pool_userdata_get(&data, userdata_key, s->process->pool);
if (!data) {
apr_pool_userdata_set((const void *)1, userdata_key,
apr_pool_cleanup_null, s->process->pool);
return OK;
}
Graham
Re: De-Chunking
Christian V. wrote: Nick Kew wrote: On Tue, 07 Nov 2006 11:24:05 +0100 "Christian V." <[EMAIL PROTECTED]> wrote: Hi , i 'm running a third-party web service authentication module that hangs when the request coming from the client is splitted out in different chunks. I don't have access to the module and to the client neither, so I'm thinking to write an input filter that collects all the chunks and pass'em to the downstream filter or handler . Is that possible? It's possible, yes. Whether it'll fix the problem for you is not certain. I'd suggest starting with a quick hack (or a dechunking proxy in front of your server) to test it first, if you really can't get the source. Maybe the Proxy will fix it but it will not be the solution, so i think i'm gonna write the module-filter. But i need to know how Apache handle multi chunk request, as im not able to find this information. Is request coming entirely to my filter in the form of bucket&brigades then passed to down-streams module or brigades are passed down as soon as they come? (I hope i explained it well) Tnx a lot, Chris. Let me explain well as im not 100% sure the problem is the 3rd party module, and other people may had met the same issue: [ CLIENT ] --> [ APACHE R.PROXY (SSL) + 3rd MODULE ] --> [WEB SERVICE] The Web Service receives requests from both Java and .net clients. Our problem is the following. The .Net clients (we have one in c# and one in VB, both programmed with visual studio 2005 ) will split the client's XML request in multiple 1024 byte packets. This happens only over HTTPS, and causes problems with the 3rd party module To debug this we have programmed an apache module on the reverse proxy that dumps the stream of data as it receives it from the clients, and our .Net client, over HTTPS, splits it up in multiple chunks, as seen here: [Tue Oct 31 15:09:56 2006] [notice] (IN) bucketdumper: mode READBYTES; blocking; 8192 bytes [Tue Oct 31 15:09:57 2006] [notice] (IN) - (AFTER bucket_read) -\tbucketdumper:\tbytes: 1024 - lenght read: 1024 - data: http://schemas.xmlsoap.org/soap/envelope/"; xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"; xmlns:tns="http://www.acme.com.com/wsdl/HelloMoto.wsdl"; xmlns:types="http://www.acme.com.com/wsdl/HelloMoto.wsdl/encodedTypes"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xmlns:xsd="http://www.w3.org/2001/XMLSchema";>http://schemas.xmlsoap.org/soap/encoding/";>TESTESTESTESTESTESTESTESTESTESTESTEST - [Tue Oct 31 15:09:58 2006] [notice] (IN) - (AFTER bucket_read) -\tbucketdumper:\tbytes: 0 - lenght read: 0 - data: > - Note how the XML is 1025 bytes long, and gets send in one 1024 byte packet first, followed by a second 1 byte packet (that contains just the final ">"). This does not happen over HTTP, where the entire XML arrives in one 1025 byte long data chunk. Also, our Java clients do not split up the XML when posting in HTTPS, independently of how long it is. Here is a request made by one of our java clients: [Tue Oct 31 15:12:57 2006] [notice] (IN) bucketdumper: mode READBYTES; blocking; 8192 bytes [Tue Oct 31 15:12:57 2006] [notice] (IN) - (AFTER bucket_read) -\tbucketdumper:\tbytes: 4333 - lenght read: 4333 - data: http://schemas.xmlsoap.org/soap/envelope/"; xmlns:xsd="http://www.w3.org/2001/XMLSchema"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>http://prognosiRiservata.acme.com";>http://";>LIVhttp://";>TESThttp://"/>http://";>falsehttp://data.prognosiRiservata.acme.com";>truehttp://Livorno.data.prognosiRiservata.acme.com";>truehttp://Livorno.data.prognosiRiservata.acme.com";>true - [Tue Oct 31 15:12:57 2006] [notice] (IN) Complete Bucket : [Tue Oct 31 15:12:57 2006] [notice] (IN) bucketdumper: mode READBYTES; blocking; 8192 bytes [Tue Oct 31 15:12:57 2006] [notice] (IN) - (AFTER bucket_read) -\tbucketdumper:\tbytes: 0 - lenght read: 0 - data: - Notice how the XML (4333 bytes long) is sent in one entire chunk. --- I realized that my initial idea of having an input filter is not applicable as long as the 3rd party module lives in the authentication/authorization phase, accessing data before any input filter. Ummm... The DeChunking-Proxy hypothesis seems to be, at present, the only valid solution! :-( Chris.
