Re: [Resin-interest] Update on 3.0.27
Thanks for the update. A snapshot to vet the changes would be great. Thanks, Matt Scott Ferguson wrote: > On Oct 24, 2008, at 11:40 AM, Matt Pangaro wrote: > >> Hi, >> I was just wondering if we could get a status update on 3.0.27, since >> there are a number of fixes in it, plus the newly discovered issue >> with >> SSL JNI. > > The plan is to work through the 3.1.x and 3.0.x regressions for next > week and release when they're clean. > > I can put up a new snapshot before that. > > -- Scott ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] 3.2 experience?
+1 On Oct 30, 2008, at 10:36 AM, Jean-Francois Lamy wrote: > I still don't see why old config files stop working. I can still > configure > Log4j using log4j.properties even though there are newer/better > config file > formats. Config files for production sites are tricky, and testing > them is > very painstaking. The pain factor for people that manage many sites > is quite > high. > > Jean-François Lamy > Teximus > C : +1 514 992-2759 > > > -Message d'origine- > De : [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] De la part de Riccardo > Cohen > Envoyé : 30 octobre 2008 05:14 > À : General Discussion for the Resin application server > Objet : Re: [Resin-interest] 3.2 experience? > > I must admit that there are some "non-compatible" changes in the > config, > AND the Api (in particular ejb syntax). > But from my point of view, this comes because Caucho provide tools > really efficients before they are completely defined by the community. > There is good and bad in everything. > > I never found difficult to upgrade, except that it costs... for all > the > changes we have to make, and the time to find the new syntax. > This process have been difficult for me because it was at a time where > the docs were in unstable state. For instance there was a clickable > index of config tags in 3.0 documentation, that disappeared for months > (no more clickable). > > Now it's back, and it seems that the new 3.2 doc is really good. > > > Jose Quinteiro wrote: >> Same here. We're still on 3.0 'cause we haven't found the time to >> port our configs to 3.1. Just got the 3.0 configs to a point where I >> liked 'em, too. >> >> Saludos, >> Jose. >> >> On Oct 29, 2008, at 5:16 PM, Jean-Francois Lamy wrote: >> >>> Same here. I don't quite get why the old style files can't be >>> parsed to >>> whatever newfangled data structure is used by the new version, with >>> whatever >>> defaults best approximate the old behaviour. >>> >>> Jean-François Lamy >>> Teximus >>> >>> -Message d'origine- >>> De : [EMAIL PROTECTED] >>> [mailto:[EMAIL PROTECTED] De la part de Rob >>> Lockstone >>> Envoyé : 29 octobre 2008 19:43 >>> À : General Discussion for the Resin application server >>> Objet : Re: [Resin-interest] 3.2 experience? >>> >>> I'm with you, Leonid! The config file changes from one "major" >>> release >>> to the next has always been a big pain. I know that some are needed >>> from time to time, but this has often been the biggest hurdle in >>> upgrading for us. We're still on 3.0.x because I haven't yet had the >>> time to vet and apply the significant config file changes between >>> 3.0 >>> and 3.1. 3.2? Forget about it! (Not stable enough for us yet >>> anyway.) >>> >>> Rob >>> >>> On Oct 29, 2008, at 10:44, Leonid Geller wrote: >>> In general I like how 3.2 has fewer jars to go around. Hessian is the exception. It would be nice if all of Hessian code was factored out into a separate library in 3.2.x, so we can drop it into other containers, whether they are applications running 3.1.x or perhaps third party apps like tomcat. Also it appears 3.2 is not backward compatible from config stand- point. It is not enough to simply rename .conf to .xml, some configuration elements that used to be optional are required now. This raises the barrier to upgrade from 3.1.x to 3.2.x -Leonid -Original Message- From: [EMAIL PROTECTED] >>> [mailto:[EMAIL PROTECTED] ] On Behalf Of Emil Ong Sent: Wednesday, October 29, 2008 12:36 PM To: General Discussion for the Resin application server Subject: [Resin-interest] 3.2 experience? Resin 3.2.1 is our latest release in the 3.2 branch, which is our development branch. This branch still undergoes our extensive release testing, but has many changes which have not been quite as vetted Resin 3.1 in production use. If you are using 3.2.0 or 3.2.1, what have your experiences been? Are you using it in production? After testing, did you decide to use Resin 3.2. or to stick with Resin 3.1? Why? What did your testing include? What features do you like and what would you like to see? I appreciate any feedback you have to offer as we've gotten a few questions from people interested in using Resin 3.2, but want to hear from other folks who've kicked the tires a bit. Thanks, Emil >>> >>> >>> ___ >>> resin-interest mailing list >>> resin-interest@caucho.com >>> http://maillist.caucho.com/mailman/listinfo/resin-interest >>> >>> >>> >>> ___ >>> resin-interest mailing list >>> resin-interest@caucho.com >>> http://maillist.caucho.com/mailman/listinfo/resin-interest >> >> >> >> ___ >> resin-interest mailing list >> resin-interest@caucho.
Re: [Resin-interest] 3.2 experience?
I still don't see why old config files stop working. I can still configure Log4j using log4j.properties even though there are newer/better config file formats. Config files for production sites are tricky, and testing them is very painstaking. The pain factor for people that manage many sites is quite high. Jean-François Lamy Teximus C : +1 514 992-2759 -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de Riccardo Cohen Envoyé : 30 octobre 2008 05:14 À : General Discussion for the Resin application server Objet : Re: [Resin-interest] 3.2 experience? I must admit that there are some "non-compatible" changes in the config, AND the Api (in particular ejb syntax). But from my point of view, this comes because Caucho provide tools really efficients before they are completely defined by the community. There is good and bad in everything. I never found difficult to upgrade, except that it costs... for all the changes we have to make, and the time to find the new syntax. This process have been difficult for me because it was at a time where the docs were in unstable state. For instance there was a clickable index of config tags in 3.0 documentation, that disappeared for months (no more clickable). Now it's back, and it seems that the new 3.2 doc is really good. Jose Quinteiro wrote: > Same here. We're still on 3.0 'cause we haven't found the time to > port our configs to 3.1. Just got the 3.0 configs to a point where I > liked 'em, too. > > Saludos, > Jose. > > On Oct 29, 2008, at 5:16 PM, Jean-Francois Lamy wrote: > >> Same here. I don't quite get why the old style files can't be >> parsed to >> whatever newfangled data structure is used by the new version, with >> whatever >> defaults best approximate the old behaviour. >> >> Jean-François Lamy >> Teximus >> >> -Message d'origine- >> De : [EMAIL PROTECTED] >> [mailto:[EMAIL PROTECTED] De la part de Rob Lockstone >> Envoyé : 29 octobre 2008 19:43 >> À : General Discussion for the Resin application server >> Objet : Re: [Resin-interest] 3.2 experience? >> >> I'm with you, Leonid! The config file changes from one "major" release >> to the next has always been a big pain. I know that some are needed >> from time to time, but this has often been the biggest hurdle in >> upgrading for us. We're still on 3.0.x because I haven't yet had the >> time to vet and apply the significant config file changes between 3.0 >> and 3.1. 3.2? Forget about it! (Not stable enough for us yet anyway.) >> >> Rob >> >> On Oct 29, 2008, at 10:44, Leonid Geller wrote: >> >>> In general I like how 3.2 has fewer jars to go around. Hessian is >>> the exception. It would be nice if all of Hessian code was factored >>> out into a separate library in 3.2.x, so we can drop it into other >>> containers, whether they are applications running 3.1.x or perhaps >>> third party apps like tomcat. >>> >>> Also it appears 3.2 is not backward compatible from config stand- >>> point. It is not enough to simply rename .conf to .xml, some >>> configuration elements that used to be optional are required now. >>> This raises the barrier to upgrade from 3.1.x to 3.2.x >>> >>> -Leonid >>> >>> >>> -Original Message- >>> From: [EMAIL PROTECTED] >> [mailto:[EMAIL PROTECTED] >>> ] On Behalf Of Emil Ong >>> Sent: Wednesday, October 29, 2008 12:36 PM >>> To: General Discussion for the Resin application server >>> Subject: [Resin-interest] 3.2 experience? >>> >>> Resin 3.2.1 is our latest release in the 3.2 branch, which is our >>> development branch. This branch still undergoes our extensive >>> release >>> testing, but has many changes which have not been quite as vetted >>> Resin >>> 3.1 in production use. >>> >>> If you are using 3.2.0 or 3.2.1, what have your experiences been? >>> Are you using it in production? After testing, did you decide to >>> use Resin 3.2. or to stick with Resin 3.1? Why? What did your >>> testing >>> include? What features do you like and what would you like to see? >>> >>> I appreciate any feedback you have to offer as we've gotten a few >>> questions from people interested in using Resin 3.2, but want to hear >>> from other folks who've kicked the tires a bit. >>> >>> Thanks, >>> Emil >> >> >> ___ >> resin-interest mailing list >> resin-interest@caucho.com >> http://maillist.caucho.com/mailman/listinfo/resin-interest >> >> >> >> ___ >> resin-interest mailing list >> resin-interest@caucho.com >> http://maillist.caucho.com/mailman/listinfo/resin-interest > > > > ___ > resin-interest mailing list > resin-interest@caucho.com > http://maillist.caucho.com/mailman/listinfo/resin-interest > > -- Riccardo Cohen Architecte du Logiciel http://www.architectedulogiciel.fr +33 (0)6.09.83.64.49 ___ resin-interest mailing list resin-
Re: [Resin-interest] Memory leak - in Resin?
On Oct 30, 2008, at 6:39 AM, Mattias Jiderhamn wrote: > Although embarrassed to admit it, we have had long standing problems > with PermGen memory leaks. We have gotten used to restarting the > server > every time we redeploy, to avoid OutOfMemoryError. Since we would like > to make use of - or at least evaluate - some of the new Resin features > like WAR versioning, I thought I’d give fixing this another shot. I've added this as http://bugs.caucho.com/view.php?id=3031 That ThreadLocal needs to be cleared in a finally block when the request completes. I'll need to check on that. -- Scott > > > I have already been through (and fixed a few of) the usual suspects; > JDBC drivers, log factories, ThreadLocals, explicit ClassLoader > references etc. There has also been at least one bug within Resin > causing leaks (bug 951 in Mantis). > > A while back I tried tracking this down using jhat, but since I have > limited experience with this, time did not allow me to get to the > bottom > of it. Today I found some more time, and also a tip on how to use > YourKit to track this down > (http://ampedandwired.com/2008/05/05/finding-permgen-memory-leaks-with-yourkit/ > for those interested). This lead me to something interesting, which I > don’t quite understand. > > If I interpret the YourKit memory snapshot correctly, here is what is > happening (from a Resin 3.1.6 perspective): > > In com.caucho.server.dispatch.ServletInvocation there is a static > ThreadLocal holding references to the current (original) request > (while > dispatching?). This means that as long as the executing (and > dispatching) thread remains in Resins thread pool, but is not used for > another dispatch, a handle to the original > com.caucho.server.http.HttpRequest is held. In the request, there is a > handle to a com.caucho.server.dispatch.Invocation, which in turn has a > handle to - the application classloader! (And there is your PermGen > leak) > > Isn’t the fact that the ThreadLocal is never cleared an obvious memory > leak? Or why haven’t this been fixed even though Scott seems to have > noticed this (see > http://bugs.caucho.com/bug_view_advanced_page.php?bug_id=2883)? > If the leak actually is in Resin, why isn’t anybody else seeing > this??? > Are we doing something unusual? (The only thing I could think of was > ServletRequest implementations inside the application being > dispatched, > however I can't find any such implementations in use) > > /Mattias Jiderhamn > > > ___ > resin-interest mailing list > resin-interest@caucho.com > http://maillist.caucho.com/mailman/listinfo/resin-interest ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Memory leak - in Resin?
We are also on REsin 3.1.6. We restart the server each deploy because of behavior exactly described below. Possibly unrelated but also strange issue we see is abnormally long re-start times, on a 2 server cluster where the process is: kill server 1 deploy war 1 restart server 1... wait long time for it to restart then repeat for server 2 On Thu, Oct 30, 2008 at 8:39 AM, Mattias Jiderhamn < [EMAIL PROTECTED]> wrote: > Although embarrassed to admit it, we have had long standing problems > with PermGen memory leaks. We have gotten used to restarting the server > every time we redeploy, to avoid OutOfMemoryError. Since we would like > to make use of - or at least evaluate - some of the new Resin features > like WAR versioning, I thought I'd give fixing this another shot. > > I have already been through (and fixed a few of) the usual suspects; > JDBC drivers, log factories, ThreadLocals, explicit ClassLoader > references etc. There has also been at least one bug within Resin > causing leaks (bug 951 in Mantis). > > A while back I tried tracking this down using jhat, but since I have > limited experience with this, time did not allow me to get to the bottom > of it. Today I found some more time, and also a tip on how to use > YourKit to track this down > ( > http://ampedandwired.com/2008/05/05/finding-permgen-memory-leaks-with-yourkit/ > for those interested). This lead me to something interesting, which I > don't quite understand. > > If I interpret the YourKit memory snapshot correctly, here is what is > happening (from a Resin 3.1.6 perspective): > > In com.caucho.server.dispatch.ServletInvocation there is a static > ThreadLocal holding references to the current (original) request (while > dispatching?). This means that as long as the executing (and > dispatching) thread remains in Resins thread pool, but is not used for > another dispatch, a handle to the original > com.caucho.server.http.HttpRequest is held. In the request, there is a > handle to a com.caucho.server.dispatch.Invocation, which in turn has a > handle to - the application classloader! (And there is your PermGen leak) > > Isn't the fact that the ThreadLocal is never cleared an obvious memory > leak? Or why haven't this been fixed even though Scott seems to have > noticed this (see > http://bugs.caucho.com/bug_view_advanced_page.php?bug_id=2883)? > If the leak actually is in Resin, why isn't anybody else seeing this??? > Are we doing something unusual? (The only thing I could think of was > ServletRequest implementations inside the application being dispatched, > however I can't find any such implementations in use) > > /Mattias Jiderhamn > > > ___ > resin-interest mailing list > resin-interest@caucho.com > http://maillist.caucho.com/mailman/listinfo/resin-interest > ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Memory leak - in Resin?
Do you have a lot of jsp's? We don't deploy war files, but I do notice that when we have any old jsp's laying around that have errors in them, resin attempts to recompile them every time it starts, and this slows down the start time considerably. So, if you have jsp's in your war, you might want to consider compiling them before you create your war file. Not sure if that's even possible, but I bet it would reduce your start times considerably, at the expense of increasing the size of your war file, of course. Rob On Oct 30, 2008, at 07:37, Sandeep Ghael wrote: We are also on REsin 3.1.6. We restart the server each deploy because of behavior exactly described below. Possibly unrelated but also strange issue we see is abnormally long re-start times, on a 2 server cluster where the process is: kill server 1 deploy war 1 restart server 1... wait long time for it to restart then repeat for server 2 ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] Memory leak - in Resin?
I've got a similar experience, but not enough evidence to name a root cause. ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] Memory leak - in Resin?
Although embarrassed to admit it, we have had long standing problems with PermGen memory leaks. We have gotten used to restarting the server every time we redeploy, to avoid OutOfMemoryError. Since we would like to make use of - or at least evaluate - some of the new Resin features like WAR versioning, I thought I’d give fixing this another shot. I have already been through (and fixed a few of) the usual suspects; JDBC drivers, log factories, ThreadLocals, explicit ClassLoader references etc. There has also been at least one bug within Resin causing leaks (bug 951 in Mantis). A while back I tried tracking this down using jhat, but since I have limited experience with this, time did not allow me to get to the bottom of it. Today I found some more time, and also a tip on how to use YourKit to track this down (http://ampedandwired.com/2008/05/05/finding-permgen-memory-leaks-with-yourkit/ for those interested). This lead me to something interesting, which I don’t quite understand. If I interpret the YourKit memory snapshot correctly, here is what is happening (from a Resin 3.1.6 perspective): In com.caucho.server.dispatch.ServletInvocation there is a static ThreadLocal holding references to the current (original) request (while dispatching?). This means that as long as the executing (and dispatching) thread remains in Resins thread pool, but is not used for another dispatch, a handle to the original com.caucho.server.http.HttpRequest is held. In the request, there is a handle to a com.caucho.server.dispatch.Invocation, which in turn has a handle to - the application classloader! (And there is your PermGen leak) Isn’t the fact that the ThreadLocal is never cleared an obvious memory leak? Or why haven’t this been fixed even though Scott seems to have noticed this (see http://bugs.caucho.com/bug_view_advanced_page.php?bug_id=2883)? If the leak actually is in Resin, why isn’t anybody else seeing this??? Are we doing something unusual? (The only thing I could think of was ServletRequest implementations inside the application being dispatched, however I can't find any such implementations in use) /Mattias Jiderhamn ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Quercus + Web Services / Zend
Hello Daniel, I had success running my project that uses ZF 1.5.2 on top of Quercus, as it is using PDO, and the Quercus support at that time (dunno know, I'm not watching its progress) didn't implement some necessary things, I did implement and so it worked fine. Which version of ZF were you using? Share your basic test too, so we can try to figure out what is happening. Regards, -Adriano On Thu, Oct 30, 2008 at 11:01 AM, Daniel López <[EMAIL PROTECTED]> wrote: > Hi, > > I'm doing some experiments with Quercus and one of the things I wanted > to do is accessing an already existing web service written in Java. I > also tried implementing the experiments using Zend Framework, even > though that failed, first with a problem I solved by upgrading to 3.1.7 > and then with more problems I found no information about. I then tried > to go back to the basics and use NuSoap and all I get when I use it is > "server failed to send headers" and from the error trace, it seems it > never reads any answer from the server ( I tried with public servers > with WSDLs that work ) but I still have to verify if it is a problem > with Quercus or my setup. As all I could find is that the simple 3 lines > I wrote "should work" and they are quite basic... well, I'll check this > weekend :). > > In any case, what's the status of Quercus regarding those subjects? Was > anybody able to run the Zend framework under Quercus? Or develop some > kind of Web Service client? The information is quite scarce and the > documentation is not too thorough, specially the list of applications > supported as the link simply goes to the documentation page ;). > > The forums (http://forum.caucho.com/) are kind of weird... how can one > see the replies to the topics? Do I have to be registered for that? > > As a "newbie" in this topic, I have to say the information about the > subject is spread and difficult to follow. There are different web sites > with different styles, the wiki, the mailing lists, the forums... > > S! > D. > --- > Daniel Lopez Janariz ([EMAIL PROTECTED]) > Web Services > Centre for Information and Technology > Balearic Islands University > (SPAIN) > --- > > > ___ > resin-interest mailing list > resin-interest@caucho.com > http://maillist.caucho.com/mailman/listinfo/resin-interest > ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] Quercus + Web Services / Zend
Hi, I'm doing some experiments with Quercus and one of the things I wanted to do is accessing an already existing web service written in Java. I also tried implementing the experiments using Zend Framework, even though that failed, first with a problem I solved by upgrading to 3.1.7 and then with more problems I found no information about. I then tried to go back to the basics and use NuSoap and all I get when I use it is "server failed to send headers" and from the error trace, it seems it never reads any answer from the server ( I tried with public servers with WSDLs that work ) but I still have to verify if it is a problem with Quercus or my setup. As all I could find is that the simple 3 lines I wrote "should work" and they are quite basic... well, I'll check this weekend :). In any case, what's the status of Quercus regarding those subjects? Was anybody able to run the Zend framework under Quercus? Or develop some kind of Web Service client? The information is quite scarce and the documentation is not too thorough, specially the list of applications supported as the link simply goes to the documentation page ;). The forums (http://forum.caucho.com/) are kind of weird... how can one see the replies to the topics? Do I have to be registered for that? As a "newbie" in this topic, I have to say the information about the subject is spread and difficult to follow. There are different web sites with different styles, the wiki, the mailing lists, the forums... S! D. --- Daniel Lopez Janariz ([EMAIL PROTECTED]) Web Services Centre for Information and Technology Balearic Islands University (SPAIN) --- ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Logs not rotating correctly
I think it could be related to http://bugs.caucho.com/view.php?id=2941 as I see this error in the logs: [2008-10-30 09:35:39.569] java.lang.UnsatisfiedLinkError: com.caucho.vfs.JniFilePathImpl.nativeTruncate([BI)I [2008-10-30 09:35:39.569] at com.caucho.vfs.JniFilePathImpl.nativeTruncate(Native Method) [2008-10-30 09:35:39.569] at com.caucho.vfs.JniFilePathImpl.truncate(JniFilePathImpl.java:363) [2008-10-30 09:35:39.569] at com.caucho.vfs.Path.truncate(Path.java:940) [2008-10-30 09:35:39.569] at com.caucho.log.AbstractRolloverLog.movePathToArchive(AbstractRolloverLog java:584) [2008-10-30 09:35:39.569] at com.caucho.log.AbstractRolloverLog.access$100(AbstractRolloverLog.java:5 9) [2008-10-30 09:35:39.569] at com.caucho.log.AbstractRolloverLog$ArchiveTask.run(AbstractRolloverLog.j ava:827) [2008-10-30 09:35:39.569] at com.caucho.util.ThreadPool$Item.runTasks(ThreadPool.java:721) [2008-10-30 09:35:39.569] at com.caucho.util.ThreadPool$Item.run(ThreadPool.java:643) [2008-10-30 09:35:39.569] at java.lang.Thread.run(Thread.java:619) This is meant to have been fixed in 3.1.7a but that's what I'm running and I still see it. Richard Grantham Development --- [EMAIL PROTECTED] Limehouse Software Ltd DDI: (020) 7566 3336 Main: (020) 7566 3320 Fax: (020) 7566 3321 Limehouse Software Ltd Bridewell Gate 9 Bridewell Place London EC4V 6AW Manchester Office: 3rd Floor, The Triangle, Exchange Square, Manchester M4 3TR Tel: (0161) 240 2440, Fax: (0161) 240 2441, ISDN: 08700 119 400 Check out Limehouse Software's innovative solutions www.limehousesoftware.co.uk - Transforming the way you publish and consult on information The information contained in this e-mail or in any attachments is confidential and is intended solely for the named addressee only. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Limehouse Software Ltd immediately by returning this e-mail to sender or calling 020 7566 3320 and do not read, use or disseminate the information. Opinions expressed in this e-mail are those of the sender and not necessarily the company. Although an active anti-virus policy is operated, the company accepts no liability for any damage caused by any virus transmitted by this e-mail, including any attachments.-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rob Lockstone Sent: 23 October 2008 05:05 To: General Discussion for the Resin application server Subject: Re: [Resin-interest] Logs not rotating correctly I don't have a definitive answer for you. We're not currently running 3.1.x, so I don't have any direct experience with it. Have you tried using rollover-size instead of rollover-period? Just to see if it makes any difference. With 3.0.x standalone (on Windows), rollover- size works fine. If you can't get it working, I'd recommend filing a bug at http://bugs.caucho.com/ Rob On Oct 21, 2008, at 08:10, Richard Grantham wrote: > Sorry, you're right. All that is missing. > > I'm running Resin 3.1.7a. My log configuration is as follows: > rollover-period="1D" /> timestamp="[%Y-%m-%d %H:%M:%S.%s] " rollover-period="1D" /> > rollover-period="1D" /> rollover-period="1D" /> > > We don't run Resin with Apache as we use a hardware load balancer. > > What I see happening is the log being rotated but a file handle is > maintained on access.log (it's all the logs mentioned above this is > happening with, not just access.log) and not recycled after the log is > rotated. The result is that the log is copied to another file but then > not cleared. It continues to be written to. Hope that makes sense. > > rgds, > > Richard > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Rob Lockstone > Sent: 15 October 2008 15:52 > To: General Discussion for the Resin application server > Subject: Re: [Resin-interest] Logs not rotating correctly > > My first question would be why would you want to maintain (on an > ongoing > basis) access logs for what appears to be a pretty busy server? > > An important piece of information that's missing is the version of > resin that you're running. I know from personal experience that older > versions, in the 2.x world, did not properly rotate log files. > > Also, what settings for the logs do you have configured in your resin > configuration? If you're running resin with apache, then (usually) > apache is in control of the access logs, not resin. It's hard to tell > from what you've said how you have resin configured, standalone or > with apache. > > Rob > > On Oct 15, 2008, at 04:33, Richard Grantham wrote: > > > Hi list, > > I've got a major issue with our live servers. The logs don't appear > to > be rotating correctly. This is filling the disk and causing > performance > issues. > > Resin is running as the
Re: [Resin-interest] 3.2 experience?
I must admit that there are some "non-compatible" changes in the config, AND the Api (in particular ejb syntax). But from my point of view, this comes because Caucho provide tools really efficients before they are completely defined by the community. There is good and bad in everything. I never found difficult to upgrade, except that it costs... for all the changes we have to make, and the time to find the new syntax. This process have been difficult for me because it was at a time where the docs were in unstable state. For instance there was a clickable index of config tags in 3.0 documentation, that disappeared for months (no more clickable). Now it's back, and it seems that the new 3.2 doc is really good. Jose Quinteiro wrote: > Same here. We're still on 3.0 'cause we haven't found the time to > port our configs to 3.1. Just got the 3.0 configs to a point where I > liked 'em, too. > > Saludos, > Jose. > > On Oct 29, 2008, at 5:16 PM, Jean-Francois Lamy wrote: > >> Same here. I don't quite get why the old style files can't be >> parsed to >> whatever newfangled data structure is used by the new version, with >> whatever >> defaults best approximate the old behaviour. >> >> Jean-François Lamy >> Teximus >> >> -Message d'origine- >> De : [EMAIL PROTECTED] >> [mailto:[EMAIL PROTECTED] De la part de Rob Lockstone >> Envoyé : 29 octobre 2008 19:43 >> À : General Discussion for the Resin application server >> Objet : Re: [Resin-interest] 3.2 experience? >> >> I'm with you, Leonid! The config file changes from one "major" release >> to the next has always been a big pain. I know that some are needed >> from time to time, but this has often been the biggest hurdle in >> upgrading for us. We're still on 3.0.x because I haven't yet had the >> time to vet and apply the significant config file changes between 3.0 >> and 3.1. 3.2? Forget about it! (Not stable enough for us yet anyway.) >> >> Rob >> >> On Oct 29, 2008, at 10:44, Leonid Geller wrote: >> >>> In general I like how 3.2 has fewer jars to go around. Hessian is >>> the exception. It would be nice if all of Hessian code was factored >>> out into a separate library in 3.2.x, so we can drop it into other >>> containers, whether they are applications running 3.1.x or perhaps >>> third party apps like tomcat. >>> >>> Also it appears 3.2 is not backward compatible from config stand- >>> point. It is not enough to simply rename .conf to .xml, some >>> configuration elements that used to be optional are required now. >>> This raises the barrier to upgrade from 3.1.x to 3.2.x >>> >>> -Leonid >>> >>> >>> -Original Message- >>> From: [EMAIL PROTECTED] >> [mailto:[EMAIL PROTECTED] >>> ] On Behalf Of Emil Ong >>> Sent: Wednesday, October 29, 2008 12:36 PM >>> To: General Discussion for the Resin application server >>> Subject: [Resin-interest] 3.2 experience? >>> >>> Resin 3.2.1 is our latest release in the 3.2 branch, which is our >>> development branch. This branch still undergoes our extensive >>> release >>> testing, but has many changes which have not been quite as vetted >>> Resin >>> 3.1 in production use. >>> >>> If you are using 3.2.0 or 3.2.1, what have your experiences been? >>> Are you using it in production? After testing, did you decide to >>> use Resin 3.2. or to stick with Resin 3.1? Why? What did your >>> testing >>> include? What features do you like and what would you like to see? >>> >>> I appreciate any feedback you have to offer as we've gotten a few >>> questions from people interested in using Resin 3.2, but want to hear >>> from other folks who've kicked the tires a bit. >>> >>> Thanks, >>> Emil >> >> >> ___ >> resin-interest mailing list >> resin-interest@caucho.com >> http://maillist.caucho.com/mailman/listinfo/resin-interest >> >> >> >> ___ >> resin-interest mailing list >> resin-interest@caucho.com >> http://maillist.caucho.com/mailman/listinfo/resin-interest > > > > ___ > resin-interest mailing list > resin-interest@caucho.com > http://maillist.caucho.com/mailman/listinfo/resin-interest > > -- Riccardo Cohen Architecte du Logiciel http://www.architectedulogiciel.fr +33 (0)6.09.83.64.49 ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
