On Thu, Dec 13, 2007 at 09:50:46PM -0500, Hammer, Tim wrote:
I am attempting to upgrade httpd from 1.3.x to 2.2.x for our web
application. I have managed to get everything building and working,
...
As you can see, the call from mod_ssl.so into the buckets/ code is
passing a null pointer.
On Fri, 14 Dec 2007 08:35:12 -0500
Mike O'Leary [EMAIL PROTECTED] wrote:
I am looking to write an Apache module that maintains a pool of socket
connections to a back-end server.
mod_proxy does that.
Alternatively, you could look at mod_dbd, which maintains a pool
of database connections.
--
Hello folks,
Has anyone come across a similar situation before? Can a target folder be
specified or is that not possible?
Any help is greatly appreciated.
Subra
On Dec 13, 2007 12:05 PM, Subra A Narayanan [EMAIL PROTECTED] wrote:
Hello folks,
I use the following command to compile my
On Thu, Dec 13, 2007 at 09:50:46PM -0500, Hammer, Tim wrote:
I am attempting to upgrade httpd from 1.3.x to 2.2.x for our web
application. I have managed to get everything building and working,
...
As you can see, the call from mod_ssl.so into the buckets/ code is
passing a null
On Fri, Dec 14, 2007 at 11:01:09AM -0500, Hammer, Tim wrote:
No, I am trying to use the new (2.2.x) mod_ssl with our modules that
have been ported from 1.3.x to 2.2.x. However, the port did not
convert our modules to use buckets and I am wondering if the new mod_ssl
is requiring the content
Joe,
Thanks for ur reply.
Let me clarify somethingWhen I said I didnt get any helpful responses, I
meant I didn't get any answers as to what is wrong with gcc and why the
module was behaving the way it was.
Anywayspoint taken.will use apxs for compiling the module.
Subra
On Dec
On Fri, 2007-12-14 at 08:07 -0500, Subra A Narayanan wrote:
Hello folks,
Hello folk,
your problem has nothing to do with apxs. The .libs directory is
created by libtool. You might want to contact the helpful dwellers on
the libtool mailing list.
Has anyone come across a similar situation
On Fri, 2007-12-14 at 11:05 -0500, Subra A Narayanan wrote:
Joe,
Thanks for ur response.
The reason I wanted to change the target directory was because my apache
module is being compiled as one of the components of a much larger makefile.
All the other shared libraries generated by this
Ralf/Joe,
Now I am trying to (just) compile my module using apxs and I see this
warning
*$ /usr/sbin/apxs -c -L /myprj/deps/axis2c/lib -L /myprj/lib/ -l
axutil -l axis2_engine -l dl -l pthread -l client -l operations -c
/myprj/obj/webservices/mod_my.o /myprj/obj/webservices/dispatcher.o
On Fri, 14 Dec 2007 16:57:28 -0500
Subra A Narayanan [EMAIL PROTECTED] wrote:
PLEASE LEARN TO POST! In particular, don't append
someone else's post to yours.
Now I am trying to (just) compile my module using apxs and I see this
warning
*$ /usr/sbin/apxs -c -L /myprj/deps/axis2c/lib -L
On Dec 14, 2007 6:05 PM, John Zhang [EMAIL PROTECTED] wrote:
When my module processes requests, I see a consistent
memory increase. It is like the memories were never
released. I am using the apr_* functions to allocate
memory (most of the time from the request-pool). My
understanding is
--- Eric Covener [EMAIL PROTECTED] wrote:
It should level out as each thread in the process
has had a chance to
run and allocate some memory for a range of
requests. MaxMemFree can
be used to return the heap memory that would
otherwise be used by
subsequent requests on that thread.
I am using the apr_* functions to allocate
memory (most of the time from the request-pool).
If there are few places where you allocate from
othr than the reqquest pool, I'd look at those first.
--
Ray B. Morris
[EMAIL PROTECTED]
Strongbox - The next generation in site security:
-Ursprüngliche Nachricht-
Von: Jiri Tulach - Position
Gesendet: Freitag, 14. Dezember 2007 08:39
An: dev@httpd.apache.org
Betreff: Re: mod_proxy in Apache 2.2 and HTTP_INTERNAL_SERVER_ERROR
It's possible fault of mod_fastcgi which returns
HTTP_INTERNAL_SERVER_ERROR in cases
Jiri Tulach - Position wrote:
It's possible fault of mod_fastcgi which returns
HTTP_INTERNAL_SERVER_ERROR in cases when server is overloaded or
external fastcgi instances are unavailable. Unfortunately mod_fastcgi is
not actively developed even thought lot of people use it in production
On Fri, 14 Dec 2007 09:43:12 +0100
jean-frederic clere [EMAIL PROTECTED] wrote:
But I still don't understand why proxy which has an option to get
proper data from another (probably) working server stops trying to
failover. I think from proxy point of view it doesn't matter why
server is
Hello,
sorry, but I don't agree :(.
1. HTTP_INTERNAL_SERVER_ERROR can be the result of an internal proxy problem.
In this case it would be wrong failing over.
This means that current implementation mixes internal errors with errors on
back end. I suggest to consider implementing different
-Ursprüngliche Nachricht-
Von: Jim Jagielski
Gesendet: Freitag, 14. Dezember 2007 14:49
An: dev@httpd.apache.org
Betreff: Re: time for 1.3.40 and 2.2.7 ?
Anyone opposed to us shooting for a TR early next week?
No. Let's rock.
I offer to RM
Thanks for doing so.
Regards
Anyone opposed to us shooting for a TR early next week?
I offer to RM
I am looking to write an Apache module that maintains a pool of socket
connections to a back-end server. When a request for the module comes in, a
connection from the pool would be grabbed and the data sent to the back-end
server. I want persistent connections to the back-end server; constantly
Subra A Narayanan wrote:
Hello folks,
Has anyone come across a similar situation before? Can a target folder be
specified or is that not possible?
Any help is greatly appreciated.
Subra
The .libs directory is specified by the libtool command, not by the apxs
tool. However, this is
Jim Jagielski wrote:
Anyone opposed to us shooting for a TR early next week?
If we can get a couple of security-related-but-not-really patches
committed to 2.0 I'd like to see that as well. I'm offering, but
if you would enjoy it, I'll just focus on win32 src/binary packages
all around.
Bill
On Dec 14, 2007, at 12:52 PM, William A. Rowe, Jr. wrote:
Jim Jagielski wrote:
Anyone opposed to us shooting for a TR early next week?
If we can get a couple of security-related-but-not-really patches
committed to 2.0 I'd like to see that as well. I'm offering,
Sure... that would be
Den Friday 14 December 2007 20.24.35 skrev Jim Jagielski:
On Dec 14, 2007, at 12:52 PM, William A. Rowe, Jr. wrote:
Jim Jagielski wrote:
Anyone opposed to us shooting for a TR early next week?
If we can get a couple of security-related-but-not-really patches
committed to 2.0 I'd like to
Oden Eriksson wrote:
Den Friday 14 December 2007 20.24.35 skrev Jim Jagielski:
From what I can see, both 1.3 and 2.2 are backport
free, so it's just 2.0 right now.
Yup - and the review of significant 2.0 patches would only take
an hour or two, it's not that complex - things that were
William A. Rowe, Jr. wrote:
There's a simple way of not-so-rudely saying ...
Sorry if this came across harshly Odin, I watch those dialogs
daily on php-dev, I'd hate to see httpd-dev polluted with the
same volume of self interest and vitriol. Let me make sure
I answered what you might have
On Fri, Dec 14, 2007 at 11:01:09AM -0500, Hammer, Tim wrote:
No, I am trying to use the new (2.2.x) mod_ssl with our
modules that
have been ported from 1.3.x to 2.2.x. However, the port did not
convert our modules to use buckets and I am wondering if the new
mod_ssl is requiring
On 12/14/2007 08:24 PM, Jim Jagielski wrote:
On Dec 14, 2007, at 12:52 PM, William A. Rowe, Jr. wrote:
Jim Jagielski wrote:
Anyone opposed to us shooting for a TR early next week?
If we can get a couple of security-related-but-not-really patches
committed to 2.0 I'd like to see that as
Hi,
Jim Jagielski schrieb:
From what I can see, both 1.3 and 2.2 are backport
free, so it's just 2.0 right now.
maybe a good candidate for inclusion in 2.0 would be
http://issues.apache.org/bugzilla/show_bug.cgi?id=43943
shmcb crash on Sparc when compiled with gcc 4.
It has been fixed with
29 matches
Mail list logo
