Re: [Resin-interest] resin maven plugin like jetty
Tony Field wrote: > Does anyone know of a resin maven plugin that works similar to the > way the jetty plugin works? There is something called Cargo (cargo.codehaus.org). I don't know enough about the Jetty plugin to tell if it is what you're looking for though. > If one doesn't exist, is anyone interested in working on one with me? > I'm sure there will be some interest as soon as people see a proof of concept. -Knut ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Application Memory Profiling
On Jun 11, 2007, at 10:11 AM, Gary Zhu wrote:
> It could be as simple as your ThreadLocal, in addition to that,
> this could also be caused by others.
True, but in this case, Daniel has noticed the extra ThreadLocal as
the object holding the link in the profile, so it's a good place to
start looking.
>private static final Level CUSTOMLEVEL = new Level("test", 555) {};
>
> Logger.getLogger("test").log("CUSTOMLEVEL, "something");
>
> };
>
> Since CUSTOMLEVEL contains java.util.logging.Level.INFO (SEVERE,
> etc), and they are 'reachable' from other part of JVM, so
> your_class is not garbage collected.
By the way, this is a bug in java.util.logging.Level. The
application code would be fine if it wasn't for the JDK bug.
The general rule is: never store an object from a child classloader
context in a parent classloader context unless you use WeakReferences.
It's the main reason why Singletons are dangerous.
ThreadLocal is an instance of this problem, because it's essentially
storing the object in the root classloader context.
-- Scott
>
> On that FOB session, Edward used JHat to trace PermGen leaks, and
> found 5-6 violations in that application server and a couple of
> places in the user application. A note to Caucho engineers: that
> case study was not based on Resin.
>
> You can find these discussions from the blogs of two Sun engineers
> who presented this FOB:
>
> http://blogs.sun.com/fkieviet
> http://blogs.sun.com/edwardchou
>
> one of the good articles is on Frank's blog:
> http://blogs.sun.com/fkieviet/entry/classloader_leaks_the_dreaded_java
>
>
>
>> -Original Message-
>> From: [EMAIL PROTECTED]
>> [mailto:[EMAIL PROTECTED] Behalf Of Scott Ferguson
>> Sent: Monday, June 11, 2007 9:12 AM
>> To: General Discussion for the Resin application server
>> Subject: Re: [Resin-interest] Application Memory Profiling
>>
>>
>>
>> On Jun 11, 2007, at 3:00 AM, Daniel López wrote:
>>
>>>
>>> Something similar happens with com.caucho.xml.Xml: I start with 2
>>> instances, one referenced from a class of mine and another from
>>> java.lang.ThreadLocal. After a restart I get 2 instances referenced
>>> from
>>> java.lang.ThreadLocal. Another restart and I have 3 referenced from
>>> java.lang.ThreadLocal... In this case, the problem seems to be a
>>> growing
>>> number of instances from
>> org.apache.xml.utils.XMLReaderManager... that
>>> are themselves related to the aforementioned
>>> com.caucho.loader.EnvironmentClassLoader.
>>
>> Do you know what is holding the ThreadLocal references?
>>
>> This definitely looks like a threading/ThreadLocal issue. There have
>> been libraries which have neglected to clear the ThreadLocals
>> properly, which will cause major problems with garbage collection and
>> classloading. That would be the first thing to look at.
>>
>> ThreadLocal needs to be used with the following pattern:
>>
>>ThreadLocal _local = new ThreadLocal();
>>
>>...
>>
>>Object oldValue = _local.get();
>>try {
>> _local.set(newValue);
>>
>> ...
>>} finally {
>> _local.set(oldValue);
>>}
>>
>> If the application forgets the second set, then the oldValue will not
>> be garbage collected.
>>
>>>
>>> So my question would be if anybody has run into similar
>> issues or has
>>> any idea what could be causing the proliferation of
>>> com.caucho.loader.EnvironmentClassLoader instances. I
>> suspect it might
>>> be that some library is keeping a reference to the
>> classloader through
>>> some daemon thread that is not being properly initialised when the
>>> context is restarted.
>>>
>>> Any hints on how to further debug this issue? Any similar
>> experience?
>>
>> Look for the ThreadLocal reference. Also, double check that there
>> isn't a daemon thread that isn't properly closed on restart.
>>
>> -- Scott
>>
>>> Thanks,
>>> D.
>>>
>>>
>>>
>>>
>>>
>>> ___
>>> 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
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Application Memory Profiling
It could be as simple as your ThreadLocal, in addition to that, this could also
be caused by others.
The class-loader problem has bugged many people. JavaOne07 had this late
evening FOB session on the topic, and a lot of people showed up, looking for
answer.
In short, 'An object can only be garbage collected if the object is
unreachable'.
A sample code:
import java.util.logging.*;
public class your_class {
private static final Level CUSTOMLEVEL = new Level("test", 555) {};
Logger.getLogger("test").log("CUSTOMLEVEL, "something");
};
Since CUSTOMLEVEL contains java.util.logging.Level.INFO (SEVERE, etc), and they
are 'reachable' from other part of JVM, so your_class is not garbage collected.
On that FOB session, Edward used JHat to trace PermGen leaks, and found 5-6
violations in that application server and a couple of places in the user
application. A note to Caucho engineers: that case study was not based on Resin.
You can find these discussions from the blogs of two Sun engineers who
presented this FOB:
http://blogs.sun.com/fkieviet
http://blogs.sun.com/edwardchou
one of the good articles is on Frank's blog:
http://blogs.sun.com/fkieviet/entry/classloader_leaks_the_dreaded_java
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Scott Ferguson
> Sent: Monday, June 11, 2007 9:12 AM
> To: General Discussion for the Resin application server
> Subject: Re: [Resin-interest] Application Memory Profiling
>
>
>
> On Jun 11, 2007, at 3:00 AM, Daniel López wrote:
>
> >
> > Something similar happens with com.caucho.xml.Xml: I start with 2
> > instances, one referenced from a class of mine and another from
> > java.lang.ThreadLocal. After a restart I get 2 instances referenced
> > from
> > java.lang.ThreadLocal. Another restart and I have 3 referenced from
> > java.lang.ThreadLocal... In this case, the problem seems to be a
> > growing
> > number of instances from
> org.apache.xml.utils.XMLReaderManager... that
> > are themselves related to the aforementioned
> > com.caucho.loader.EnvironmentClassLoader.
>
> Do you know what is holding the ThreadLocal references?
>
> This definitely looks like a threading/ThreadLocal issue. There have
> been libraries which have neglected to clear the ThreadLocals
> properly, which will cause major problems with garbage collection and
> classloading. That would be the first thing to look at.
>
> ThreadLocal needs to be used with the following pattern:
>
>ThreadLocal _local = new ThreadLocal();
>
>...
>
>Object oldValue = _local.get();
>try {
> _local.set(newValue);
>
> ...
>} finally {
> _local.set(oldValue);
>}
>
> If the application forgets the second set, then the oldValue will not
> be garbage collected.
>
> >
> > So my question would be if anybody has run into similar
> issues or has
> > any idea what could be causing the proliferation of
> > com.caucho.loader.EnvironmentClassLoader instances. I
> suspect it might
> > be that some library is keeping a reference to the
> classloader through
> > some daemon thread that is not being properly initialised when the
> > context is restarted.
> >
> > Any hints on how to further debug this issue? Any similar
> experience?
>
> Look for the ThreadLocal reference. Also, double check that there
> isn't a daemon thread that isn't properly closed on restart.
>
> -- Scott
>
> > Thanks,
> > D.
> >
> >
> >
> >
> >
> > ___
> > 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
Re: [Resin-interest] Application Memory Profiling
On Jun 11, 2007, at 3:00 AM, Daniel López wrote:
>
> Something similar happens with com.caucho.xml.Xml: I start with 2
> instances, one referenced from a class of mine and another from
> java.lang.ThreadLocal. After a restart I get 2 instances referenced
> from
> java.lang.ThreadLocal. Another restart and I have 3 referenced from
> java.lang.ThreadLocal... In this case, the problem seems to be a
> growing
> number of instances from org.apache.xml.utils.XMLReaderManager... that
> are themselves related to the aforementioned
> com.caucho.loader.EnvironmentClassLoader.
Do you know what is holding the ThreadLocal references?
This definitely looks like a threading/ThreadLocal issue. There have
been libraries which have neglected to clear the ThreadLocals
properly, which will cause major problems with garbage collection and
classloading. That would be the first thing to look at.
ThreadLocal needs to be used with the following pattern:
ThreadLocal _local = new ThreadLocal();
...
Object oldValue = _local.get();
try {
_local.set(newValue);
...
} finally {
_local.set(oldValue);
}
If the application forgets the second set, then the oldValue will not
be garbage collected.
>
> So my question would be if anybody has run into similar issues or has
> any idea what could be causing the proliferation of
> com.caucho.loader.EnvironmentClassLoader instances. I suspect it might
> be that some library is keeping a reference to the classloader through
> some daemon thread that is not being properly initialised when the
> context is restarted.
>
> Any hints on how to further debug this issue? Any similar experience?
Look for the ThreadLocal reference. Also, double check that there
isn't a daemon thread that isn't properly closed on restart.
-- Scott
> Thanks,
> D.
>
>
>
>
>
> ___
> 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] quercus questions
I love caucho products and all the work Scott has done (he's the fing man) but if it were me, I wouldn't use Quercus in production unless I was 100% sure my application ran 100% correctly on it. That said, most php applications will run *great*, especially if you hand built them. When you introduce a framework, you now must check to be sure that framework runs correctly as well. In getting familiar with webapps 'the java way' realize that as of today there is of course more than one way. But start with the fundamentals: - understand jsp and servlets -- plenty of material online (google: core servlets), but I recommend the Head First book -- read Sun's servlet spec - understand MVC aka 'model 2 mvc' - understand struts 1 -- see the online book 'struts survival guide' - experiment w/ Resin to learn about db connection pooling and other cool features In other words, learn to build a standard Java webapp. Then learn how to use Quercus. Many in the java camp would cringe at the notion of using php for anything other than the view. In addition, the Java community has gone waaay past manual database interactions like the usual php mysql and pdo functions. So you will at some point want to look at ORM layers like Hibernate et al, unless you really love sql and string concatenation. As for c and fun, I still have my hair and I like to keep it that way, but you might be a far better programmer than me. Viel gluck, yong On Jun 11, 2007, at 8:54 AM, Nathan Nobbe wrote: Yong, bleeding edge is cool w/ me as im a gentoo user; the only thing i worry about going w/ quercus really, is having a product that may be difficult to support. my opinion of the php community is that good developers, in particular those w/ oo skillsets are difficult, if not almost impossible to come by, so quercus could add yet another layer of complexity and make it almost really impossible; i dont know though, just speculation. as i mentioned im working w/ sqlite3 atm via pdo, but i intend to port the same db abstraction to the other pdo drivers like i said. i am comfortable using quercus in an enterprise environment for my large traffic sites, and sticking w/ mod-php for my embedded products, but another thing i worry about is going under the hood. one of the reasons quercus is attractive to me is that im much more proficient in java than c. although i can write in both i do struggle a bit w/ c. so anyway if i do write some extensions to the php language itself, i would much prefer to do it on the quercus platform, but if the code for my embedded products is to stay similar to that of the enterprise products i will certainly have to write similar stuff in c anyway, should be fun i guess, right? at my last job we had some hard-core java guys come in and i learned a lot; we were using tomcat, which i understand may not be the greatest app server, but anyway code was being deployed as war files so i have just a very crude familiarity w/ web apps, 'the java way'. im reading tons of material atm, but i am interested in getting started in quercus. if it isnt too much trouble, is there a primer on web apps the java way online that you feel is worth mention to a beginner like me? thanks for your reply. -nathan On 6/11/07, Yong Bakos <[EMAIL PROTECTED]> wrote: Hi Nathan, some information is here: http://quercus.caucho.com/quercus-3.1/doc/quercus-module-status.xtp Some info about PDO here http://caucho.com/resin-3.1/doc/quercus-overview.xtp#databases but understand that Quercus is bleeding edge stuff, and the best thing to do is experiment. You will also want to educate yourself on Web applications done 'the java way,' and how Resin, and servlet containers in general, work. yong On Jun 10, 2007, at 12:46 PM, Nathan Nobbe wrote: oh, right, i just remembered another critical thing; the SPL. -nathan On 6/10/07, Nathan Nobbe <[EMAIL PROTECTED]> wrote: hello all, i am interested in quercus and intend to begin experimenting with it. just getting started, im curious if there is a list of extensions that are known to be supported at this time. all the extensions are listed in the php online manual, so i wonder if theres a document that just lists all of them and the support status under quercus. also, i am very curious about pdo and xsl / xml. pdo was introduced in php5, and there are separate drivers for each database; currently i work with sqlite3 ( corresponding pdo driver api), and in the future will be running mysql and possibly oracle as well. also, php5 unveiled a new xml infrastructure built on libxml2. it seems obvious that quercus is going to implement xml support through some java libs, instead, but i wonder about the simplexml and dom extensions; these are built into php5 using the new libxml2 framework; so are these extensions available in quercus via an identical interface? there are also a number of xsl and xslt functions. all of these things are
Re: [Resin-interest] Session timeout configuration ignored...
Hi Mark, does the session timeout work for you with lower values, like 30 (minutes)? I can't really image why you want a timout of 20 days, but maybe you want to try regular cookies instead of session cookies. Regards, markus Mark Derricutt wrote: > Hi all, > > I've been trying to suss out a problem we're sessing with our idle > sessions timing out after 1-2 minutes of being idle regardless of any > settings being defined. > > I'm seeing this under 3.0.14, 3.0.23 and 3.1.1. > > The web app's web.xml (expanded war) has: > > > 28800 > > > inside the element but sessions don't seem to last anywhere > near 28800 minutes. > > I've seen lots of posts in the archives regarding session timeouts and > after increasing the logging in my resin I see the following: > > [14:39:46.308] create session abc2pDXqqc4Rqe6z6mjmr > [14:39:46.308] create session abc2pDXqqc4Rqe6z6mjmr > 14:39:46,309 INFO [SessionListener] New Session created on Fri Jun 08 > 14:39:46 NZST 2007 with id: abc2pDXqqc4Rqe6z6mjmr from uri > /bw/index.htm for null > 14:39:46,309 INFO [SessionListener] There are now 1 live sessions in > the application. > [14:41:28.653] invalidate session abc2pDXqqc4Rqe6z6mjmr > [14:41:28.653] java.lang.Exception > [14:41:28.653] at > com.caucho.server.session.SessionImpl.invalidate(SessionImpl.java:539) > [14:41:28.653] at > com.caucho.server.session.SessionManager.handleAlarm > (SessionManager.java:1581) > [14:41:28.653] at com.caucho.util.Alarm.handleAlarm(Alarm.java:351) > [14:41:28.653] at com.caucho.util.Alarm.run(Alarm.java:321) > [14:41:28.653] at com.caucho.util.ThreadPool$Item.runTasks > (ThreadPool.java:600) > [14:41:28.653] at > com.caucho.util.ThreadPool$Item.run(ThreadPool.java:522) > [14:41:28.653] at java.lang.Thread.run(Thread.java:619) > [14:41:28.657] remove session abc2pDXqqc4Rqe6z6mjmr > 14:41:28,657 INFO [SessionListener] Session destroyed - id > abc2pDXqqc4Rqe6z6mjmr. There are now 0 live sessions in the application. > > This shows resin creating the session (logging twice for some reason), > then my session listener logging the creation, followed by 2 minutes > then an exception during session invalidation. > > Theres nothing in my resin.conf overriding the > value, I ever went to the paranoid level of removing anything > mentioning timeout (keepalives etc.). > > Does anyone have any suggestions on what I could look at? > > Cheers, > Mark > > > > > ___ > resin-interest mailing list > resin-interest@caucho.com > http://maillist.caucho.com/mailman/listinfo/resin-interest > -- -- Dipl.-Ing. Markus Ken Baron-Moriyama <[EMAIL PROTECTED]> Director Global IT Relations and Research Co-Founder Wazap AG Karl-Liebknecht-Str. 5 10178 Berlin Germany Tel: +49 30 278744 2241 Fax: +49 30 278744 29 URL: http://wazap.com/ Winner of the prestigious 2007 Red Herring Europe 100 award Wazap Aktiengesellschaft HRB 103534 B Sitz der Gesellschaft: Berlin Amtsgericht:Berlin-Charlottenburg Vorstand: Andreas Ruehrig (Vors.), Timo Meyer, Alexander Piutti, Philip Gienandt Aufsichtsrat: Martin Sinner (Vors.), Frank Boehnke, Florian Seubert ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] quercus questions
Yong, bleeding edge is cool w/ me as im a gentoo user; the only thing i worry about going w/ quercus really, is having a product that may be difficult to support. my opinion of the php community is that good developers, in particular those w/ oo skillsets are difficult, if not almost impossible to come by, so quercus could add yet another layer of complexity and make it almost really impossible; i dont know though, just speculation. as i mentioned im working w/ sqlite3 atm via pdo, but i intend to port the same db abstraction to the other pdo drivers like i said. i am comfortable using quercus in an enterprise environment for my large traffic sites, and sticking w/ mod-php for my embedded products, but another thing i worry about is going under the hood. one of the reasons quercus is attractive to me is that im much more proficient in java than c. although i can write in both i do struggle a bit w/ c. so anyway if i do write some extensions to the php language itself, i would much prefer to do it on the quercus platform, but if the code for my embedded products is to stay similar to that of the enterprise products i will certainly have to write similar stuff in c anyway, should be fun i guess, right? at my last job we had some hard-core java guys come in and i learned a lot; we were using tomcat, which i understand may not be the greatest app server, but anyway code was being deployed as war files so i have just a very crude familiarity w/ web apps, 'the java way'. im reading tons of material atm, but i am interested in getting started in quercus. if it isnt too much trouble, is there a primer on web apps the java way online that you feel is worth mention to a beginner like me? thanks for your reply. -nathan On 6/11/07, Yong Bakos <[EMAIL PROTECTED]> wrote: Hi Nathan, some information is here: http://quercus.caucho.com/quercus-3.1/doc/quercus-module-status.xtp Some info about PDO here http://caucho.com/resin-3.1/doc/quercus-overview.xtp#databases but understand that Quercus is bleeding edge stuff, and the best thing to do is experiment. You will also want to educate yourself on Web applications done 'the java way,' and how Resin, and servlet containers in general, work. yong On Jun 10, 2007, at 12:46 PM, Nathan Nobbe wrote: oh, right, i just remembered another critical thing; the SPL. -nathan On 6/10/07, Nathan Nobbe <[EMAIL PROTECTED]> wrote: hello all, i am interested in quercus and intend to begin experimenting with it. just getting started, im curious if there is a list of extensions that are known to be supported at this time. all the extensions are listed in the php online manual, so i wonder if theres a document that just lists all of them and the support status under quercus. also, i am very curious about pdo and xsl / xml. pdo was introduced in php5, and there are separate drivers for each database; currently i work with sqlite3 ( corresponding pdo driver api), and in the future will be running mysql and possibly oracle as well. also, php5 unveiled a new xml infrastructure built on libxml2. it seems obvious that quercus is going to implement xml support through some java libs, instead, but i wonder about the simplexml and dom extensions; these are built into php5 using the new libxml2 framework; so are these extensions available in quercus via an identical interface? there are also a number of xsl and xslt functions. all of these things are critical to my current system architecture and for a viable transition to quercus all of them would need to be available. a reference doc would be a great starting point for me, if its out there.. thanks, -nathan ___ 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
[Resin-interest] Application Memory Profiling
Hi there, I was checking one of my web applications to see if I there was anything wrong with the framework we use, as I had fixed a small issue that could help with memory usage and I have found out some "symptoms" that I think might be related to Resin and/or the libraries, so I wanted to check with you guys if know what could be the issue here. I'm using Resin 3.1.1 under Java 6 and the profiler is YourKit Java Profiler 6.0.15. .- I start the application, access one page to verify it is fully loaded and then take a snapshot. .- I modify web.xml so the context is restarted, access the same page again, try to force garbage collection and wait until memory usage is stable, then take a second snapshot. .- Repeat the same step. After that, comparing the snapshots and looking at the new objects created, I get that each time the context is restarted, the new object that "consumes" more memory is com.caucho.loader.EnvironmentClassLoader. In fact, upon the initial load I have 5 instances of that class, after the first restart I have 6, after the second restart I have 7 instances... The extra instances seem to be related to HSQLDB, Quartz, Apache log and some java.security classes, but I'm not sure yet who is guilty of keeping the whole set alive, or if that's normal. Something similar happens with com.caucho.xml.Xml: I start with 2 instances, one referenced from a class of mine and another from java.lang.ThreadLocal. After a restart I get 2 instances referenced from java.lang.ThreadLocal. Another restart and I have 3 referenced from java.lang.ThreadLocal... In this case, the problem seems to be a growing number of instances from org.apache.xml.utils.XMLReaderManager... that are themselves related to the aforementioned com.caucho.loader.EnvironmentClassLoader. So my question would be if anybody has run into similar issues or has any idea what could be causing the proliferation of com.caucho.loader.EnvironmentClassLoader instances. I suspect it might be that some library is keeping a reference to the classloader through some daemon thread that is not being properly initialised when the context is restarted. Any hints on how to further debug this issue? Any similar experience? Thanks, D. ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
