Modifications to JNDI environment from admin or jmxproxy not seen in application
When I change JNDI environment entries in the admin app or from the
manager app's jmxproxy, those changes are not reflected in the Context
I'm getting in my app when I do
new InitialContext().lookup("java:comp/env/test")
Since I'm doing that per-call in my webapp (and printing the result
directly to the logs), I'd expect to get my change. But, even if I
delete that environment entry, after having declared it in my
context.xml as per below, it's still there in my webapp.
Similarly, if I take that entry out of my context.xml and then add it
manually from admin, etc. it is not seen by my webapp. I even dropped
in a modified org/apache/naming/NamingContext class that println'ed
from its bind message...I'd see my entries from context.xml get bound
on deploy, but when I change things in the admin app, etc. I see
nothing...those must be being stored in an entirely different Context
class?
What am I doing wrong? Thanks,
eric
--
http://ir.iit.edu/~ej
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
problem building 5.5.15
All - Apologies in advance if this should go to tomcat-users but I'm suspecting a problem with the way the source code is being distributed so I'm starting here. I downloaded the source file for 5.5.15 and built it. After installing it I ran bin/version.sh which said I had version 5.5.0.0. Not what I was expecting. So I followed instructions, exactly, from http://tomcat.apache.org/tomcat-5.5-doc/building.html to build directly from subversion. The build went fine. But version.sh still says 5.5.0.0. I was expecting to have 5.5.15. So, did I really just build 5.5.0.0? There was a bug that was supposedly fixed in 5.5.15 that I was experiencing, and I still see this bug when I use this 5.5.0.0 which leads me to conclude I did not really build 5.5.15. Note: I can't use the binary 5.5.15 package because I have a requirement to patch JNDIRealm.java, that's why I am starting from the source code. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: problem building 5.5.15
OK thanks for the tip. Is there a document that goes into detail on this? On Mon, Feb 13, 2006 at 07:35:42PM +, Mark Thomas wrote: > Eric Lenio wrote: > > All - > > > > Apologies in advance if this should go to tomcat-users but I'm > > suspecting a problem with the way the source code is being distributed > > so I'm starting here. > > > > I downloaded the source file for 5.5.15 and built it. After installing > > it I ran bin/version.sh which said I had version 5.5.0.0. Not what I > > was expecting. > This is the default version number set in build.properties.default > > The behaviour you see is expected and can be changed by setting the > appropriate ant properties. > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: problem building 5.5.15
Hi Mark, I would be happy to send in patches to the docs on how to build Tomcat but I still need more info. Let me rephrase my initial question. Does there exist a module in the current subversion repository that has predefined all the properties to generate a file that is the same as a release? For example, I am attempting to generate apache-tomcat-5.5.15.tar.gz. The current docs basically say "run ant". Based on your earlier email I know now that I'm supposed to first set the tomcat version properties. OK so after ant finishes up, then what? I think the next step is to go into the build subdir and do 'ant release' but that's guesswork on my part. I'm looking to replicate the way you guys produce official releases. On Mon, Feb 13, 2006 at 07:59:58PM +, Mark Thomas wrote: > Eric Lenio wrote: > > OK thanks for the tip. Is there a document that goes into detail > > on this? > BUILDING.TXT and http://tomcat.apache.org/tomcat-5.5-doc/building.html > are the main documents. Documentation patches are always welcome. > > Mark > > > - > 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: problem building 5.5.15
Well if the RM must generate this file for each release perhaps then it could be added to subversion? That way any time 'svn update' is used to refresh sources the current Tomcat version can be known. On Tue, Feb 14, 2006 at 08:28:04AM +0100, Mladen Turk wrote: > > You will need to edit the build/build.properties.default > and adjust the version numbers to preferred version. > > It's up to RM to adjust them before releasing or building. > We don't have actual version number inside the SVN, although > we might add some sort of > > > in the build.xml that would contain only version flags: > > # - Vesion Control Flags - > version.major=5 > version.minor=5 > version.build=1 > version.patch=16 > #Set the pretty version name > version=5.5.16-dev > > > Since that still implies that RM will still have to > edit that file before releasing, you might as well create > a build.properties file with the upper content. > > The easiest thing would be to have a separate version > property file updated regularly upon releases. > > Regards, > Mladen. > > - > 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]
missing unregisterWrapper in MapperListener.java
Hi, I am currently working on implementing an OSGi Http service based on the full-fledged Tomcat running inside the OSGi environment as an OSGi bundle. To implement Http service, the major functionality I require from Tomcat is that it should allow for dynamic adding/removing servlet and servlet-mapping without having to restart context for many reasons such as performace consideration, etc. After having worked with Tomcat for some time, I found the goal is hard to achieve without modification to the current code of Tomcat (I am using 5.5.17), the following is my understanding of the reason why: The mapping info are mostly maintained at two places: StandardContext and Connector, each StandardContext only contains servlet-mappings pertaining to itself, but a Connector includes not only all servlet-mappings from all StandardContext instances but also the virtual host, context mappings for the servlet container. The mapping info at these places must be consistent, otherwise, Http request dispatch may run into prolems. The current mechanism used to synchronize them is through JMX Mbean registration/unregistration events: StandardContext creates/destroys servlet wrapper mbeans for the servlets being added/removed to/from the context, and the Connector (actually a MapperListener owned by it) listens to the events and updates its mapping info accordingly. But I found only registerWrapper is provided in MapperListener.java at the moment, no associated unregisterWrapper is there. This prevents previously registered servlet mapping info from being able to be removed from the Connector even if the servlet and its mapping info has been removed from its containing context, and subsequently prevents other servlet from being registered under the same servlet path with Connector. For instance, I first add a servlet X to the root context at path "/test-servlet" and then remove the servlet and its mapping info from the context by invoking removeServletMapping and removeChild on the context, but due to the reason aforementioned, the mapping "/test-servlet" to the servlet will still be kept in Connector. So later, when I try to add a servlet Y to the root context at the same path "/test-servlet" again, the old mapping at path "/test-servlet" kept in Connector will prevent the mapping info from being updated due to the rule that only distinct servlet path is allowed to be registered. This makes the Http requests to the servlet Y mistakenly dispatched by Connector to servlet X and eventually leads to failures. The fix I have tried is that we can add the unregisterWrapper method and corresponding mbean unregistration event handling to the MapperListener.java so that the MapperListener can always keep the mapping info maintained in StandardContext and Connector consistent. Any thoughts? Thanks, Eric - 抢注雅虎免费邮箱-3.5G容量，20M附件！
Re: FYI: jk 1.2.20 core on iSeries v5R3
e Jan 30 03:02:28 2007] [notice] Apache/2.2.4 (Unix) mod_jk/1.2.20 mod_ssl/2.2.4 OpenSSL/0.9.8d configured -- resuming normal operations [Tue Jan 30 03:02:28 2007] [info] Server built: Jan 29 2007 23:44:30 [Tue Jan 30 03:02:28 2007] [debug] worker.c(1740): AcceptMutex: sysvsem (default: sysvsem) [Tue Jan 30 03:03:54 2007] [notice] child pid 2203720 exit signal Segmentation fault (11) [Tue Jan 30 03:04:00 2007] [debug] worker.c(1083): the listener thread didn't exit [Tue Jan 30 03:04:01 2007] [debug] worker.c(1083): the listener thread didn't exit [Tue Jan 30 03:04:13 2007] [debug] worker.c(1354): taking over scoreboard slot from 1552520 (quiescing) [Tue Jan 30 03:04:19 2007] [notice] child pid 2576392 exit signal Segmentation fault (11) [Tue Jan 30 03:04:23 2007] [notice] child pid 2310294 exit signal Segmentation fault (11) [Tue Jan 30 03:04:26 2007] [notice] child pid 2576394 exit signal Segmentation fault (11) [Tue Jan 30 03:29:30 2007] [notice] child pid 1552524 exit signal Segmentation fault (11) [Tue Jan 30 04:09:22 2007] [notice] child pid 2584796 exit signal Segmentation fault (11) Again, I thought I would be able to track them down by changing the log level to "trace", but the problem disappears at that log level. I had assumed it was slowing the connection rate down enough to mitigate the problem. Not sure if any of that helps.. if you can help me or want more info let me know. Thanks! Eric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: FYI: jk 1.2.20 core on iSeries v5R3
Here's the Tomcat log: Jan 31, 2007 6:31:10 PM org.apache.jk.common.HandlerRequest invoke INFO: Unknown message 0 Jan 31, 2007 6:31:12 PM org.apache.jk.common.HandlerRequest invoke INFO: Unknown message 0 --- And here's the only thing I know about dbx: dbx ../bin/httpd core Type 'help' for help. warning: The core file is not a fullcore. Some info may not be available. [using memory image in core] reading symbolic information ... Segmentation fault in sig_coredump at 0x10037590 0x10037590 (sig_coredump+0x84) 80410014lwz r2,0x14(r1) (dbx) where sig_coredump() at 0x10037590 malloc_y.malloc_y(0x2000, 0x0, 0x1fe8, 0x30411700, 0xf879614d, 0x7858c51, 0x17, 0x0) at 0xd03002c4 malloc_common.malloc_common_53_36(??) at 0xd02fd8b8 jk_pool_dyn_alloc() at 0xdc05a4c0 jk_pool_alloc() at 0xdc05a5b4 jk_b_set_buffer_size() at 0xdc06c0fc ajp_service() at 0xdc064c28 jk_handler() at 0xdc050e60 ap_run_handler() at 0x10003a24 ap_invoke_handler() at 0x10004810 ap_process_request() at 0x1002fd88 ap_process_http_connection() at 0x1004d0dc ap_run_process_connection() at 0x10013dc0 ap_process_connection() at 0x100144f0 process_socket() at 0x1000b03c worker_thread() at 0x1000a8e0 dummy_worker() at 0xdbdb8384 --- I'll have a look and see if I can't get more information out of tomcat.. there must be a way to increase the logging there. I am using mpm=worker. If you still think it's worth the time I will re-compile with prefork and take another shot. Thanks again for your help. Eric Rainer Jung wrote: Hi Eric, maybe your observation is in fact related to Henri's, since you also get core dumps (segmentation faults), which is quite unusual. See further comments inline. Eric Wertman wrote: Sorry to jump in, I'm new here. I started watching this list because of a problem I'm having with the mod_jk 1.2.20 as well. I'm not getting core files, but I do have problems that I can't reproduce at log level trace or debug. Apache logs segmentation faults. You might be able to produce a core (which would be very helpful) by setting the coredumpdirectory in apache and maybe tweaking your os config. One point that might help to produce cores, would be to not run apache as root. I'm running it on AIX 5.3 (ml05). I compiled the apache 2.2.4 and apr-1.2.8 along with the mod_jk, and using tomcat 5.5.20 with an IBM 1.5 JRE. I compiled them all using the IBM cc_r compiler. I've actually tried a number of different flags trying to resolve my problem, assuming initially that I was doing something incorrectly. The behavior persists, though, and my compilations have all been clean. Apache without mod_jk doesn't give me any problems. Superficially it seems to work fine. Once I run tests with ab, it starts to get a little ugly. I get a number of failed requests, and these types of errors: [Tue Jan 30 03:03:53 2007] [2203720:] [error] jk_ajp_common.c (1504): Unknown AJP protocol code: 41 [Tue Jan 30 03:03:53 2007] [2203720:] [error] jk_ajp_common.c (970): wrong message format 0x3837 from 127.0.0.1:8010 hose mean, taht something is fundamentally wrong in the answer mopd_jk receives from tomcat. It doesn't really look like AJP/1.3. Is your MPM worker or prefork? Could you try again with prefork, in case it is worker? Do you get error message on the tomcat side? [Tue Jan 30 03:03:53 2007] [2203720:] [error] jk_ajp_common.c (1566): (PlatformServer) Tomcat is down or refused connection. No response has been sent to the client (yet) [Tue Jan 30 03:03:53 2007] [2203720:] [info] jk_ajp_common.c (1877): (PlatformServer) receiving from tomcat failed, recoverable operation attempt=0 [Tue Jan 30 03:03:53 2007] [2203720:] [info] jk_ajp_common.c (1916): (PlatformServer) sending request to tomcat failed, recoverable operation attempt=1 [Tue Jan 30 03:03:53 2007] [2203720:] [info] jk_ajp_common.c (1842): (PlatformServer) request failed, because of server error without recovery in send loop attempt=0 [Tue Jan 30 03:03:53 2007] [2203720:] [info] mod_jk.c (2142): Service error=-5 for worker=PlatformServer [Tue Jan 30 03:03:53 2007] [2203720:] [info] mod_jk.c (401): Write without start, starting with defaults Ths one is very unusual, and it is the log statement, that is the only one, that could have produced Henri's core dump, although we still do not know why. It correlates to a protocol error. [Tue Jan 30 03:03:53 2007] [2203720:] [error] jk_ajp_common.c (970): wrong message format 0x031a from 127.0.0.1:8010 [Tue Jan 30 03:03:53 2007] [2203720:] [error] jk_ajp_common.c (1592): (PlatformServer) Tomcat is down or network problems. Part of the response has already been sent to the cli ent [Tue Jan 30 03:03:53 2007] [2203720:] [info] jk_ajp_common.c (1877): (PlatformServer)
Re: FYI: jk 1.2.20 core on iSeries v5R3
Mladen Turk wrote: Eric Wertman wrote: Connector: JkWorkersFile conf/workers.properties JkShmFile logs/mod_jk.shm JkShmSize 8192 This is 8MB of shared memory. Are you sure you have 1 workers? It wasn't obvious to me what a reasonable value of this was.. I tried everything from the default to commenting it out. At one point I set it to 1048576. It didn't seem to make much difference in any case.. what's the reccomendation for that setting? Is it purely based on number of workers, or does the size and type of data also count? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: FYI: jk 1.2.20 core on iSeries v5R3
I did rebuild the sources as prefork, it seems to have stopped the problem. I did also make those 2 corrections you pointed out earlier in the thread. Eric Wertman wrote: Connector: maxThreads="800" minThreads="100" bufferSize="8192" backlog="256" /> I've tried all sorts of permutations of this... None of the values make much difference. My ab test is -n 1000 -c 200. --- workers.properties: # PlatformServer worker.PlatformServer.type=ajp13 worker.PlatformServer.host=localhost worker.PlatformServer.port=8010 worker.PlatformServer.connection_pool_timeout=60 worker.PlatformServer.socket_timeout=60 worker.PlatformServer.retries=5 I've been through a lot of different settings here too. I've tried some almost insane values for maxThreads --- httpd.conf (Using virtual servers, forgot to mention that before) JkWorkersFile conf/workers.properties JkShmFile logs/mod_jk.shm JkShmSize 8192 JkLogFile logs/mod_jk.log JkLogLeveldebug --- mod_jk startup at debug level. I only included it because it shows what mod_jk thinks of my connector. [Wed Jan 31 18:26:15 2007] [2281674:] [debug] jk_worker.c (239): creating worker PlatformServer [Wed Jan 31 18:26:15 2007] [2281674:] [debug] jk_worker.c (144): about to create instance PlatformServer of ajp13 [Wed Jan 31 18:26:15 2007] [2281674:] [debug] jk_worker.c (157): about to validate and init PlatformServer [Wed Jan 31 18:26:15 2007] [2281674:] [debug] jk_ajp_common.c (1971): worker PlatformServer contact is 'localhost:8010' [Wed Jan 31 18:26:15 2007] [2281674:] [debug] jk_ajp_common.c (2098): setting endpoint options: [Wed Jan 31 18:26:15 2007] [2281674:] [debug] jk_ajp_common.c (2101): keepalive:0 [Wed Jan 31 18:26:15 2007] [2281674:] [debug] jk_ajp_common.c (2105): timeout: 60 [Wed Jan 31 18:26:15 2007] [2281674:] [debug] jk_ajp_common.c (2109): buffer size: 0 [Wed Jan 31 18:26:15 2007] [2281674:] [debug] jk_ajp_common.c (2113): pool timeout: 60 [Wed Jan 31 18:26:15 2007] [2281674:] [debug] jk_ajp_common.c (2117): connect timeout: 0 [Wed Jan 31 18:26:15 2007] [2281674:] [debug] jk_ajp_common.c (2121): reply timeout:0 [Wed Jan 31 18:26:15 2007] [2281674:] [debug] jk_ajp_common.c (2125): prepost timeout: 0 [Wed Jan 31 18:26:15 2007] [2281674:] [debug] jk_ajp_common.c (2129): recovery options: 0 [Wed Jan 31 18:26:15 2007] [2281674:] [debug] jk_ajp_common.c (2133): retries: 5 [Wed Jan 31 18:26:15 2007] [2281674:] [debug] jk_ajp_common.c (2137): max packet size: 8192 [Wed Jan 31 18:26:15 2007] [2281674:] [debug] jk_ajp_common.c (2008): setting connection pool size to 25 with min 13 --- Can't reproduce at debug level. This is info (got it on the first try). [Wed Jan 31 18:31:10 2007] [2539586:] [error] jk_ajp_common.c (1504): Unknown AJP protocol code: 41 [Wed Jan 31 18:31:10 2007] [2539586:] [info] jk_ajp_common.c (1842): (PlatformServer) request failed, because of server error without recovery in send loop attempt=0 [Wed Jan 31 18:31:10 2007] [2539586:] [error] jk_ajp_common.c (970): wrong message format 0x3837 from 127.0.0.1:8010 [Wed Jan 31 18:31:10 2007] [2539586:] [error] jk_ajp_common.c (1566): (PlatformServer) Tomcat is down or refused connection. No response has been sent to the client (yet) [Wed Jan 31 18:31:10 2007] [2539586:] [info] jk_ajp_common.c (1877): (PlatformServer) receiving from tomcat failed, recoverable operation attempt=0 [Wed Jan 31 18:31:10 2007] [2539586:] [info] jk_ajp_common.c (1916): (PlatformServer) sending request to tomcat failed, recoverable operation attempt=1 [Wed Jan 31 18:31:10 2007] [2539586:] [info] mod_jk.c (2142): Service error=-5 for worker=PlatformServer [Wed Jan 31 18:31:11 2007] [2539586:] [info] mod_jk.c (401): Write without start, starting with defaults [Wed Jan 31 18:31:12 2007] [2539586:] [error] jk_ajp_common.c (970): wrong message format 0x0400 from 127.0.0.1:8010 [Wed Jan 31 18:31:12 2007] [2539586:] [error] jk_ajp_common.c (1566): (PlatformServer) Tomcat is down or refused connection. No response has been sent to the client (yet) [Wed Jan 31 18:31:12 2007] [2539586:] [error] jk_ajp_common.c (1504): Unknown AJP protocol code: 02 [Wed Jan 31 18:31:12 2007] [2539586:] [info] jk_ajp_common.c (1877): (PlatformServer) receiving from tomcat failed, recoverable operation attempt=0 [Wed Jan 31 18:31:12 2007] [2539586:] [info] jk_ajp_common.c (1916): (PlatformServer) sending request to tomcat failed, recoverable operation attempt=1 [Wed Jan 31 18:31:12 2007] [2539586:] [info] jk_ajp_common.c (1842): (PlatformServer) request failed, because of server error without
Re: [VOTE] Releasing Tomcat Connectors 1.2.21
I'm just ringing in, although I don't have a vote. I was working with Rainer on an issue with 1.2.21 on some Red Hat machines. I started with mod_jk because those were the only error messages I was getting. It turns out that those messages were not related to my ultimate problem. Thanks again to Rainer for helping me track that down and sort it out. My ultimate problem was that apache was returning bad data in some requests, but logging 200 error code and the proper file sizes in the access_log. The files themselves were of variable size and often contained other "junk" that was obviously from apache memory space (chunks of log entries and other things). The theories I went though included targeting sendfile, mmap, and mod_cache (mod_cache_mem) . I disabled all of these and still was experiencing the problem. Eventually I stopped it from happening by switching from mod_jk to mod_proxy_ajp. I still have the other things enabled. Since I'm not a developer I can't say exactly where that problem might be. It does seem as though there is some problem there. I couldn't reproduce it with ab... apache thinks everything is normal. It didn't show up until I put the servers in production, and then it was only a small percentage of overall requests. If I hadn't seen the b0rked images and files through my browser I would not have known the problem existed. I'd be happy to help troubleshoot this if anyone wants to investigate further. Thanks; Eric Henri Gomez wrote: Well it shouldn't stop the release since it may be related to iSeries beast. I should check about compile flags (we don't use configure on iSeries) and may be I miss something but it seems related to logging area ;( 2007/3/1, Rainer Jung <[EMAIL PROTECTED]>: Henri, since this alredy happened in 1.2.20 and it runs well on most platforms, think it should not stop the release. But I'm still very interested in fixing his. In your last problem report, I think I saw a stack trace from which we could see the method, were the crash was happening. Maybe we can then build a debug version, to find out, which things didn't get initialized properly. Regards, Rainer Henri Gomez wrote: > Stable on Linux PPC but still problem on iSeries V5R3 : > > 18, instruction X''. > Pointeur non défini pour position mémoire référencée. > Application error. MCH3601 unmonitored by MOD_JK1221 at statement > 37, instruction X''. > Value for call stack counter parameter not valid. > Application error. CEE9901 unmonitored by QP0WPINT at statement > 18, instruction X''. > Pointeur non défini pour position mémoire référencée. > Application error. MCH3601 unmonitored by MOD_JK1221 at statement > 37, instruction X''. > Value for call stack counter parameter not valid. > Application error. CEE9901 unmonitored by QP0WPINT at statement > 18, instruction X''. > > Apache is 2.0.58 on V5R3 :( > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- -- kippdata informationstechnologie GmbH Tel: 0228 98549 -0 Bornheimer Str. 33aFax: 0228 98549 -50 53111 Bonn www.kippdata.de HRB 8018 Amtsgericht Bonn / USt.-IdNr. DE 196 457 417 Geschäftsführer: Dr. Thomas Höfer, Rainer Jung, Sven Maurmann === kippdata informationstechnologie GmbH Tel: +49 228 98549 -0 Bornheimer Str. 33aFax: +49 228 98549 -50 D-53111 Bonn www.kippdata.de HRB 8018 Amtsgericht Bonn / USt.-IdNr. DE 196 457 417 Geschäftsführer: Dr. Thomas Höfer, Rainer Jung, Sven Maurmann - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: reload on demand
WebSphere has this option on deployment, you can indicate that an app should poll it's class files every so often to see if there are any changes, and restart itself if it does. It is a nice option to have, but I agree that I'd rather my computer program not do anything I didn't ask of it. Kent Tong wrote: Yoav Shapira apache.org> writes: There will always be at least one manual step, because as things stand right now a computer program can't read your mind ;) You don't want it to reload automatically when a specific resource (or resources) is/are modified, you don't want it to reload automatically on a time basis, you don't want to use the Manager HTML reload interface or the Ant tasks that invoke it in a script... What automatic options remain? ;) The automatic option is when I access the webapp, Tomcat notes that some class file in it has changed and reload the webapp. - 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: Debugging Apache/mod_jk (worker) fault on AIX
Hi Rainer... I'll have to re-compile to get this info for you. I'll
make sure I can re-produce it and submit the details in a bugzilla.
I think the first thing you'll notice, though, is that I'm using the IBM
cc_r compiler and not gcc.
Rainer Jung wrote:
Eric reported very strange mod_jk behaviour using it with Apache
2.0/worker on AIX.
I start a new mail thread, because until now all the discussion is part
of non-specific threads.
Eric: could you please open a bugzilla (issues.apache.org), so that we
can track the issue?
Also: When you compile mod_jk for your apache with worker MPM, does the
make output contain the flag -D_REENTRANT?
If no, how does the begginning of the file HOME_OF_APACHE/bin/apr-config
look like? Example:
APR_MAJOR_VERSION="0"
APR_DOTTED_VERSION="0.9.12"
prefix="/var/tmp/install/apache2p"
exec_prefix="/var/tmp/install/apache2p"
bindir="${prefix}/bin"
libdir="${prefix}/lib"
datadir="/var/tmp/install/apache2p"
installbuilddir="${prefix}/build"
includedir="/var/tmp/install/apache2p/include"
CC="gcc "
CPP="gcc -E"
SHELL="/bin/sh"
CPPFLAGS="-DLINUX=2 -D_REENTRANT -D_GNU_SOURCE"
CFLAGS="-O2 -g -Wall -pthread"
LDFLAGS=""
LIBS="-lrt -lm -lcrypt -lnsl -lpthread -ldl"
EXTRA_INCLUDES=""
SHLIBPATH_VAR="LD_LIBRARY_PATH"
APR_SOURCE_DIR="/non/existing/build/path/apache2/srclib/apr"
APR_BUILD_DIR="/non/existing/build/path/apache2/srclib/apr"
APR_SO_EXT="lo"
APR_LIB_TARGET="-rpath \$(libdir) \$\$objects"
APR_LIBNAME="apr-${APR_MAJOR_VERSION}"
Regards,
Rainer
-
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: Debugging Apache/mod_jk (worker) fault on AIX
Actually I started with xlc_r and it wouldn't go. Not mod_jk
specifically, but apr or apache 2.2.4. I stuck with cc_r for consistency.
William A. Rowe, Jr. wrote:
Any reason you didn't choose xlc_r? I'd suggest you retest with that
compile.
Rainer Jung wrote:
Hi Eric,
we won't close the issue immediately with "we don't support cc_r". This
will be our last option :)
Rainer
Eric Wertman wrote:
Hi Rainer... I'll have to re-compile to get this info for you. I'll
make sure I can re-produce it and submit the details in a bugzilla.
I think the first thing you'll notice, though, is that I'm using the
IBM cc_r compiler and not gcc.
Rainer Jung wrote:
Eric reported very strange mod_jk behaviour using it with Apache
2.0/worker on AIX.
I start a new mail thread, because until now all the discussion is part
of non-specific threads.
Eric: could you please open a bugzilla (issues.apache.org), so that we
can track the issue?
Also: When you compile mod_jk for your apache with worker MPM, does the
make output contain the flag -D_REENTRANT?
If no, how does the begginning of the file HOME_OF_APACHE/bin/apr-config
look like? Example:
APR_MAJOR_VERSION="0"
APR_DOTTED_VERSION="0.9.12"
prefix="/var/tmp/install/apache2p"
exec_prefix="/var/tmp/install/apache2p"
bindir="${prefix}/bin"
libdir="${prefix}/lib"
datadir="/var/tmp/install/apache2p"
installbuilddir="${prefix}/build"
includedir="/var/tmp/install/apache2p/include"
CC="gcc "
CPP="gcc -E"
SHELL="/bin/sh"
CPPFLAGS="-DLINUX=2 -D_REENTRANT -D_GNU_SOURCE"
CFLAGS="-O2 -g -Wall -pthread"
LDFLAGS=""
LIBS="-lrt -lm -lcrypt -lnsl -lpthread -ldl"
EXTRA_INCLUDES=""
SHLIBPATH_VAR="LD_LIBRARY_PATH"
APR_SOURCE_DIR="/non/existing/build/path/apache2/srclib/apr"
APR_BUILD_DIR="/non/existing/build/path/apache2/srclib/apr"
APR_SO_EXT="lo"
APR_LIB_TARGET="-rpath \$(libdir) \$\$objects"
APR_LIBNAME="apr-${APR_MAJOR_VERSION}"
Regards,
Rainer
-
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]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
dbcp pool evictor deadlock?
r the correct dbcp settings would be appreciated to ensure that this doesn't happen again. Thanks, Eric - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: dbcp pool evictor deadlock?
"Mark Thomas" wrote in message news:4a40e12c.2070...@apache.org... > Narendra Sarkar wrote: >> Hi, >> We have a multi threaded environment. We have noticed that thread blocks >> for >> 10 to 20 minutes due DBCP getConnection method call. Then, we >> investigated >> the source code of DBCP(commons-dbcp-1.2.1-PII.jar) and noticed that >> createConnection method is synchronized. This problem occur more >> frequently >> when we have lower value of MaxIdleConnection parameter. After increasing >> the value of MaxIdleConnection parameter, frequency of blocking get >> reduced. >> We then replaced DBCP connection pooling with Oracle Connection pooling >> (ojdbc14.jar) and never encountered blocking issue. >> >> I think the issue is with that createConnection method of DBCP >> synchronization. We have taken Thread dump to do above analysis. > > Yep, known issues with commons-pool. Should be fixed in 1.5.1. Trunk has > been updated. Proposed for 6.0.x and 5.5.x. Alternatively, there is the > new JDBC pool module. I'm a little confused now. Filip pointed me to the jdbp-1.0.5 package. Is that just repackaged versions of dbcp 1.2.2/pool 1.5? If not, what versions of dbcp/pool are contained within there? If the fix in commons-pool is in 1.5.1, am I still expecting concurrency problems if upgrading 1.5? What would be the best move? Thanks, Eric - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: dbcp pool evictor deadlock?
"Filip Hanik - Dev Lists" wrote in message news:4a40eddd.2000...@hanik.com... > first, sorry for bringing this thread to dev, that should have never > happened. I fat fingered the keyboard. I cross posted my response to this, so the thread can continue on the user list, if needed. >>>> I think the issue is with that createConnection method of DBCP >>>> synchronization. We have taken Thread dump to do above analysis. >>>> >>> Yep, known issues with commons-pool. Should be fixed in 1.5.1. Trunk has >>> been updated. Proposed for 6.0.x and 5.5.x. Alternatively, there is the >>> new JDBC pool module. >>> >> >> I'm a little confused now. Filip pointed me to the jdbp-1.0.5 package. >> Is that just repackaged versions of dbcp 1.2.2/pool 1.5? If not, what >> versions of dbcp/pool are contained within there? >> > its a different package all together. Similar features, different > implementation. Is the implementation stable and fully tested? Or is it still undergoing development? Thanks, Eric - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Redirecting Tomcat logs to rsyslog server
For internal security reasons I need to prevent our tomcat logs from writing to the webserver local disk. We set up a rsyslog server and want to pipe the log data directly to rsyslog. I am trying to work out how to configure tomcat to send all lpg data to STDOUT or named pipe and have the rsyslog agent send the data to rsyslog on a separate server. We are on CentOS 5.6, Tomcat 6 and rsyslog 5.8.1. I need to know: 1) do we use the default logging library or log4j 2) where is this configured in the tomcat config Thanks, Eric -- View this message in context: http://old.nabble.com/Redirecting-Tomcat-logs-to-rsyslog-server-tp31717311p31717311.html Sent from the Tomcat - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Tagging 9.0.x
On 2018-09-03 12:19, Mark Thomas wrote: Hi all, As the start of September is here I'm planning to tag 9.0.x (and 8.5.x) shortly and roll the next monthly release. Hi! Will there be a new release of tomcat native to go with 9.0.x? - Eric L - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat Native 1.2.18
On Thu, Oct 18, 2018 at 12:19 AM Mark Thomas wrote: > Version 1.2.18 includes the following changes compared to 1.2.17: > > - Windows binaries built with OpenSSL 1.0.2p and APR 1.6.5 > - Windows binaries built with OpenSSL 1.1.1 and APR 1.6.5 > - TLSv1.3 support when built with OpenSSL 1.1.1 > > Various other fixes and improvements. See the changelog for details. > [snip] Where is the changelog? Thanks for the release! - Eric L
Stopping service on Windows takes a long time
Hi, I usually keep up with the latest version of Tomcat and use it for personal projects. My main platform is Windows (10). I noticed with 9.0.14, using the application "Monitor Tomcat" that is takes a very long time to stop the service. Maybe 3-5 times as long as previously. The progress bar even cycles. I thought it might be a problem with my system but today I needed to use Tomcat for something at work, and I saw the same behavior on my work computer (which is also running Windows 10). 9.0.13 did not have this issue. Using the latest 64-bit Java 8 JDK (update 192). - Eric L - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
question on AprEndpoint.Poller used on XP
Hi,
We're in a discussion on the APR dev mailing list regarding a problem
with tcnative on XP. On XP the poller implemented in APR with select()
is being used. According to Jeff Trawick of APR, select can never give
an APR_POLLHUP return event (see
http://mail-archives.apache.org/mod_mbox/apr-dev/201105.mbox/browser).
Should this situation be handled by the AprEndpoint.Poller thread when
the poll return value rv > 0 and obviously the first test in de next
snippet from AprEndpoint.Poller.run():
if (((desc[n*2] & Poll.APR_POLLHUP) == Poll.APR_POLLHUP)
|| ((desc[n*2] & Poll.APR_POLLERR) == Poll.APR_POLLERR)
|| (comet && (!processSocket(desc[n*2+1], SocketStatus.OPEN)))
|| (!comet && (!processSocket(desc[n*2+1] {
fails? Is this the reason for the
(!processSocket(desc[n*2+1], SocketStatus.OPEN))
test on the third line above?
In the case where we encounter 100% cpu usage when the client connection
has gone, processSocket() returns true (as almost always). Is this
intended or wopuld this be a place where a fix could be introduced
following the line of Jeff Trwick's message mentioned above?
Eric
Re: question on AprEndpoint.Poller used on XP
On Fri, May 6, 2011 at 4:18 PM, Mladen Turk wrote: > On 05/06/2011 04:02 PM, Eric van der Maarel wrote: > >> Hi, >> >> We're in a discussion on the APR dev mailing list regarding a problem >> with tcnative on XP. On XP the poller implemented in APR with select() >> is being used. According to Jeff Trawick of APR, select can never give >> an APR_POLLHUP return event (see >> http://mail-archives.apache.org/mod_mbox/apr-dev/201105.mbox/browser). >> >> > I followed the discussion and the ideal solution would be to make sure > that the correct flags are returned. > > > >> In the case where we encounter 100% cpu usage when the client connection >> has gone, processSocket() returns true (as almost always). Is this >> intended or wopuld this be a place where a fix could be introduced >> following the line of Jeff Trwick's message mentioned above? >> >> > I suppose the problem is that inside Tomcat we don't check the data > processed. Here the solution would be that if the socket comes out > from the Poller with POLLIN and the subsequent read returns 0 we > should close that socket instead putting it back to Poller. > I presume this is what's going on, right? > Yes, I guess that is where I was going; suggested also by Jeff Trawick of APR. Isn't it what should be going on in processSocket(desc[n*2+1], SocketStatus.OPEN) already (e.g., because the event handler returns with a Handler.SocketState.CLOSED or another more appropriate state to be invented)? Regards, Eric > > Regards > -- > ^TM > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
