| 00:42.54 | *** join/#tomcat factor (~factor@75.108.161.36) |
| 01:21.44 | *** join/#tomcat hybridpo1lo (~hybridpol@50.56.228.65) |
| 01:21.45 | *** join/#tomcat draemon__ (~draemon@trapdoor.vm.bytemark.co.uk) |
| 02:49.29 | *** join/#tomcat infinitiguy (~stashersl@pool-108-20-195-233.bstnma.fios.verizon.net) |
| 04:35.46 | *** join/#tomcat infinitiguy (~stashersl@pool-108-20-195-233.bstnma.fios.verizon.net) |
| 05:26.09 | *** join/#tomcat vigneshwaran (~vigneshwa@182.71.239.158) |
| 06:00.13 | *** join/#tomcat vigneshwaran (~vigneshwa@182.71.239.158) |
| 06:25.47 | *** join/#tomcat opalka (~ropalka@84.64.broadband3.iol.cz) |
| 06:25.47 | *** join/#tomcat opalka (~ropalka@redhat/jboss/opalka) |
| 06:26.53 | *** join/#tomcat papegaaij (~papegaaij@5ee53fc2.ftth.concepts.nl) |
| 06:28.13 | *** join/#tomcat mike817 (~mike817@ool-44c27cf2.dyn.optonline.net) |
| 06:42.36 | *** join/#tomcat zerobravo (~zerobravo@93-141-47-226.adsl.net.t-com.hr) |
| 07:08.43 | *** join/#tomcat lkoranda (lkoranda@nat/redhat/x-qtbyltaxucyfrmtp) |
| 07:20.10 | *** join/#tomcat vigneshwaran (~vigneshwa@182.71.239.158) |
| 07:36.28 | *** join/#tomcat _moon (~moon@LNeuilly-152-22-7-151.w193-251.abo.wanadoo.fr) |
| 07:48.45 | *** join/#tomcat Gio^ (~VaNNi___@dti-rtr.wtc.aerioconnect.net) |
| 07:51.45 | *** join/#tomcat Mimiko (~Mimiko@77.89.245.38) |
| 07:52.11 | *** join/#tomcat _Qman (~Q@213.177.160.238) |
| 07:54.21 | *** join/#tomcat BuenGenio (~BuenGenio@059148208218.ctinets.com) |
| 07:54.34 | BuenGenio | hellp |
| 07:55.13 | BuenGenio | what can be the reason for a java.lang.ClassNotFoundException: com.dotv.streetlightserver.api.soap.SLVAxisSessionListener error, when the jar that contains the library is loaded by tomcat? |
| 07:55.33 | BuenGenio | <PROTECTED> |
| 07:55.33 | BuenGenio | java 14649 tomcat7 mem REG 252,2 796275 660896 /usr/share/tomcat7/lib/lib/streetlight.jar |
| 07:55.33 | BuenGenio | java 14649 tomcat7 64r REG 252,2 796275 660896 /usr/share/tomcat7/lib/lib/streetlight.jar |
| 08:00.17 | *** join/#tomcat vigneshwaran (~vigneshwa@182.71.239.158) |
| 08:01.56 | *** join/#tomcat mturk (~mturk@57-46.dsl.iskon.hr) |
| 08:01.57 | *** join/#tomcat mturk (~mturk@redhat/jboss/mturk) |
| 08:39.45 | *** join/#tomcat alcir (~alcir@159.213.59.135) |
| 08:40.14 | *** join/#tomcat vigneshwaran (~vigneshwa@182.71.239.158) |
| 08:41.46 | *** join/#tomcat xuesheng (~pawelek@cs78175239.pp.htv.fi) |
| 09:20.23 | *** join/#tomcat vigneshwaran (~vigneshwa@182.71.239.158) |
| 09:30.17 | *** part/#tomcat xuesheng (~pawelek@cs78175239.pp.htv.fi) |
| 10:00.22 | *** join/#tomcat vigneshwaran (~vigneshwa@182.71.239.158) |
| 10:27.06 | *** join/#tomcat lkoranda_ (lkoranda@nat/redhat/x-wjlfbrukmhocfunr) |
| 10:34.10 | *** join/#tomcat xuesheng (~pawelek@cs78175239.pp.htv.fi) |
| 10:35.53 | *** join/#tomcat BuenGenio (~BuenGenio@cm218-252-100-177.hkcable.com.hk) |
| 10:40.21 | *** join/#tomcat vigneshwaran (~vigneshwa@182.71.239.158) |
| 10:41.16 | *** part/#tomcat ed8 (~ed8@82.225.177.85) |
| 11:01.34 | *** join/#tomcat lkoranda (lkoranda@nat/redhat/x-yvffixitoudqznfv) |
| 11:12.40 | *** part/#tomcat xuesheng (~pawelek@cs78175239.pp.htv.fi) |
| 11:38.39 | *** join/#tomcat hjb_ (~hjb@unaffiliated/hjb) |
| 12:41.20 | *** join/#tomcat webguynow (~webguynow@c-24-1-222-204.hsd1.il.comcast.net) |
| 13:35.24 | *** join/#tomcat SmokeyD (~SmokeyD@e137009.upc-e.chello.nl) |
| 13:36.15 | SmokeyD | hey everyone. Does anyone know of a webapp that I can deploy in tomcat that just shows the logs from /var/log/tomcat/ (with authentication, an possibly configurable which logs to show)? |
| 13:41.56 | *** join/#tomcat acidjnk22 (~havenone@p57B8DD70.dip.t-dialin.net) |
| 13:53.35 | *** join/#tomcat whartung_ (~whartung@wsip-98-189-78-118.oc.oc.cox.net) |
| 13:58.06 | *** join/#tomcat mturk (~mturk@57-46.dsl.iskon.hr) |
| 13:58.06 | *** join/#tomcat mturk (~mturk@redhat/jboss/mturk) |
| 14:05.13 | *** join/#tomcat infinitiguy (~stashersl@173-162-135-105-NewEngland.hfc.comcastbusiness.net) |
| 14:32.01 | *** join/#tomcat xnyx (~xnyx@wsd-079-066.merlin.mb.ca) |
| 14:32.04 | xnyx | heya folks... |
| 14:32.32 | xnyx | would there be any reason why I couldnt have 20 tomcat servers all read the same webapps dir via NFS ? |
| 14:39.01 | SmokeyD | xnyx, depends, if it is read-only, it might be possible. But at least during deployment, those webapps dirs would be written into and some webapps might also write logs or other data in their webapps dir |
| 14:39.53 | *** join/#tomcat BuenGenio (~BuenGenio@203.145.92.164) |
| 14:40.14 | SmokeyD | which would mean simultaneous writes from different tomcat servers on the same file. That would definately cause trouble. NFS has file locks, but I wouldn't want to bet anything on it working properly |
| 14:41.56 | pucko | another solution is to put $CATALINA_BASE/conf/Catalina/<yourhostname>/ on the nfs, and use context-descriptors to point to the WAR |
| 14:44.08 | *** join/#tomcat lkoranda_ (lkoranda@nat/redhat/x-ltfunsxnjgqtdxmm) |
| 14:44.41 | pucko | a second solution is to set the attribute unpackWAR to false, which would make the tomcats not unpack the war's in the webapps. |
| 14:44.56 | *** join/#tomcat yassine (~yassine@unaffiliated/yassine) |
| 14:46.09 | xnyx | hrmmm |
| 14:46.18 | xnyx | perhaps Im comming at this from the wrong aproach... |
| 14:47.04 | xnyx | I will have an unknown number of tomcat servers, Im starting with 10 right now but expect to scale beyond 20... I need a war file deployment method |
| 14:48.56 | pucko | well, the NFS-solution should work I guess with unpackwar=false. as tomcat only reads from the file and never writes, the chance of NFS screwing up should be ok |
| 14:50.22 | pucko | just make sure that only /webapps is on the shared drive, not /work or /conf |
| 15:04.40 | *** join/#tomcat lkoranda (lkoranda@nat/redhat/x-rbawxxrypieuxjsb) |
| 15:17.18 | *** join/#tomcat lkoranda (lkoranda@nat/redhat/x-xnkaqkshwoszrmul) |
| 16:30.24 | *** join/#tomcat jasonb_ (d871a88d@gateway/web/freenode/ip.216.113.168.141) |
| 17:16.42 | *** join/#tomcat xuesheng (~pawelek@cs78175239.pp.htv.fi) |
| 17:21.38 | *** join/#tomcat acidjnk22 (~havenone@p57B8DD70.dip.t-dialin.net) |
| 17:40.35 | *** part/#tomcat xuesheng (~pawelek@cs78175239.pp.htv.fi) |
| 17:52.15 | *** join/#tomcat Arn (6a43be4c@gateway/web/freenode/ip.106.67.190.76) |
| 17:52.34 | Arn | hi |
| 17:52.39 | xnyx | pucko, what is the impact of not unpacking the war file ? |
| 17:53.06 | *** join/#tomcat Gio^ (~VaNNi___@216-240-49-78.mxu.aerioconnect.net) |
| 18:00.00 | whartung | NFS could work, there isn't really a good way to load a war atomically, unless you're willing to restart. |
| 18:00.27 | whartung | if you're willing to restart, then I would just replicate it and not worry about it |
| 18:00.46 | xnyx | how would you replicate it ? |
| 18:00.52 | whartung | rsync |
| 18:00.57 | xnyx | hrmm |
| 18:01.00 | xnyx | yes... |
| 18:01.02 | whartung | rsync to a new directory |
| 18:01.26 | whartung | then rename the old one to app.bak, and the new one to app |
| 18:01.49 | whartung | unless you have just GBs of content, then I'd do a hybrid |
| 18:02.00 | whartung | leaving most of the static huge data alone |
| 18:02.04 | xnyx | I can do that |
| 18:02.15 | whartung | it's nice to have the old copy if something awful goes wrong so you can go back instantly |
| 18:02.15 | xnyx | the war files are 10 and 15 mb |
| 18:02.56 | whartung | yea, that's not "large" |
| 18:03.21 | whartung | 56k modems aren't used a whole lot any more :) |
| 18:03.33 | whartung | my screenshots are that big lol |
| 18:03.40 | xnyx | LOL |
| 18:04.10 | whartung | the thing to do then |
| 18:04.16 | whartung | would be to have a deployment source |
| 18:04.26 | whartung | then have each host PULL from that. |
| 18:04.27 | xnyx | been a while since I rsync'ed anything, I can do a checksum with rsync correct ? |
| 18:04.31 | xnyx | yeah |
| 18:04.37 | whartung | yea, you can do that |
| 18:04.47 | whartung | but I'd just write a script that did the work. |
| 18:05.27 | whartung | because you can do this out of band, right? It doesn't really matter how long this takes (it's not super time sensitive). You want it to be efficient, but if it takes a couple of minutes, no big deal |
| 18:06.09 | whartung | the key is that you need to ensure that your backend works ok when SOME are running the old version and other are running the new version, unless you have a "every things down" maintenance window you can use. |
| 18:06.26 | whartung | and that mostly means being sensitive with the database tables and compatability |
| 18:06.59 | whartung | you also don't want new code referencing new static content that's "not there yet" |
| 18:12.11 | xnyx | I have a 20 minute window at 4am for everything down |
| 18:12.18 | whartung | ok |
| 18:12.27 | whartung | see, you can move all the date before that window |
| 18:12.32 | whartung | use that window to do the "mv" |
| 18:12.35 | xnyx | yeah |
| 18:12.43 | xnyx | Im just debugging my script now |
| 18:12.45 | whartung | fire the sites up, quick consistency/smoke test, |
| 18:12.50 | whartung | if it fails, you can roll back easily. |
| 18:12.52 | xnyx | been so long since I use bash for anything fun :) |
| 18:13.09 | whartung | the hardest part, always the hardest part, is the database |
| 18:13.43 | xnyx | the DB goes offline at 3:55am for about 30 minutes so my window will be from 4am to 4:20 |
| 18:14.13 | xnyx | I run some maintenance plans, and commvault backs up the DB VirtualMachine at that time |
| 18:14.21 | whartung | yea, I only comment on the difficulty of rolling back db changes if something goes wrong. |
| 18:14.28 | xnyx | yeah |
| 18:14.38 | xnyx | understood |
| 18:14.45 | xnyx | I hate "if" |
| 18:14.47 | xnyx | :) |
| 18:14.54 | whartung | 99.99% of the time, it's simply a non-issue |
| 18:15.02 | whartung | for the times it's really a big deal, get a bigger window. |
| 18:15.21 | whartung | "yea, we really need an hour for this otherwise the system may be dead for 3 days." |
| 18:15.58 | whartung | you can work around all this, but you have to do a LOT of architecture work that more most scenarios is simply overkill |
| 18:16.22 | whartung | if you can stand being down a 1/2 hr, you likely can stand being down more than that for extraordinary situations |
| 18:16.30 | xnyx | any thoughts as to how I could automate a "test" ? |
| 18:16.57 | xnyx | yeah, we are a public school division so technicaly we are not a 24x7 shop |
| 18:17.15 | whartung | well, you can have some kind of selenium style smoke test, that runs through the top 10 pieces of functionality. |
| 18:17.27 | whartung | you can do your checksumming trick, make sure everything sums up properly |
| 18:17.28 | xnyx | as much as staff think we are, we are only a best effort after 6pm |
| 18:17.48 | whartung | public school that needs 20 servers?? That seems a lot |
| 18:17.56 | xnyx | 45,000 students |
| 18:18.01 | whartung | (granted, some school districts are huge) |
| 18:18.07 | xnyx | 6000 teaching staff |
| 18:18.08 | whartung | they on them all day? |
| 18:18.11 | xnyx | and this is the report card... |
| 18:18.27 | whartung | anyway |
| 18:18.34 | whartung | the point being |
| 18:18.35 | xnyx | the system is hardly used except for report card season 3 times a year and they are all on |
| 18:18.42 | whartung | yea |
| 18:18.49 | xnyx | so for the rest of the year, 5 VM's |
| 18:18.52 | whartung | heh |
| 18:19.03 | xnyx | in 2 weeks 20+ VM's |
| 18:19.31 | whartung | I would go an automated web test of some kind. log in, get a students grade, change the grade, run a report, on each of the machines, stuff like that. |
| 18:19.45 | whartung | create some fake students and teachers for the test |
| 18:19.49 | whartung | if parctical |
| 18:19.58 | xnyx | yes... I could stick a test page into the war file |
| 18:20.13 | xnyx | good idea... expect a result set if good we are good, if not, back rev |
| 18:20.23 | whartung | deploy all the machines, run the test simultaneously ,should run really fast |
| 18:20.37 | xnyx | yeah... |
| 18:20.39 | xnyx | good idea |
| 18:20.45 | xnyx | good good... like that idea |
| 18:20.46 | whartung | once the machines are up, test should be < 5m |
| 18:21.02 | xnyx | I'll retrieve a version number from the DB |
| 18:21.12 | whartung | do all of your changes 1 month before the big roll out :) |
| 18:21.17 | xnyx | :) |
| 18:21.22 | whartung | so the real test is "all 20 machines up and running" |
| 18:21.27 | xnyx | november 11th is the biggest day |
| 18:21.27 | whartung | vs "is new feature working" |
| 18:38.26 | xnyx | if I just drop a new war file onto where the existing one was, will it unpack (assuming =true) or do I need to delete the unpacked files first ? |
| 18:38.48 | whartung | no, tomcat will delete the old one first |
| 18:39.09 | whartung | it will undeploy the app, delete the old dir, expand the new one, and then deploy the new one |
| 18:39.20 | xnyx | thats pretty cool... |
| 18:39.28 | whartung | yea, it works pretty well |
| 18:39.42 | xnyx | so by me simply dropping the new file in there its gonna take care of everything ? |
| 18:39.50 | whartung | yes |
| 18:39.52 | xnyx | new war file |
| 18:39.53 | xnyx | wow... |
| 18:40.01 | whartung | but you won't have the "old one" there |
| 18:40.02 | xnyx | I never would have thought something could be so cool |
| 18:40.06 | whartung | heh |
| 18:40.07 | xnyx | no, it will be renamed |
| 18:40.14 | whartung | no, it will be deleted :) |
| 18:40.18 | whartung | "automatically" |
| 18:40.27 | xnyx | I was going to mv it to .old |
| 18:40.45 | whartung | that's why it's better to down tomcat, rename the old one, expand the new one and start tomcat. |
| 18:40.47 | whartung | now |
| 18:40.55 | whartung | since your app is only 10-15mb |
| 18:40.56 | xnyx | ok |
| 18:41.07 | whartung | if you just have the old war someplace safe, then it doesn't really matter |
| 18:41.14 | whartung | your deploy is "fast enough" |
| 18:41.19 | xnyx | yeah |
| 18:41.20 | xnyx | k |
| 18:41.59 | whartung | so copy your new war to "/appwars" or whatever, then deploy it on top of itself, and if things go awry, deploy the old back over it |
| 18:44.40 | whartung | you DO have a staging environment, yes? that replicates your deployment in architecture, just not in scale? |
| 18:44.54 | whartung | I assume you're using some kind of load balancer for the 20 instances? |
| 18:46.31 | xnyx | yes |
| 18:46.37 | whartung | k |
| 18:46.37 | xnyx | F5 big-ip |
| 18:46.41 | whartung | yea |
| 18:46.47 | whartung | do you have TWO of those |
| 18:46.48 | whartung | ? |
| 18:46.51 | xnyx | I do |
| 18:46.54 | whartung | ok |
| 18:46.59 | whartung | so you can proof all of this out in the lab |
| 18:47.01 | xnyx | we love HA |
| 18:47.24 | xnyx | I have a test invironment that runs on ESX |
| 18:47.45 | xnyx | DB server, DC, and tomcat servers |
| 18:48.48 | xnyx | pretty cool actaully, its taken me about 5 years (seriosly) to perfect the system, but I can clone my production VM's to a test environment in just a few clicks |
| 18:49.36 | whartung | nice |
| 18:53.34 | *** join/#tomcat internat (~nf@60-241-102-25.static.tpgi.com.au) |
| 20:23.24 | *** join/#tomcat jasonb (d871a88d@gateway/web/freenode/ip.216.113.168.141) |
| 21:12.45 | *** join/#tomcat factor (~factor@75.108.161.36) |
| 22:24.14 | *** join/#tomcat yassine (~yassine@unaffiliated/yassine) |