Re: Updating Tomcat native requires APR update
On Wed, Jun 29, 2016 at 3:04 PM, Mark Thomas wrote: > On 29/06/2016 12:40, Ari Luoma wrote: >> First I would like to thank you for the great job you do by responding >> to these questions people have. >> >> I am about to update Tomcat 8.0.26 -> 8.5.3. >> >> I am using AJP APR connector between Tomcat and Apache. >> >> If I update APR (by downloading and compiling it from APR website) to >> the newest do I also need to compile httpd or can it use 1.3.9 APR >> with httpd when Tomcat uses 1.5.2? > > As long as you compile APR 1.5.2 to a separate location and don't > overwrite your APR 1.3.9 build you should be fine. > But even though if someone would overwrite the previous one it should be fine, because compiling later version? Binary Compatibility: "Similar to source compatibility, an application that has been compiled against a particular version will continue to be linkable against later versions (unless the major number changes). It is possible that an application will not be able to successfully link against a previous minor version." Source: http://apr.apache.org/versioning.html >> Below more info about the current setup: >> >> One Server with: CentOS 6.3 >> Apache HTTP Server 2.2.15 (installed from centos repo) >> Tomcat 8.0.26 (Installed by downloading tar.gz...) >> APR 1.3.9 (installed from centos repo and this is the newest version >> available from repo) >> Tomcat-native 1.1.33 (built from Tomcat directory) >> >> Server is running multiple Tomcats instances in different ports. >> httpd is there at front as a proxy with configuration something like this. >> >> Listen 443 >> NameVirtualHost *:443 >> >> ... >> >> ProxyPass ajp://localhost:8109/myWebApp/ timeout=3600 >> ProxyPassReverseCookiePath /myWebApp /test >> >> >> >> >> Connector on Tomcat side: >> >> >> >> #httpd -V >> Server version: Apache/2.2.15 (Unix) >> Server built: Aug 13 2013 17:29:28 >> Server's Module Magic Number: 20051115:25 >> Server loaded: APR 1.3.9, APR-Util 1.3.9 >> Compiled using: APR 1.3.9, APR-Util 1.3.9 >> ... >> >> When about to build the tomcat native 1.2.7 from Tomcat 8.5.3 it says: >> configure: error: Found APR 1.3.9. You need version 1.4.3 or newer installed. > > Once you fix the APR issue, OpenSSL might be your next problem since > tomcat native requires OpenSSL 1.0.2. There are various solutions, the > simplest being to build Tomcat Native without OpenSSL support if you > don't need it. Thanks for that! Luckily I don't need the SSL support on Tomcat side, because httpd handles it and connection to manager goes through VPN so I can "downgrade" https connection into http. > > Mark > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Runtime Cloning of DataSource for Different DB?
On 6/29/2016 1:44 AM, Mark Thomas wrote:
On 29/06/2016 05:12, Terence M. Bandoian wrote:
On 6/28/2016 3:56 AM, Mark Thomas wrote:
On 27/06/2016 22:35, Jerry Malcolm wrote:
Mark,
On 6/27/2016 1:07 PM, Mark Thomas wrote:
On 27/06/2016 17:44, Jerry Malcolm wrote:
I'm assuming that context.lookup(...) simply locates the "jdbc/myDB"
tag in the context.xml file, pulls all of the parms out of
that tag, creates a DataSource object utilizing the parms, and returns
it.If that's the case, couldn't I create a variation/subclass
of the
Context object that modifies the url parm that it found in the
resource
tag and puts the desired db name into the url before constructing the
DataSource?
Sure.
You need to implement the appropriate factory and then specify your
factory class explicitly in the Resource element using the factory
attribute.
You probably want to start here for ideas on how to code up your
factory:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/naming/factory/
or for a more specific example:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/dbcp/dbcp2/BasicDataSourceFactory.java?view=annotate
Mark
Thanks so much. This looks doable. Just to make sure I have the big
picture correct
1) I will define a new custom resource that returns a custom context
object that I write.
2) On the tag for my custom context resource I can put all of
the standard DataSource parms
3) I then call lookup() on this custom context passing the dbName in
4) This custom context will build an appropriate Reference object with
all the parms, instantiate a BasicDataSourceFactory, and call
getInstance(.) on the factory.
When I need an instance of the datasource:
Context initContext = new InitialContext();
Context envContext =
(Context)initContext.lookup("java:/comp/env");
MyDataSourceContext dsContext = (MyDataSourceContext)
envContext.lookup( "dsContext/myDSContext" );
DataSource myDS = (DataSource) dsContext.getInstance(
"dbName" );
Am I getting close?
Yes, but I don't think you want to use custom NamingContexts. I think
there is a simpler way.
1. Write a custom DataSource factory that provides a getDataSource(...)
method that allows you to pass in whatever per instance config you need.
This DataSource factory will need to use bean style setters (like the
example I linked to) to pick up the other config from the
2. Write a custom resource factory that returns an instance of your
DataSource factory.
3. Add a context Resource element for your DataSource factory,
remembering to use the factory element and specify the custom resource
factory from 2.
HTH,
Mark
If external configuration were not required, would there be a problem
instantiating a DataSource directly and setting any required properties
programmatically? Would any functionality be lost?
The option of a global resource shared between multiple web apps is lost.
You'd need a mechanism (a statics would work) to store and retrieve the
DataSource.
Also, if there were base properties set in a element, would
there be a problem using a copy of the properties from that data source,
modified as necessary, to instantiate a new DataSource?
No, but you'd need to be careful since multiple requests for the same
DataSource should return the same object. You'd need to be able to
differentiate between a request for a new DataSourece and a previously
created one.
Mark
Thanks!
-Terence
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [ANN] Apache Tomcat 8.5.3 available
On 29/06/2016 17:53, Christian wrote: > On 29.06.2016 18:34, Christian wrote: >> On 29.06.2016 17:54, Mark Thomas wrote: >>> Those just wrap java.util.logging so follow the instructions (from >>> log4j2) to redirect that to log4j2. >>> >>> Mark >> >> Thank you for your quick reply. >> That's what I did already[1], but it still results in an exception: >> Exception in thread "main" java.lang.NoClassDefFoundError: >> org/apache/juli/logging/LogFactory >> >> This message results from the attempt to load the logger into >> org.apache.catalina.startup.ContextConfig's static log field. >> >> Just to prevent misunderstandings: I'm using tomcat-embed-core 8.5.3. >> >> Regards >> Christian >> >> [1] add log4j-jul to classpath and add >> java.util.logging.manager=org.apache.logging.log4j.jul.LogManager to >> the system properties >> > > I found my mistake: I just needed to add org.apache.tomcat:tomcat-juli... That is a bug in the 8.5.3 packaging that should be fixed for 8.5.4. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [ANN] Apache Tomcat 8.5.3 available
On 29.06.2016 18:34, Christian wrote: On 29.06.2016 17:54, Mark Thomas wrote: Those just wrap java.util.logging so follow the instructions (from log4j2) to redirect that to log4j2. Mark Thank you for your quick reply. That's what I did already[1], but it still results in an exception: Exception in thread "main" java.lang.NoClassDefFoundError: org/apache/juli/logging/LogFactory This message results from the attempt to load the logger into org.apache.catalina.startup.ContextConfig's static log field. Just to prevent misunderstandings: I'm using tomcat-embed-core 8.5.3. Regards Christian [1] add log4j-jul to classpath and add java.util.logging.manager=org.apache.logging.log4j.jul.LogManager to the system properties I found my mistake: I just needed to add org.apache.tomcat:tomcat-juli... Regards Christian - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [ANN] Apache Tomcat 8.5.3 available
On 29.06.2016 17:54, Mark Thomas wrote: Those just wrap java.util.logging so follow the instructions (from log4j2) to redirect that to log4j2. Mark Thank you for your quick reply. That's what I did already[1], but it still results in an exception: Exception in thread "main" java.lang.NoClassDefFoundError: org/apache/juli/logging/LogFactory This message results from the attempt to load the logger into org.apache.catalina.startup.ContextConfig's static log field. Just to prevent misunderstandings: I'm using tomcat-embed-core 8.5.3. Regards Christian [1] add log4j-jul to classpath and add java.util.logging.manager=org.apache.logging.log4j.jul.LogManager to the system properties - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [ANN] Apache Tomcat 8.5.3 available
On 29/06/2016 16:35, Christian wrote: > Hi all, > > > On 14.06.2016 14:23, Mark Thomas wrote: >> On 14/06/2016 13:18, Sergio Fernández wrote: >>> May I ask what happened with tomcat-embed-logging-* artifacts in >>> 8.5.3? I >>> still see them at 8.0.x, included the recent 8.0.36, but they >>> disappeared >>> after 8.5.2: >>> >>> [...] >> Those modules have been removed. They are only useful with log4j 1.x >> which is no longer supported by the log4j community. With log4j 2.x, you >> can achieve the same result with no extra Tomcat libraries. >> >> Mark > > I might be blind, but couldn't figure out how to achieve proper logging > with log4j 2.x. > Is there a special module implementing org.apache.juli.logging.Log and > org.apache.juli.logging.LogFactory? Those just wrap java.util.logging so follow the instructions (from log4j2) to redirect that to log4j2. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [ANN] Apache Tomcat 8.5.3 available
Hi all, On 14.06.2016 14:23, Mark Thomas wrote: On 14/06/2016 13:18, Sergio Fernández wrote: May I ask what happened with tomcat-embed-logging-* artifacts in 8.5.3? I still see them at 8.0.x, included the recent 8.0.36, but they disappeared after 8.5.2: [...] Those modules have been removed. They are only useful with log4j 1.x which is no longer supported by the log4j community. With log4j 2.x, you can achieve the same result with no extra Tomcat libraries. Mark I might be blind, but couldn't figure out how to achieve proper logging with log4j 2.x. Is there a special module implementing org.apache.juli.logging.Log and org.apache.juli.logging.LogFactory? Regards Christian - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: AW: wrong request.getServerPort value reported on upgraded HTTP/2 connector ?
that was fast. thanks. Frank -Original Message- From: Mark Thomas [mailto:ma...@apache.org] Sent: Wednesday, June 29, 2016 3:41 PM To: Tomcat Users List Subject: Re: AW: wrong request.getServerPort value reported on upgraded HTTP/2 connector ? On 29/06/2016 09:49, Mark Thomas wrote: > On 29/06/2016 07:50, Frank Taffelt wrote: >> i have no other connectors than the one on port 443. > > I can reproduce this. I'll look at getting this fixed for the next release. Fixed. The fix will be in 9.0.0.M9 onwards and 8.5.4 onwards. Mark > > Mark > > >> >> -Ursprüngliche Nachricht- >> Von: Christopher Schultz [mailto:ch...@christopherschultz.net] >> Gesendet: Dienstag, 28. Juni 2016 17:56 >> An: Tomcat Users List >> Betreff: Re: wrong request.getServerPort value reported on upgraded HTTP/2 >> connector ? >> >> Frank, >> >> On 6/28/16 11:02 AM, Frank Taffelt wrote: >>> Calling the method request.getServerPort() returns 80 on http/2 >>> upgraded requests for the https connector. I would expect that this >>> method should return 443 in these calls. My current workarround is >>> to disable the APR Listener as this results in correct value for the >>> https connector. So is this a bug? >> >> Definitely seems like a bug. You have no other connectors defined other than >> the one on port 443? >> >> -chris >> >> - >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> >> >> - >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Fwd: tomcat 8.0 session_id resets in AWS
On 29/06/2016 14:05, Gibu George wrote: > Hi All, > > I'm trying to get tomcat to work in a cluster with sessions being persisted > in mysql, in AWS. I have setup two tomcat servers in the clusters using " > org.apache.catalina.tribes.membership.StaticMember". > > The problem that I am facing is that when a request that containing > session_id created by tomcat instance1 is send to tomcat instance2, tomcat > instance2 fails to validate the session_id ( created by instance1 ) and > send a new session_id, created by instance2 in the response. > > Why is this happening? Many possible reasons. More investigation is required. Is your web application cluster enabled? What do the logs tell you is happening with the cluster? > Has anyone face such an issue ? Frequently. > my tomcat is front ended by nginx > > Part 2: How do I enable logging for session management in tomcat? What do i > need to add in logging.properties file? org.apache.catalina.session.level = FINE org.apache.catalina.tribes.level = FINE is probably overkill but you can narrow it down once you figure out what is useful (or not) for your situation. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: AW: wrong request.getServerPort value reported on upgraded HTTP/2 connector ?
On 29/06/2016 09:49, Mark Thomas wrote: > On 29/06/2016 07:50, Frank Taffelt wrote: >> i have no other connectors than the one on port 443. > > I can reproduce this. I'll look at getting this fixed for the next release. Fixed. The fix will be in 9.0.0.M9 onwards and 8.5.4 onwards. Mark > > Mark > > >> >> -Ursprüngliche Nachricht- >> Von: Christopher Schultz [mailto:ch...@christopherschultz.net] >> Gesendet: Dienstag, 28. Juni 2016 17:56 >> An: Tomcat Users List >> Betreff: Re: wrong request.getServerPort value reported on upgraded HTTP/2 >> connector ? >> >> Frank, >> >> On 6/28/16 11:02 AM, Frank Taffelt wrote: >>> Calling the method request.getServerPort() returns 80 on http/2 >>> upgraded requests for the https connector. I would expect that this >>> method should return 443 in these calls. My current workarround is to >>> disable the APR Listener as this results in correct value for the >>> https connector. So is this a bug? >> >> Definitely seems like a bug. You have no other connectors defined other than >> the one on port 443? >> >> -chris >> >> - >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> >> >> - >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Need help setting up SSL on Tomcat 8
Hello Daniel
Thank you for the information. Here is the output of the keytool command:
Keystore type: JKS
Keystore provider: SUN
Your keystore contains 2 entries
root, Jun 16, 2016, trustedCertEntry,
Certificate fingerprint (SHA1):
27:AC:93:69:FA:F2:52:07:BB:26:27:CE:FA:CC:BE:4E:F9:C3:19:B8
{b81d8607-57e9-4c35-a058-cd46099e7797}, Jun 16, 2016, PrivateKeyEntry,
Certificate fingerprint (SHA1):
6C:67:52:63:6B:EF:A2:3D:CD:A7:CB:64:99:99:4F:9C:3E:85:B9:AA
Is it possible that the error that I am seeing, is related to the fact that
I am using a wildcard certificate?
Thanks
On Tue, Jun 28, 2016 at 5:09 PM, Daniel Savard
wrote:
> 2016-06-28 16:24 GMT-04:00 Sean Son :
>
>
> >
> > as for the output to the keytool command:
> >
> > Isnt the output to that command, confidential information?
> >
> >
> No, there isn't anything confidential from the output of a simple -list. It
> doesn't display the private key or anything like that. It will just show
> the list of certificates in your keystore.
>
> The first entry in the keystore will be the one sent back by the Tomcat
> server since you didn't specify any alias. So, I assume this is the
> intended behavior.
>
> Since you do not specify any trust store, the default trust store shipped
> with your version of Java will be used. If the clients trying to connect
> are not having certificats signed by one of these, it will fails. It may
> not be a problem in your case since you do not provide any details on the
> clients' certificates.
>
> Regards,
> -
> Daniel Savard
>
Fwd: tomcat 8.0 session_id resets in AWS
Hi All, I'm trying to get tomcat to work in a cluster with sessions being persisted in mysql, in AWS. I have setup two tomcat servers in the clusters using " org.apache.catalina.tribes.membership.StaticMember". The problem that I am facing is that when a request that containing session_id created by tomcat instance1 is send to tomcat instance2, tomcat instance2 fails to validate the session_id ( created by instance1 ) and send a new session_id, created by instance2 in the response. Why is this happening? Has anyone face such an issue ? my tomcat is front ended by nginx Part 2: How do I enable logging for session management in tomcat? What do i need to add in logging.properties file? -- --gibu
Re: mod-jk (1.2.37) crashes Apache 2 (2.4.7) occasionally with a buffer overflow on Ubuntu 14.04 x64
Am 29.06.2016 um 11:58 schrieb Michael Diener: I get occasional Apache 2 crashes being caused by mod_jk and I'm running out of ideas about the cause of the problem. I hope somebody here can point me in the right direction. Can you reproduce? Does it also happen on a test system? tomcat6 6.0.39-1 libapache2-mod-jk 1:1.2.37-3 Latest we provide in the project is 1.2.41. It is pretty easy to compile yourself and would be an interesting check to see, whether it is just an old already fixed problem. apache2 2.4.7-1ubuntu4 java version "1.6.0_45" Java(TM) SE Runtime Environment (build 1.6.0_45-b06) Java HotSpot(TM) 64-Bit Server VM (build 20.45-b01, mixed mode) /var/log/apache2/error.log buffer overflow detected ***: /usr/sbin/apache2 terminated=== Backtrace: =/lib/x86_64-linux-gnu/libc.so.6(+0x7329f)[0x7fe9aa7de29f]/lib/x86_64-linux-gnu/libc.so.6(__fortify_fail+0x5c)[0x7fe9aa875bbc]/lib/x86_64-linux-gnu/libc.so.6(+0x109a90)[0x7fe9aa874a90]/lib/x86_64-linux-gnu/libc.so.6(+0x10ab07)[0x7fe9aa875b07]/usr/lib/apache2/modules/mod_jk.so(jk_open_socket+0x8d8)[0x7fe9a7c60cb8]/usr/lib/apache2/modules/mod_jk.so(ajp_connect_to_endpoint+0x65)[0x7fe9a7c7bf75]/usr/lib/apache2/modules/mod_jk.so(+0x36422)[0x7fe9a7c7d422]/usr/lib/apache2/modules/mod_jk.so(+0x1674c)[0x7fe9a7c5d74c]/usr/sbin/apache2(ap_run_handler+0x40)[0x7fe9ab65fbe0]/usr/sbin/apache2(ap_invoke_handler+0x69)[0x7fe9ab660129]/usr/sbin/apache2(ap_process_async_request+0x20a)[0x7fe9ab6756ca]/usr/sbin/apache2(+0x69500)[0x7fe9ab672500]/usr/sbin/apache2(ap_run_process_connection+0x40)[0x7fe9ab669220]/usr/lib/apache2/modules/mod_mpm_event.so(+0x681b)[0x7fe9a783981b]/lib/x86_64-linux-gnu/libpthread.so.0(+0x8184)[0x7fe9aab38184]/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7fe9aa86537d]* === Memory map: 7fe68800-7fe68806a000 rw-p 00:00 0 7fe68806a000-7fe68c00 ---p 00:00 0 ... 7fffa6c27000-7fffa6c48000 rw-p 00:00 0 [stack] 7fffa6c86000-7fffa6c88000 r-xp 00:00 0 [vdso] ff60-ff601000 r-xp 00:00 0 [vsyscall] [Wed Jun 29 05:01:50.052325 2016] [core:notice] [pid 1747:tid 140641581987712] AH00051: child pid 17018 exit signal Aborted (6), possible coredump in /etc/apache2 The log indicates there might be a coredump, but there is not. Configure your system so that it writes core dump files, look at the core dump file with "gdb", e.g. running "thread apply all bt full" and provide the output. Likely your httpd is running as a suid process (started as root but the children switch uid to something else, like www or similar). You have to enable core dump for suid processes explicitly in your Linux. There is no log in /var/log/apache2/mod_jk.log at the same time. /var/log/tomcat6/catalina.out Jun 29, 2016 5:01:49 AM org.apache.jk.common.ChannelSocket processConnection WARNING: processCallbacks status 2 Jun 29, 2016 5:01:49 AM org.apache.jk.common.ChannelSocket processConnection WARNING: processCallbacks status 2 The Tomcat log indicates AFAIK that the client connection has been lost. /etc/libapache2-mod-jk/httpd-jk.conf JkWorkersFile /etc/libapache2-mod-jk/workers.properties JkLogFile /var/log/apache2/mod_jk.log JkLogLevel warn JkShmFile /var/log/apache2/jk-runtime-status /etc/libapache2-mod-jk/workers.properties The next lines look like they are coming from very old and partially nonsense recipies. Your crash won't be a result of those but you should probably start to create your config based on what's inside the conf folder of our source distribution for mod_jk. The files can also be found under http://svn.apache.org/viewvc/tomcat/jk/trunk/conf/. workers.tomcat_home=/usr/share/tomcat6 workers.java_home=/usr/lib/jvm/java-6-sun ps=/ worker.list=loadbalancer worker.loadbalancer.type=lb worker.loadbalancer.balance_workers=ajp13_worker,ajp13_worker2 worker.loadbalancer.sticky_session=0 worker.ajp13_worker.port=xxx worker.ajp13_worker.host=localhost worker.ajp13_worker.type=ajp13 worker.ajp13_worker.lbfactor=50 If you don't really need the increased max_packet_size, you should comment it out here and the packetSize below and retry. Those settings are not so common. There were also changes related to them in newer versions. worker.ajp13_worker.max_packet_size=65536 Not crash related, but I don't like the general socket_timeout. Look at the configs proposed above. They use lots of good timeouts, but socket_timeout is not one of them. worker.ajp13_worker.socket_timeout=300 worker.ajp13_worker.ping_mode=A worker.ajp13_worker.secret=xxx worker.ajp13_worker.fail_on_status=503 worker.ajp13_worker.connection_pool_size=32768 #worker.ajp13_worker.activation=disabled worker.ajp13_worker.redirect=ajp13_worker2 worker.ajp13_worker2.port=xxx worker.ajp13_worker2.host=otherhost worker.ajp13_worker2.type=ajp13 worker.ajp13_worker2.lbfactor=1 worker.ajp13_worker2.max_packet_size=65536
Re: Updating Tomcat native requires APR update
On 29/06/2016 12:40, Ari Luoma wrote: > First I would like to thank you for the great job you do by responding > to these questions people have. > > I am about to update Tomcat 8.0.26 -> 8.5.3. > > I am using AJP APR connector between Tomcat and Apache. > > If I update APR (by downloading and compiling it from APR website) to > the newest do I also need to compile httpd or can it use 1.3.9 APR > with httpd when Tomcat uses 1.5.2? As long as you compile APR 1.5.2 to a separate location and don't overwrite your APR 1.3.9 build you should be fine. > Below more info about the current setup: > > One Server with: CentOS 6.3 > Apache HTTP Server 2.2.15 (installed from centos repo) > Tomcat 8.0.26 (Installed by downloading tar.gz...) > APR 1.3.9 (installed from centos repo and this is the newest version > available from repo) > Tomcat-native 1.1.33 (built from Tomcat directory) > > Server is running multiple Tomcats instances in different ports. > httpd is there at front as a proxy with configuration something like this. > > Listen 443 > NameVirtualHost *:443 > > ... > > ProxyPass ajp://localhost:8109/myWebApp/ timeout=3600 > ProxyPassReverseCookiePath /myWebApp /test > > > > > Connector on Tomcat side: > > > > #httpd -V > Server version: Apache/2.2.15 (Unix) > Server built: Aug 13 2013 17:29:28 > Server's Module Magic Number: 20051115:25 > Server loaded: APR 1.3.9, APR-Util 1.3.9 > Compiled using: APR 1.3.9, APR-Util 1.3.9 > ... > > When about to build the tomcat native 1.2.7 from Tomcat 8.5.3 it says: > configure: error: Found APR 1.3.9. You need version 1.4.3 or newer installed. Once you fix the APR issue, OpenSSL might be your next problem since tomcat native requires OpenSSL 1.0.2. There are various solutions, the simplest being to build Tomcat Native without OpenSSL support if you don't need it. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Updating Tomcat native requires APR update
First I would like to thank you for the great job you do by responding to these questions people have. I am about to update Tomcat 8.0.26 -> 8.5.3. I am using AJP APR connector between Tomcat and Apache. If I update APR (by downloading and compiling it from APR website) to the newest do I also need to compile httpd or can it use 1.3.9 APR with httpd when Tomcat uses 1.5.2? Below more info about the current setup: One Server with: CentOS 6.3 Apache HTTP Server 2.2.15 (installed from centos repo) Tomcat 8.0.26 (Installed by downloading tar.gz...) APR 1.3.9 (installed from centos repo and this is the newest version available from repo) Tomcat-native 1.1.33 (built from Tomcat directory) Server is running multiple Tomcats instances in different ports. httpd is there at front as a proxy with configuration something like this. Listen 443 NameVirtualHost *:443 ... ProxyPass ajp://localhost:8109/myWebApp/ timeout=3600 ProxyPassReverseCookiePath /myWebApp /test Connector on Tomcat side: #httpd -V Server version: Apache/2.2.15 (Unix) Server built: Aug 13 2013 17:29:28 Server's Module Magic Number: 20051115:25 Server loaded: APR 1.3.9, APR-Util 1.3.9 Compiled using: APR 1.3.9, APR-Util 1.3.9 ... When about to build the tomcat native 1.2.7 from Tomcat 8.5.3 it says: configure: error: Found APR 1.3.9. You need version 1.4.3 or newer installed. Best Regards, Ari Luoma - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
mod-jk (1.2.37) crashes Apache 2 (2.4.7) occasionally with a buffer overflow on Ubuntu 14.04 x64
I get occasional Apache 2 crashes being caused by mod_jk and I'm running out of ideas about the cause of the problem. I hope somebody here can point me in the right direction. -Michael tomcat6 6.0.39-1 libapache2-mod-jk 1:1.2.37-3 apache2 2.4.7-1ubuntu4 java version "1.6.0_45" Java(TM) SE Runtime Environment (build 1.6.0_45-b06) Java HotSpot(TM) 64-Bit Server VM (build 20.45-b01, mixed mode) /var/log/apache2/error.log buffer overflow detected ***: /usr/sbin/apache2 terminated=== Backtrace: =/lib/x86_64-linux-gnu/libc.so.6(+0x7329f)[0x7fe9aa7de29f]/lib/x86_64-linux-gnu/libc.so.6(__fortify_fail+0x5c)[0x7fe9aa875bbc]/lib/x86_64-linux-gnu/libc.so.6(+0x109a90)[0x7fe9aa874a90]/lib/x86_64-linux-gnu/libc.so.6(+0x10ab07)[0x7fe9aa875b07]/usr/lib/apache2/modules/mod_jk.so(jk_open_socket+0x8d8)[0x7fe9a7c60cb8]/usr/lib/apache2/modules/mod_jk.so(ajp_connect_to_endpoint+0x65)[0x7fe9a7c7bf75]/usr/lib/apache2/modules/mod_jk.so(+0x36422)[0x7fe9a7c7d422]/usr/lib/apache2/modules/mod_jk.so(+0x1674c)[0x7fe9a7c5d74c]/usr/sbin/apache2(ap_run_handler+0x40)[0x7fe9ab65fbe0]/usr/sbin/apache2(ap_invoke_handler+0x69)[0x7fe9ab660129]/usr/sbin/apache2(ap_process_async_request+0x20a)[0x7fe9ab6756ca]/usr/sbin/apache2(+0x69500)[0x7fe9ab672500]/usr/sbin/apache2(ap_run_process_connection+0x40)[0x7fe9ab669220]/usr/lib/apache2/modules/mod_mpm_event.so(+0x681b)[0x7fe9a783981b]/lib/x86_64-linux-gnu/libpthread.so.0(+0x8184)[0x7fe9aab38184]/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7fe9aa86537d]* === Memory map: 7fe68800-7fe68806a000 rw-p 00:00 0 7fe68806a000-7fe68c00 ---p 00:00 0 ... 7fffa6c27000-7fffa6c48000 rw-p 00:00 0 [stack] 7fffa6c86000-7fffa6c88000 r-xp 00:00 0 [vdso] ff60-ff601000 r-xp 00:00 0 [vsyscall] [Wed Jun 29 05:01:50.052325 2016] [core:notice] [pid 1747:tid 140641581987712] AH00051: child pid 17018 exit signal Aborted (6), possible coredump in /etc/apache2 The log indicates there might be a coredump, but there is not. There is no log in /var/log/apache2/mod_jk.log at the same time. /var/log/tomcat6/catalina.out Jun 29, 2016 5:01:49 AM org.apache.jk.common.ChannelSocket processConnection WARNING: processCallbacks status 2 Jun 29, 2016 5:01:49 AM org.apache.jk.common.ChannelSocket processConnection WARNING: processCallbacks status 2 The Tomcat log indicates AFAIK that the client connection has been lost. /etc/libapache2-mod-jk/httpd-jk.conf JkWorkersFile /etc/libapache2-mod-jk/workers.properties JkLogFile /var/log/apache2/mod_jk.log JkLogLevel warn JkShmFile /var/log/apache2/jk-runtime-status /etc/libapache2-mod-jk/workers.properties workers.tomcat_home=/usr/share/tomcat6 workers.java_home=/usr/lib/jvm/java-6-sun ps=/ worker.list=loadbalancer worker.loadbalancer.type=lb worker.loadbalancer.balance_workers=ajp13_worker,ajp13_worker2 worker.loadbalancer.sticky_session=0 worker.ajp13_worker.port=xxx worker.ajp13_worker.host=localhost worker.ajp13_worker.type=ajp13 worker.ajp13_worker.lbfactor=50 worker.ajp13_worker.max_packet_size=65536 worker.ajp13_worker.socket_timeout=300 worker.ajp13_worker.ping_mode=A worker.ajp13_worker.secret=xxx worker.ajp13_worker.fail_on_status=503 worker.ajp13_worker.connection_pool_size=32768 #worker.ajp13_worker.activation=disabled worker.ajp13_worker.redirect=ajp13_worker2 worker.ajp13_worker2.port=xxx worker.ajp13_worker2.host=otherhost worker.ajp13_worker2.type=ajp13 worker.ajp13_worker2.lbfactor=1 worker.ajp13_worker2.max_packet_size=65536 worker.ajp13_worker2.socket_timeout=300 worker.ajp13_worker2.ping_mode=A worker.ajp13_worker2.secret=xxx worker.ajp13_worker2.fail_on_status=503 worker.ajp13_worker2.connection_pool_size=32768 worker.ajp13_worker2.activation=disabled #worker.ajp13_worker2.redirect=ajp13_worker /etc/tomcat6/server.xml ls /etc/apache2/mods-enabled/ access_compat.load auth_basic.load authz_core.load autoindex.conf deflate.load env.load headers.load mime.conf mpm_event.load rewrite.load socache_shmcb.load status.conf alias.conf authn_core.load authz_host.load autoindex.load dir.conf expires.load jk.conf mime.load negotiation.conf setenvif.conf ssl.conf status.load alias.load authn_file.load authz_user.load deflate.conf dir.load filter.load jk.load mpm_event.conf negotiation.load setenvif.load ssl.load lsb_release -rd Description: Ubuntu 14.04.4 LTS Release: 14.04
Re: AW: wrong request.getServerPort value reported on upgraded HTTP/2 connector ?
On 29/06/2016 07:50, Frank Taffelt wrote: > i have no other connectors than the one on port 443. I can reproduce this. I'll look at getting this fixed for the next release. Mark > > -Ursprüngliche Nachricht- > Von: Christopher Schultz [mailto:ch...@christopherschultz.net] > Gesendet: Dienstag, 28. Juni 2016 17:56 > An: Tomcat Users List > Betreff: Re: wrong request.getServerPort value reported on upgraded HTTP/2 > connector ? > > Frank, > > On 6/28/16 11:02 AM, Frank Taffelt wrote: >> Calling the method request.getServerPort() returns 80 on http/2 >> upgraded requests for the https connector. I would expect that this >> method should return 443 in these calls. My current workarround is to >> disable the APR Listener as this results in correct value for the >> https connector. So is this a bug? > > Definitely seems like a bug. You have no other connectors defined other than > the one on port 443? > > -chris > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
AW: Memory Leak
Hi
> > Here, the log. I am quite sure how to go about troubleshooting it.
> > Any help is greatly appreciated.
> The application has a memory leak. You need to get it fixed.
> > catalina.out.prob:SEVERE: The web application [] appears to have
> > started a thread named
> > [cluster-ClusterId{value='5745ebcecdb2e06579174645',
> > description='null'}-devnymongodb01.meridiancapital.com:27017] but has
> > failed to stop it. This is very likely to create a memory leak.
There MIGHT be a memory leak but this does NOT have to be one.
I have seen several libraries that tell their maintenance threads to stop and
they actually DO, but the library itself does no join() so the thread stops a
little later (depending on the library, "little" was between a few milliseconds
and 10 minutes).
But this message is only logged when the application is stopped, so if it runs
out of memory during operation, this is a rather unrelated shutdown problem.
Anyway, check if there is a memory leak by taking a memory dump (probably using
jmap) and analyze that.
Eclipse MAT has nice tools for this.
> > MemTotal:8061448 kB
> > MemFree: 5399052 kB
This means that your server has 5.3 GB free memory.
Do you configure the amount of memory assigned to tomcat in any way?
If you have 5.3 GB of free memory while tomcat starves, you misconfigured that.
(Misconfiguration might as well include not configuring min/max heap sizes at
all.)
Regards,
Steffen
smime.p7s
Description: S/MIME cryptographic signature
AW: wrong request.getServerPort value reported on upgraded HTTP/2 connector ?
i have no other connectors than the one on port 443. -Ursprüngliche Nachricht- Von: Christopher Schultz [mailto:ch...@christopherschultz.net] Gesendet: Dienstag, 28. Juni 2016 17:56 An: Tomcat Users List Betreff: Re: wrong request.getServerPort value reported on upgraded HTTP/2 connector ? -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Frank, On 6/28/16 11:02 AM, Frank Taffelt wrote: > Calling the method request.getServerPort() returns 80 on http/2 > upgraded requests for the https connector. I would expect that this > method should return 443 in these calls. My current workarround is to > disable the APR Listener as this results in correct value for the > https connector. So is this a bug? Definitely seems like a bug. You have no other connectors defined other than the one on port 443? - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJXcp4aAAoJEBzwKT+lPKRYfwgP/isAFGcsIB0XcgY/SCzVYdas WO0gBJmDl8IiDG7ALYQ+XZqvCaZZbQRvLZ5se6gx9UGbnpKqTV27j51kSEKb9txE sat8y7JmYlwrnTrxu6vDgPYHODYs+tI7ilYC02YSBth9v9E6I14egEV7bEv5H0F4 zYavdyO8jUFDFnv/tqllPfu0vm58BSHZnGHJcnSLU3hqijJOcS1edEq+jzj/xAJr GtMi8ehI2RMSGq5nizl5Yc3zuc3jlsvilpPSc3ygqJfNltKBKDnNivUPWONF4ozS Ibl6o1Rs8hs132xZka1OPI3+BlTc9HkQgHU3jvrQlfkWzNjv6ogM6Q5B76Jgv65T li65XFLmw9x6SdUWn93S4FIQIJs/rYoJyX53ZwSlHiONFZh2C4KlDCzQPJ6iMt5z UdQeUHCHZ2xZURmScSpVAOkyGog6V84kHtaDVPgD8+umNBqA+ujy7abDb6ZdKDuC Yke6RssFatQmWBGJkp3JORPOIq1C1sNh64Gd1hz8U17kHK0zmffYis5aqeFPxUxr 2jEz1VAbsZULDclpWi2JW4TKezVrOykmQ4Dmgz//OOKeXW1XCwtaigK/c3XSv95D cm3tpaGUsdhLUM75YaK/H1sLKwVyav6rubYrXWmKvTOPgO4sd3DlXFbW5T7NT+CR ikuriVBWliBg8rb61KlH =b+VE -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Runtime Cloning of DataSource for Different DB?
On 29/06/2016 05:12, Terence M. Bandoian wrote:
> On 6/28/2016 3:56 AM, Mark Thomas wrote:
>> On 27/06/2016 22:35, Jerry Malcolm wrote:
>>> Mark,
>>>
>>> On 6/27/2016 1:07 PM, Mark Thomas wrote:
On 27/06/2016 17:44, Jerry Malcolm wrote:
> I'm assuming that context.lookup(...) simply locates the "jdbc/myDB"
> tag in the context.xml file, pulls all of the parms out of
> that tag, creates a DataSource object utilizing the parms, and returns
> it.If that's the case, couldn't I create a variation/subclass
> of the
> Context object that modifies the url parm that it found in the
> resource
> tag and puts the desired db name into the url before constructing the
> DataSource?
Sure.
You need to implement the appropriate factory and then specify your
factory class explicitly in the Resource element using the factory
attribute.
You probably want to start here for ideas on how to code up your
factory:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/naming/factory/
or for a more specific example:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/dbcp/dbcp2/BasicDataSourceFactory.java?view=annotate
Mark
>>> Thanks so much. This looks doable. Just to make sure I have the big
>>> picture correct
>>>
>>> 1) I will define a new custom resource that returns a custom context
>>> object that I write.
>>> 2) On the tag for my custom context resource I can put all of
>>> the standard DataSource parms
>>> 3) I then call lookup() on this custom context passing the dbName in
>>> 4) This custom context will build an appropriate Reference object with
>>> all the parms, instantiate a BasicDataSourceFactory, and call
>>> getInstance(.) on the factory.
>>>
>>> When I need an instance of the datasource:
>>> Context initContext = new InitialContext();
>>> Context envContext =
>>> (Context)initContext.lookup("java:/comp/env");
>>> MyDataSourceContext dsContext = (MyDataSourceContext)
>>> envContext.lookup( "dsContext/myDSContext" );
>>> DataSource myDS = (DataSource) dsContext.getInstance(
>>> "dbName" );
>>>
>>> Am I getting close?
>> Yes, but I don't think you want to use custom NamingContexts. I think
>> there is a simpler way.
>>
>> 1. Write a custom DataSource factory that provides a getDataSource(...)
>> method that allows you to pass in whatever per instance config you need.
>> This DataSource factory will need to use bean style setters (like the
>> example I linked to) to pick up the other config from the
>>
>> 2. Write a custom resource factory that returns an instance of your
>> DataSource factory.
>>
>> 3. Add a context Resource element for your DataSource factory,
>> remembering to use the factory element and specify the custom resource
>> factory from 2.
>>
>> HTH,
>>
>> Mark
>
>
> If external configuration were not required, would there be a problem
> instantiating a DataSource directly and setting any required properties
> programmatically? Would any functionality be lost?
The option of a global resource shared between multiple web apps is lost.
You'd need a mechanism (a statics would work) to store and retrieve the
DataSource.
> Also, if there were base properties set in a element, would
> there be a problem using a copy of the properties from that data source,
> modified as necessary, to instantiate a new DataSource?
No, but you'd need to be careful since multiple requests for the same
DataSource should return the same object. You'd need to be able to
differentiate between a request for a new DataSourece and a previously
created one.
Mark
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
