[OT]Re: Tomcat server apparently bouncing up and down
Talking nicely and understandingly to it won't help either, I guess... Have a nice weekend Peter > Am 19.08.2017 um 08:31 schrieb André Warnier (tomcat) : > > 3 kids raised, 30 years of programming talking : slap it. > > > - > 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: Tomcat server apparently bouncing up and down
3 kids raised, 30 years of programming talking : slap it. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat server apparently bouncing up and down
On 8/18/17, 1:41 PM, Christopher Schultz wrote: You say that you aren't running it as a service. How then are you running Tomcat? startup.sh and shutdown.sh from a command line. Just starting catalina.sh from the CLI directly? If you run it in the background, are you running it with nohup? If not, your console closing might be killing the Java process. Hmm... but you said that Tomcat does in fact shut down when you login and stop it. Probably not a SIGHUP killing the process. When it's unresponsive, it's apparently still running. But it's not just our context that's unresponsive; manager is also unresponsive. And we run with autodeploy disabled: aside from being a huge context that takes a while to deploy, it's also one that often needs to be stopped, have instance-specific values set in its web.inf, and then get restarted, before it can function normally. If you stop Tomcat (when it's unresponsive), then re-start it, does it appear to work correctly right away, or do you need to do anything else to get it to work again? It opens up the port immediately, and serves a sign-on page for our webapp as soon as it's had a chance to initialize. I looked in the latest localhost access log, and no sign of anything suspicious there. -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat server apparently bouncing up and down
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 James, On 8/18/17 3:48 PM, James H. H. Lampert wrote: > This is not with the Debian apt-get that I'm having trouble > figuring out where it's finding its webapp contexts. > > It's with the downloaded-from-Apache one that I've got running (on > port 7070, no HTTPS) on a CentOS 5 box, and that I haven't figured > out how to run as a service (but that's not the immediate > problem). > > It seems that the Tomcat server was apparently running fine for > several days (albeit unmonitored and without any firewall opening > allowing it to be reached from outside, up until yesterday > afternoon), up until a few hours ago. Then it started going down. > > Yesterday afternoon, I put our webapp context on it, and changed > the port forwarding in the firewall, so that the outside access > (and therefore, the Site24x7 monitor on this particular server) > pointed to it, rather than to what it replaced. > > And then I got a message from Site24x7 telling me that it had gone > down. After a brief inspection, I shut it down and restarted it. > > Less than an hour later, the same story. And a third time. > > The fourth time, I had my hands too full to go in and manually > restart it, and to my surprise, without my having restarted it, I > got a message from Site24x7 telling me it was back up. > > And it bounced up and down a few times since then. I eventually > shut it down. > > There's nothing in catalina.out between our webapp announcing that > it was running (9:14 AM), and the messages from my shutting it down > (11:46 AM). > > So far as I've been able to determine, when it's reported as down, > it's not accepting requests even from within the LAN. > > Anybody ever seen anything like this before? Do you know how the monitoring service tests the service for its "liveness"? Is there anything (else) in the log files? There may be something in the files other than catalina.out. I know that I still have trouble in a dev environment with Tomcat repeatedly detecting changes on the filesystem and re-deploying a context multiple times, even when there have been no changes after the one that caused the initial reload. Have you enabled an access log? If so, can you see the requests both before and after the service appears to go offline? You say that you aren't running it as a service. How then are you running Tomcat? Just starting catalina.sh from the CLI directly? If you run it in the background, are you running it with nohup? If not, your console closing might be killing the Java process. Hmm... but you said that Tomcat does in fact shut down when you login and stop it. Probably not a SIGHUP killing the process. If you stop Tomcat (when it's unresponsive), then re-start it, does it appear to work correctly right away, or do you need to do anything else to get it to work again? - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlmXUOYACgkQHPApP6U8 pFhrNw/+JKhveJc7Zg7gtZ4WBGrWa42jibjIXJOV62VgLRyjaCFIowltwxXpHz9F S2p91A8MYGOYnvMMHU8QHwdC+KW6gR+SoKBVHImHzz1MUJpC6Oru/Np1dcGaM4Jg 7pn4SoWXeMCWrZqt/3keQ2YvsU8ZSUgh6957AF0pYnBmXNkkYZ3LMJ+2Y1UILWZA +DBuuHRnn73YGPu0S8vLQvFr6PQwbbVUVmIe+Lp5i069G1FPHa+9zYdwlUjF5P9l gewCgVidcQE1rSoNyW2FiiNqEtQgths4sV6a34DVi2e5ez6FMGMXk4qcrcZmdP3f lOL0L+QYBvhfXXH/Vl83Bn42lQI2WMVv0nozb/NTr41kUVIbZBbERWQLRmmxqVGs irz/L/6YgGcWX/Mj+ib9mP6SJpqSXrJwBlVeudkG8V4uVkEGzFIy3PwURCNScGrJ 9xVeBz+eBEU0kcgJGP8AcGaO6MuhEnvsuVgVLpSpCAv1m2jrB68/9a1LfU+gfnfL vu6TIaDb0ivqMeD76y3XD4FLOINdAY/eKv6OSRGG+sGI7qCd/K3PQf7nj8qHnDVA QlAsmE7tA6gJb8ULDOdTYFuLDgOoEpkaCHatMP/QAOZf8CgX4uHKB73r7VA2q5Kc Kk0qIJ2stmnIah0BJVXk/sLAtYmxLOc7WzYzJf9SUK43tbZ6eM8= =fmwC -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat server apparently bouncing up and down
This is not with the Debian apt-get that I'm having trouble figuring out where it's finding its webapp contexts. It's with the downloaded-from-Apache one that I've got running (on port 7070, no HTTPS) on a CentOS 5 box, and that I haven't figured out how to run as a service (but that's not the immediate problem). It seems that the Tomcat server was apparently running fine for several days (albeit unmonitored and without any firewall opening allowing it to be reached from outside, up until yesterday afternoon), up until a few hours ago. Then it started going down. Yesterday afternoon, I put our webapp context on it, and changed the port forwarding in the firewall, so that the outside access (and therefore, the Site24x7 monitor on this particular server) pointed to it, rather than to what it replaced. And then I got a message from Site24x7 telling me that it had gone down. After a brief inspection, I shut it down and restarted it. Less than an hour later, the same story. And a third time. The fourth time, I had my hands too full to go in and manually restart it, and to my surprise, without my having restarted it, I got a message from Site24x7 telling me it was back up. And it bounced up and down a few times since then. I eventually shut it down. There's nothing in catalina.out between our webapp announcing that it was running (9:14 AM), and the messages from my shutting it down (11:46 AM). So far as I've been able to determine, when it's reported as down, it's not accepting requests even from within the LAN. Anybody ever seen anything like this before? -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat memory
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Leon, On 8/17/17 6:57 AM, Leon Rosenberg wrote: > Fady, one thing, > > analyzing heap dumps is hard especially a 10GB dump, you will need > at least 40 Gb of memory an about 10 hours to start jhat. What is > fast is analyzing a histogram. A histogram is a list of all > classes in your JVM and amount of memory they use. It is very easy > to use: > > jmap -histo:live >outputfile the :live parameter is > important, otherwise you will see dead objects as well. Keep in > mind a major gc will be triggered. > > The output looks like this: > > num #instances #bytes class name > -- 1: 98573 > 13165976 [C 2: 4376 11325928 [B 3: 96526 > 2316624 java.lang.String 4: 405221296704 > java.util.HashMap$Node 5: 10954 807552 > [Ljava.lang.Object; 6: 7494 781480 > java.lang.Class 7: 6778 655464 > [Ljava.util.HashMap$Node; ... > > 3103: 1 16 > sun.util.locale.provider.TimeZoneNameUtility$TimeZoneNameGetter > 3104: 1 16 sun.util.resources.LocaleData > 3105: 1 16 > sun.util.resources.LocaleData$LocaleDataResourceBundleControl Total > 456560 37330672 > > This won't point you to exact direction of memory leak or resource > consumption, but you will see what classes are consuming memory. So > if you find out that class foo.bar.XYZBean has 10.000.000 instances > and occupies 2 gb of memory, you know where to look. > > Keep in mind that only memory directly used by a class is counted, > so every string will appear twice, as string and as byte array. > > If you see that the used memory amount is growing, take multiple > histograms, every 10 minutes or so and analyse the differences. I > wrote a little script years ago for myself ( > https://github.com/dvayanu/ldt/blob/c8b3c2b6f61de5c583db503f6fd5e2d8aa 8b9aa0/java/ldt/histo/HistoDiffReader.java) > > that takes two histograms and prints out the differences. This way you c an > see if new instances of a specific class(es) are accumulated over > time. In this case you have a memory leak. The OP's report sounds more like a great disparity between native memory versus heap memory usage. The Java heap, of course, is only a part of the actual (virtual) RAM used by the process; there are plenty of non-heap memory resources required by the JVM for everything. I've not found a great tool for inspecting native memory spaces in a JVM. My recommendation would be that the OP make sure he/she has the latest possible version of the JVM available, just in case there is a memory leak in the JVM itself. The same should be done with all other libraries in case any memory leaks exist and have been fixed. - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlmW7WAACgkQHPApP6U8 pFhd9RAAsjPO/BTFX2RRZH0SRry2b0Pb1tMlGwPBW0tEesQRnLn+zS5l3FaSrwJJ 7Ar9fJhcwIiGZdDq15hURg9vVJFoEEfh3jhhOTH8DafDFfjneEnwzrvUcdyyrlpL 8tyXByTpk0H51HPaEkhm0YJlSY6rSQuVOfVNOY+HrFSQiDxidqU5l5igUdnmczk1 0Z+AXuOB+oF1E1XkihPfDpX1TwsImuGKylBe7Rmng4KWA8J8d9Xo17bXH2DfgDOm zt0iSTYZ3Hus1T84zpO4qCm9NWvYvROMACcTweYJ8VsgXkjnacVZhSP4NA3vlGF4 TuzxnyUWngbB82ERoiD0BY99406fcxvAyyJ1H1EQ7Z76UlRWKaQgGWK3U/Fb4kI0 6ugXV9daNmGYGar9rHmSGccUzkyqzOnjinFOF3OYaAs8eyFPvXlB0TvXWbQUQESe Jx4YK+vmtGVIUlM/c4selCPPKpryOkRfjjqBdDOnrJYWbp6bYlMtRpzO19TpCOIA qve6SWCVhEhzviXbW+xs0GH2QQHuveDzc5XIZC7ysX3Y5kTdJlOvH0j9pWCeMaQ5 1tAKj2jiI/m9VirjsFpxC0hy8lRB1wqrJQdaIRwWtaMEO7zVy20igyEMrw/tXOcv 6K14O6hMQPqaE1ge8xFk+IzEzyceaCzmv3xw8C5FRlIntzlFFBM= =KFMx -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Where Tomcat webapp contexts live on Debian
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Leon, On 8/16/17 3:24 AM, Leon Rosenberg wrote: > Debian has a long tradition of doing things in a very special way > when it comes to java. Long enough they shipped GnuJ as standard > JVM with a debian distribution, a piece of garbage that wasn't able > to start simplest of java programs. But there has been an as long > tradition to reply to every question about tomcat behaviour on a > specific distribution by suggesting to throw the crap away and > download the vanilla tomcat form the one and only legal source ;-) > (at least in the past, to which debian belongs). Debian has tried to make Tomcat's configuration work the same way that httpd does, with lots of little configuration files, etc. that all contribute to a complex system. For users of a vanilla Tomcat installation, it seems crazy. For longtime users of httpd (at least, on Debian), it seems perfectly natural. Debian's package structure makes sense if you think of Tomcat as modular. It's quite reasonable for you to, for instance, NOT install/deploy the manager application. If you download and install the vanilla Tomcat, you have to move/rename/delete the manager application. On Debian, it's the other way: you have to opt-into the manager application by installing it as a separate package. Unless Debian's package-managed version of Tomcat are actively irritating you, I would recommend attempting to learn how they work and get comfortable with them. The package manager will keep the packages up-to-date and working with minimal maintenance on your part - -- at the cost (at least, on Debian) of always being fairly delayed in terms of version numbers. They will back-port all security fixes, but you may be stuck on e.g. 7.0.35 for several years until you get a new distribution update (e.g. Debian 6 -> Debian 7). This is either a nightmare or a dream for you. Debian is insanely stable, which is great. The downside to that is that it's *extremely* stable. :) - -chris > On Wed, Aug 16, 2017 at 7:43 AM, Peter Kreuser > wrote: > >> I'd assume the service that starts tomcat sets the bin-Dir, that >> contains a setenv.sh, that has the CATALINA_HOME and BASE >> env-Varaibles, where you find the context-Files that have a >> docbase. >> >> I'd like to repeat the question: who did this setup? >> >> Peter Kreuser >> >>> Am 15.08.2017 um 23:45 schrieb James H. H. Lampert < >> jam...@touchtonecorp.com>: >>> >>> I think I've mentioned before that I have a Tomcat server on a >>> Google >> Compute Debian instance, that I installed with an "apt-get," >> rather than from an Apache download. >>> >>> I had to apt-get manager separately, which is odd to begin >>> with. >>> >>> And things ended up in unexpected places. >>> >>> Some stuff (like the Catalina directory) wound up in >>> /etc/tomcat7. Other >> stuff (like the bin and lib directories) wound up in >> /usr/share/tomcat7. >>> >>> But the weirdest thing is where the webapp contexts wound up. >>> The >> default ROOT context (which doesn't look quite like the default >> ROOT context of anything I've installed from an Apache download) >> is in /var/lib/tomcat7/webapps/ROOT. But the manager and >> host-manager webapps are in /usr/share/tomcat7-admin/manager and >> /usr/share/tomcat7-admin/host- manager. >>> >>> Setting aside any questions of why whoever set this up for >>> Debian did it >> this way, all of this still raises a very big question: >>> >>> How is Tomcat finding all of this? >>> >>> -- JHHL >>> >>> - - >>> >>> 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 >> >> > -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlmW6p0ACgkQHPApP6U8 pFg0fA//VBlLtTW6lvC54Z2Sf+9P1XzSLybW7qJVzKhZRMl3RDgLnBxNj9khV3yU YTt+d/YWGpmBNWS7rWocP5kfWWUXh7vHZqcADWLr/hEA534X+QO/FQWDT7bIrtU8 oSO8yP6iU3fLb8vDbMUmh6szDGol0QPE8H/x6Fg8FyLhUT5EV6gaR157o8+Q9/O6 lyO1koul+XJzGvq9BsbYsJv5Dvy6gPjzEc2tRMK68Q1npNLJHOgwpMM09ppe63yR YVaAsPlReCCGpM31Nh7vzVGOIqVUS34hbiVkheO1rD9kVKyR25S4KGhJHyS/tkHj 74z9BuO13K+YjZzQJr2SNf95O4RgIsw3C0CgdnL7hF2XY2lYOrmfFhpdoR7YMBC9 YqXXvpkxiGUbYPdiVmq8DO/DSkLfmXgaUdNlqTNqu2gXGTs84801q4ocojKBp0a2 L894scVRn4B+olkGWdf+yEaJTm5xrMvJ0gMw9s32ZFgRZet+Yz4kSnO+9nHszvfj cvAZ/NT2NPuMXe2POv64ARupB6A9w/gTppuV/WC7gqxslZfNQwrqj+RMjXc4ypIr /OuaRXLSI17xVb1zJ3nL/zuzfYXpzH1uVAG5eEi7GM+oUXzZjslQSdiyxnn1Ur1/ EJN2PN9yGcYCiDlv4qxJMtYc1yYFz18PSgCMCRVscTWj5aw0DeE= =CDMF -END PGP SIGNATURE- - To unsubscribe, e-mail: use
Re: Cluster StaticMember (McastService:Required property "tcpListenPort" is missing)
Hello,
It seems to me that it's always necessary to initialize
membershipService, maybe something like that (untested):
---
apache-tomcat-7.0.70-src/java/org/apache/catalina/tribes/group/ChannelCoordinator.java.original
2016-06-15 18:45:51.0 +0200
+++
apache-tomcat-7.0.70-src/java/org/apache/catalina/tribes/group/ChannelCoordinator.java
2017-08-18 13:19:53.342672900 +0200
@@ -148,6 +148,10 @@
}
clusterReceiver.start();
//synchronize, big time FIXME
+
membershipService.setLocalMemberProperties(getClusterReceiver().getHost(),
+
getClusterReceiver().getPort(),
+
getClusterReceiver().getSecurePort(),
+
getClusterReceiver().getUdpPort());
Member localMember = getChannel().getLocalMember(false);
if (localMember instanceof StaticMember) {
// static member
@@ -155,13 +159,6 @@
staticMember.setHost(getClusterReceiver().getHost());
staticMember.setPort(getClusterReceiver().getPort());
staticMember.setSecurePort(getClusterReceiver().getSecurePort());
-} else {
-// multicast member
-
membershipService.setLocalMemberProperties(getClusterReceiver().getHost(),
-getClusterReceiver().getPort(),
-getClusterReceiver().getSecurePort(),
-getClusterReceiver().getUdpPort());
-
}
valid = true;
}
Regards,
Carlos.
On Fri, Aug 18, 2017 at 9:51 AM, Carlos Peon Costa wrote:
> The reason could be here:
>
> $ diff -r
> apache-tomcat-7.0.69-src/java/org/apache/catalina/tribes/group/ChannelCoordinator.java
> apache-tomcat-7.0.70-src/java/org/apache/catalina/tribes/group/ChannelCoordinator.java
> 146,149c151,165
> <
> membershipService.setLocalMemberProperties(getClusterReceiver().getHost(),
> <
> getClusterReceiver().getPort(),
> <
> getClusterReceiver().getSecurePort(),
> <
> getClusterReceiver().getUdpPort());
> ---
>> Member localMember = getChannel().getLocalMember(false);
>> if (localMember instanceof StaticMember) {
>> // static member
>> StaticMember staticMember = (StaticMember)localMember;
>> staticMember.setHost(getClusterReceiver().getHost());
>> staticMember.setPort(getClusterReceiver().getPort());
>>
>> staticMember.setSecurePort(getClusterReceiver().getSecurePort());
>> } else {
>> // multicast member
>>
>> membershipService.setLocalMemberProperties(getClusterReceiver().getHost(),
>> getClusterReceiver().getPort(),
>> getClusterReceiver().getSecurePort(),
>> getClusterReceiver().getUdpPort());
>>
>> }
>
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Cluster StaticMember (McastService:Required property "tcpListenPort" is missing)
Hello,
Cluster static members seem to fail since version 7.0.70 (also
reproduced in 8.0.45):
SEVERE: The required Server component failed to start so Tomcat is
unable to start.
...
Caused by: org.apache.catalina.tribes.ChannelException:
java.lang.IllegalArgumentException: McastService:Required property
"tcpListenPort" is missing.; No faulty members identified.
at
org.apache.catalina.tribes.group.ChannelCoordinator.internalStart(ChannelCoordinator.java:200)
at
org.apache.catalina.tribes.group.ChannelCoordinator.start(ChannelCoordinator.java:100)
at
org.apache.catalina.tribes.group.ChannelInterceptorBase.start(ChannelInterceptorBase.java:162)
at
org.apache.catalina.tribes.group.interceptors.StaticMembershipInterceptor.start(StaticMembershipInterceptor.java:168)
at
org.apache.catalina.tribes.group.ChannelInterceptorBase.start(ChannelInterceptorBase.java:162)
at
org.apache.catalina.tribes.group.GroupChannel.start(GroupChannel.java:431)
at
org.apache.catalina.ha.tcp.SimpleTcpCluster.startInternal(SimpleTcpCluster.java:689)
... 15 more
Caused by: java.lang.IllegalArgumentException: McastService:Required
property "tcpListenPort" is missing.
at
org.apache.catalina.tribes.membership.McastService.hasProperty(McastService.java:360)
at
org.apache.catalina.tribes.membership.McastService.start(McastService.java:379)
at
org.apache.catalina.tribes.group.ChannelCoordinator.internalStart(ChannelCoordinator.java:182)
... 21 more
The reason could be here:
$ diff -r
apache-tomcat-7.0.69-src/java/org/apache/catalina/tribes/group/ChannelCoordinator.java
apache-tomcat-7.0.70-src/java/org/apache/catalina/tribes/group/ChannelCoordinator.java
28a29,30
> import org.apache.catalina.tribes.membership.StaticMember;
> import org.apache.catalina.tribes.transport.ReceiverBase;
143a146,148
> if (clusterReceiver instanceof ReceiverBase) {
> ((ReceiverBase)clusterReceiver).setChannel(getChannel());
> }
146,149c151,165
<
membershipService.setLocalMemberProperties(getClusterReceiver().getHost(),
<
getClusterReceiver().getPort(),
<
getClusterReceiver().getSecurePort(),
<
getClusterReceiver().getUdpPort());
---
> Member localMember = getChannel().getLocalMember(false);
> if (localMember instanceof StaticMember) {
> // static member
> StaticMember staticMember = (StaticMember)localMember;
> staticMember.setHost(getClusterReceiver().getHost());
> staticMember.setPort(getClusterReceiver().getPort());
>
> staticMember.setSecurePort(getClusterReceiver().getSecurePort());
> } else {
> // multicast member
>
> membershipService.setLocalMemberProperties(getClusterReceiver().getHost(),
> getClusterReceiver().getPort(),
> getClusterReceiver().getSecurePort(),
> getClusterReceiver().getUdpPort());
>
> }
but I can't see why and go forward alone ;). If I'm not wrong, posting
in this mailing list is the proper way to go.
Regards,
Carlos.
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
