Re: mod_webapp.so socketpool changes..
Hi, I'm a bit confused about the problem with the use of the APR atomic types. Is the problem that it is not supported on all platforms? If this is the case then isn't this a problem with the apr code? Even if a given OS doesn't specifically offer atomic types then (as menioned earlier) a simple mutex and int in a struct offers the same functionality. As far as I can see, all this wrapping should be part of the apr, shouldn't it? I think puting in #ifdef APR_USE_ATOMICS is a bit of band-aid solution; Whether or not atomics are OS supported the variables in question should really be only operated on atomically (in a multi-threaded environment) or else the code is not thread-safe. Also, I don't know if this has got anything to do with the compilation problems found but when I first put in the atomics I found that the implementation in the (fairly recent) version of the apr I had was broken (on NT) and caused compilation to fail. Getting the latest version fixed this problem. BTW Pier, sorry for not responding earlier - I managed to get the mod_webapp module compiling for Apache 2 after tweaking the 1.3 makefile to get a 2.0 makefile for NT. I used the apr directly from the Apache 2.0 distribution. At the moment I am using Apache 2.0 on an NT intranet server with the mod_webapp at it seems to behave identically to the 1.3 version. PS. If you want me to make any changes modifications (either changing the #ifdef or anything else) to the warp connector just let me know PPS. I noticed a comment about mod_webapp being deprecated. Is this the case? Simon. [EMAIL PROTECTED] wrote: Pier Fumagalli wrote: Cavan Morris [EMAIL PROTECTED] wrote: Attached is an ASCII file with my build process. It may be important to not that I'm using the APR libraries from the webapp-module-1.0.2-tc402 and apxs from apache 2.0.32 not 2.0.35. You _need_ to use the APR libraries shipped with your Apache 2.0 version, and the same APXS, anyway it's bloated on my system as well. I have some spare time on my hands tonight, and tomorrow... I'll try to revamp the autoconf stuff and make it build again... NOTE I might break something in Win32 builds. Can someone with MSVC give it a go once they see my commits, please? /NOTE Question: when you say Yes, that's right... do you mean yes that's right, the socketpool work may solve bug 8433 or yes that's right, it doesn't compile? The #if APR_HAS_THREADS is wrong that should have been #if APR_HAS_ATOMIC. But APR_HAS_ATOMIC is not existing and it is not possible to force APR to use a generic C code for atomics (apr_force_atomic_generic cannot be set to one via some configure options). Therefore when apr_atomic_t is not defined mod_webapp compilation failed miserably. I will try to change the #if APR_HAS_THREADS into #ifdef USE_ATOMICS like in the mod_mem_cache.c of httpd-2.0. (As a temporary fix). Both... Yeah, the socketpool solves that problem as well (at least it should, what's your worker configuration in Apache 2.0? - output of httpd -l please :) and yes, it doesn't compile... On APR they're talking about removing atomics, since those bits actually depend (especially on sun hardware) on some opcodes present only on V9 architectures (JF might explain it better than me, the only 2 RISCs I've coded for are PPCs and MIPSes), thus making binaries unportable from one architecture to another... The atomic for SPARC is using cas that is an 8+ opcode. This causes problems on SPARC machines with old processors. There is a C code for machines that does not have a as atomic support. Therefore my thought is to rely on inter-process mutex locking, instead of atomics)... Thanks for your time. I feel lucky to have some spare time on my hands :) :) :) Pier -Cavan Morris - Original Message - From: Pier Fumagalli [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Saturday, April 27, 2002 8:58 AM Subject: Re: mod_webapp.so socketpool changes.. Cavan Morris [EMAIL PROTECTED] wrote: Hey Guys, I reported bug 8433 and am looking for a way to solve it. I thought that the socketpool work you're doing might solve the problem but wasn't able to compile the latest from cvs. My question is do you think that what you're working on could fix the bug? This is a very severe problem on my system. I have to restart both apache and tomcat if I get 2 concurrent requests. If you've got any ideas on the java side I can look into it, but have no idea what to do with the C. Yes, that's right... Can you send out why it doesn't compile? That code uses ATOMIC, but given that atomics are going to go away in a short time from APR, we'll need to change it to use intra-process mutexes... It doesn't compile on OS/X as well... :( Pier -- I think that it's extremely foolish to name a server after
Re: mod_webapp.so socketpool changes..
Hi John-Frederic, I've only just seen your mail as I've been away for a few days... Is there any update on this? Have you had a chance to look at the updates I made? If you want me to do any more work on this just let me know... BTW I've been testing this on an NT intranet web server running Apache 1.3.24 and more recently 2.0 and so far it's seems to be stable... Simon. [EMAIL PROTECTED] wrote: Pier Fumagalli wrote: [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi, As mentioned in my last email I have updated the socketpool changes to incorporate the changes recommended. I'm not sure if my mail was missed or not but I haven't received any feedback on the latest changes. What's the process to get this code into the codebase? I believe I would need cvs access to commit this (if deemed acceptable) into the source myself. Is this the case? Can someone fill me in Attached are the changes made. Simon, both I and JF have been pretty busy this last few days... I wanted to it out also with Apache 2.0's worker MPM before committing... I have been out for a week... But I will try to find some time today ;-) Pier -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: mod_webapp file changes for socket pools
Hi, Attached should be the updated socket pool changes to mod_webapp. I think I've incorporated the recommended changes. If you have any further comments just let me know Simon mod_webapp_update.zip Description: Zip compressed data -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [Fwd: mod_webapp file changes for socket pools]
Hi, I've done most of the changes suggested but am a little confused on a few points: warp_socket_pool current has the following features: 1) It implements a socket pool. 2) The implementation is thread-safe (I think!) 3) The implementation uses atomics. In a mt environment all features except 3 are completely necessary. Should I add a new define WARP_USE_ATOMICS, or similar, which by default is defined? Now, in a st environment none of the above features are necessary, although, if 1) isn't supported then the name is probably a bit misleading! Which features, if any, should I take out for a st environment? Possible options: * Set the pool size to 1. (#define MAX_SOCKET_POOL_SIZE 1) * Remove the mutex locking. * Change the implementation so that a handle to a single socket is held. * Replace use of atomics with ints etc.. I've added the warp_sockpool_destroy function. As far I can tell I shouldn't add a call to it anywhere in the code, should I? Any thoughts? Thanks Simon Pier Fumagalli [EMAIL PROTECTED] wrote: Jean-frederic Clere [EMAIL PROTECTED] wrote: atomic are very good but only used in mod_cache (experimental) and there the code is like: +++ #ifdef USE_ATOMICS apr_atomic_set(obj-refcount, 1); #else obj-refcount = 1; #endif +++ That will be nice to do the same in mod_webapp (At least #ifdef APR_HAS_THREADS). Hmm.. We could define a couple of macros... In lib/pr_warp.c: apr_socket_t * sock = 0; That is better to have apr_socket_t * sock = NULL; Yup... Having a pool of size one when no threads probably saves a lot of #define APR_HAS_THREADS. Agreed... Or we can comment out large chunks of code... Some changes in pr_warp_socketpool.c are needed ;-). Like what? BTW, can we keep this on the list? I won -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Building modapp for Tomcat4.0 and apache1_3.23
The problem described is a compilation problem and isn't related to to the make install. I had this problem when I tried to compile the source after downloading it a while ago. The problem is caused by the constants TYPE_... not being defined anywhere in the source. To solve this problem I took at look at the java warp source to determine what the constants should be and then added them into pr_warp.h file as follows: #define TYPE_ERROR 0x00 #define TYPE_DISCONNECT 0xfe As I mentioned I downloaded my source a while ago and I haven't checked against the latest source. If the problem is still there then I think this might be a broken mainline. Simon. make install? I don't run it. I manually copy mod_webapp.so from apache-1.3/.libs to libexec directory. README.txt should have all information you need. Punky - Original Message - From: Noaman Ahmed [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, April 06, 2002 9:18 PM Subject: Building modapp for Tomcat4.0 and apache1_3.23 I am getting following o/p at the time of builng webapp module . ../configure with all appropriate action succeds. Even make Succeds But I get following error at the time of make install make[1]: Entering directory lib make[1]: Invoking make build /usr/local/bin/gcc -g -O2 -g -O2 -DSOLARIS2=8 -D_POSIX_PTHREAD_SEMANTICS - D_RE ENTRANT -I/usr/local/apr/include -I/software/user/webapp_module/include -c pr _warp.c -o pr_warp.o pr_warp.c: In function `headers': pr_warp.c:198: `TYPE_REQ_HEADER' undeclared (first use in this function) pr_warp.c:198: (Each undeclared identifier is reported only once pr_warp.c:198: for each function it appears in.) pr_warp.c: In function `warp_handle': pr_warp.c:245: `TYPE_REQ_INIT' undeclared (first use in this function) pr_warp.c:279: `TYPE_REQ_CONTENT' undeclared (first use in this function) pr_warp.c:291: `TYPE_REQ_SCHEME' undeclared (first use in this function) pr_warp.c:303: `TYPE_REQ_AUTH' undeclared (first use in this function) pr_warp.c:329: `TYPE_REQ_CLIENT' undeclared (first use in this function) pr_warp.c:345: `TYPE_REQ_SERVER' undeclared (first use in this function) pr_warp.c:359: `TYPE_REQ_PROCEED' undeclared (first use in this function) pr_warp.c:372: `TYPE_RES_STATUS' undeclared (first use in this function) pr_warp.c:380: `TYPE_RES_HEADER' undeclared (first use in this function) pr_warp.c:391: `TYPE_RES_COMMIT' undeclared (first use in this function) pr_warp.c:396: `TYPE_RES_BODY' undeclared (first use in this function) pr_warp.c:403: `TYPE_RES_DONE' undeclared (first use in this function) pr_warp.c:408: `TYPE_CBK_READ' undeclared (first use in this function) pr_warp.c:416: `TYPE_CBK_DONE' undeclared (first use in this function) pr_warp.c:418: `TYPE_CBK_DATA' undeclared (first use in this function) pr_warp.c:421: `TYPE_ERROR' undeclared (first use in this function) pr_warp.c:373: warning: unreachable code at beginning of switch statement pr_warp.c:373: warning: unreachable code at beginning of switch statement *** Error code 1 make: Fatal error: Command failed for target `pr_warp.o' Current working directory /software/user/webapp_module/lib *** Error code 1 make: Fatal error: Command failed for target `template' Current working directory /software/user/webapp_module *** Error code 1 make: Fatal error: Command failed for target `lib-build' you have mail _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
mod_webapp socket pool changes
Hi, I've made some more progress on the socket pool implementation in mod_webapp to solve the concurrent request problem on NT boxes and it is pretty much complete. At the moment I am using a hard-coded constant to set the max number of available sockets that may be kept in a socket pool at any time. Note this option doesn't bound the number of concurrent connections but bounds the number of available and unused sockets in a pool. This constant is currently set to 25. Should this be changed to a configurable option? I'm not really sure it is necessary but am happy to change this is required. (I presume it's not too difficult to add a configuration variable that a user sets in httpd.conf...). If I keep the constant should it be changed to some other (arbitrary) constant? Also, for convenience, I've added the (3) pool functions into pr_warp.c. Any thoughts on whether they should go into a new source file? Finally, could someone offer to review and incorporate the changes into the cvs tree? Thanks Simon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
mod_webapp file changes for socket pools
Hi, Attached should be the changes I made to implement socket pools within mod_webapp. I've added a new file, pr_warp_socketpool.c, as suggested. In the zip file are the complete, changed, versions of the files along with the output of diff -u. For each file I've saved the diff in filename.diff. If there are any changes suggested to I'll be happy to incorporate them and resend the changes.. Simon mod_webapp.zip Description: Zip compressed data -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: mod_webapp file changes for socket pools
Pier wrote:
The only thing I don't like (much) is the name of the prototype functions:
- warp_socket_pool_create
- warp_socket_pool_acquire_socket
- warp_socket_pool_return_socket
And a lack of warp_socket_pool_destroy...
I would have called them
- warp_sockpool_create
- warp_sockpool_acquire
- warp_sockpool_release
- warp_sockpool_destroy
I'll change the function names and add a destroy function. For the destroy function
I'm assuming you want:
apr_status_t warp_sockpool_destroy(warp_socket_pool * pool)
{
return apr_thread_mutex_destroy(pool-pool_mutex);
}
Is this right? Am I missing something?
Simon
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
apr pools in mod_webapp
Hi, Sorry if this is a little off-topic I'm presentently trying to modifiy the mod_webapp source so that concurrent warp requests can be supported on NT. To do this, I'm implementing a pool of sockets per warp connection and each time a warp request is made a socket is acquired from the pool, used and then returned. This insures that only a single request is active on a socket at a time and so far the prototype I have is working and seems to address the problem. I've had a look at the apr documentation but it is pretty brief. I'm trying to get a proper understanding of how exactly the apr pool a.d.t. behaves and how memory is cleaned up with it. My understanding (so far) is that an apr pool essentially makes memory cleanup a bit easier by cleaning up all datastructures associated with it when it is destroyed. This removes the need to cleanup all datastructures individually and makes memory leaks less likely. As far as I can see the only way to cleanup a data structure associated with a pool is to free the entire pool. Is this correct? In this way, the pool does not behave like many common pool implementations which have alloc() and free() methods and are basically there to prevent memory allocation routine overhead. If anyone could fill me in on more details or point me to some documentation, that would be great! Thanks Simon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Problem with mod_webapp/warp connector
Hi, I've recently setup a intranet site on an NT 4.0 box using Apache 1.3.23 combined with Tomcat 4.0.3. To integrate them together I'm using the warp connector and the mod_webapp module I found at http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.0.1/bin/win32/webapp-module-1.0-tc40-windows.zip. This was the only location that I could find the webapp module so I *think* it is the latest. In general it all seems to work fine but I'm experiencing a few issues which seem to suggest to me that there is a threading issue in this version of the connector. The two main problems I've had are: 1) If I have a html document that specifies a frameset with two .jsp frames then strange bahavior occurs. I consistently get pr_warp.c errors and sometimes get the html output of the .jsps in the wrong frame. If I change one of the frames to be a static .html served directly by Apache and not via the connector then the problem goes away. 2) I've created a sevlet that acts as a download page, dynamically creating zip files and sending them as inline content back to the browser using the getOutputStream() method. In general this works great. I've noticed the problem, however, that whilst the download is proceeding (it takes a minute or so) if I use a another browser to access any other .jsp (via the connector) that the .zip download bombs out and the .jsp file is not received correctly. If I access the .jsp by using the http connector (ie port 8080) at the same time as the download no problem occurs. For this reason it seems to be a problem with the warp connector rather than with Tomcat itself. Does anyone know if I am using the wrong version or are these symptoms of a bug in the connector? As I'm new to Apache an Tomcat it may simply be a configuration issue - perhaps? If it is thought that this is a bug maybe I'll take a look at the source code for mod_webapp and see if I can see anything wrong. Does anynone have any ideas where to start and any information on how to get a build up and running on NT? Thanks for any advice. Simon Keary [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
