headers
Andrew Jaquith | 1 Mar 2007 02:56
Picon

Re: A lot of listeners created from guestSession()

>> background thread that worked like the lock reaper. If the  
>> SessionMonitor is not removing WikiSessions when the HttpSession  
>> expires, THEN IT IS A BUG. I believe we fixed such a bug  
>> (classcast exception) in 2.5.20.
>
> I thought so too but I'm currently using the latest CVS (maybe -1) and
> still seeing tons of guest sessions. Will investigate further...

Cool. I'd be curious to hear what you find; again, these things  
should be expiring themselves according to the container's settings.

> I'd really prefer (1) as I have very low appreciation of  
> WeakReferences
> right now -- they seem to me a sloppy way of approaching a problem, a
> way of mopping up from the backend rather than simply being diligent
> about cleaning up after oneself. Since they're weak we can't even rely
> on them necessarily. I don't see that this future proofs anything,
> maybe I'm not understanding you exactly. (I wouldn't -- myself  
> anyway --
> worry about future events we haven't thought of yet.)

WeakReferences "future-proof" things in the sense that they protect  
against developers (like ourselves, it seems...) who don't always  
clean up listener lists. It's a defensive programming technique, and  
a fairly well accepted one at that. Remember that the events are  
MEANT to be listened to by classes that aren't necessarily core to  
JSPWiki. That's why the interfaces are public and documented (by you!  
thanks by the way). Third-party developers and end-users may NOT  
fully appreciate the memory implications of stashing listeners all  
over the place without cleaning them up. So, as much as you might
(Continue reading)

Permalink | Reply | 6 comments |
headers
Murray Altheim | 1 Mar 2007 03:28
Favicon

Re: A lot of listeners created from guestSession()

Andrew Jaquith wrote:
>>> background thread that worked like the lock reaper. If the 
>>> SessionMonitor is not removing WikiSessions when the HttpSession 
>>> expires, THEN IT IS A BUG. I believe we fixed such a bug (classcast 
>>> exception) in 2.5.20.
>>
>> I thought so too but I'm currently using the latest CVS (maybe -1) and
>> still seeing tons of guest sessions. Will investigate further...
> 
> Cool. I'd be curious to hear what you find; again, these things should 
> be expiring themselves according to the container's settings.

Well, CVS is back up again so I've just downloaded 2.5.28 but I won't
be using it today as I'm trying to concentrate on a few other things.
I'm currently using 2.5.23 for my test wiki, which is exhibiting the
creation of all these listeners. Here's an output of me testing the
MostPopularPlugin (MPP) and MostPopularListener (MPL)

   [java] WikiJSPFilter() BEGIN. count=1
   [java] WIKI_SERVLET_FILTER: fireEvent! type=24; page=''MostPopularPlugin'
   [java] WEM.fireEvent() source: com.ecyrd.jspwiki.WikiEngine; page requested event (24)
   [java] (guestSession)
   [java] DELEGATE.addWikiEventListener() to com.ecyrd.jspwiki.auth.authorize.GroupManager; 168
listeners; already contains? false
   [java] DELEGATE.addWikiEventListener() to com.ecyrd.jspwiki.auth.AuthenticationManager; 168
listeners; already contains? false
   [java] (guestSession)
   [java] DELEGATE.addWikiEventListener() to com.ecyrd.jspwiki.auth.authorize.GroupManager; 169
listeners; already contains? false
   [java] DELEGATE.addWikiEventListener() to com.ecyrd.jspwiki.auth.AuthenticationManager; 169
(Continue reading)

Permalink | Reply | 1 comment |
headers
Janne Jalkanen | 1 Mar 2007 09:11

Re: A lot of listeners created from guestSession()

> I have no idea what you mean by "hundreds of guest sessions". Maybe  
> I missed something and I should just RTFT. What's generating all of  
> these?

ReferenceManager and ACL initialization.  In order to do that, we  
parse the wikipages.  Parsing the wikipages creates a WikiContext.   
Creating a WikiContext creates a WikiSession.  Creating a WikiSession  
without a HTTP request creates a new GuestSession for each parser...

/Janne
Permalink | Reply | 3 comments |
headers
Janne Jalkanen | 1 Mar 2007 09:18

Re: JSPWiki future

> This is available for a long time in log4j,
> DomConfigurator.configureAndWatch() uses XML syntax for describing  
> the log4j
> config (and has more features), but there is also a Java property  
> based
> configurator (PropertyConfigurator.configureAndWatch), my guess is  
> that the
> latter would be fairly easy to start using in jspwiki.

Well, yes and no.

configureAndWatch() looks at a file.  We find our property file using  
findResourceAsStream(), so we can e.g. find it from a WAR file, and  
then call configure(Properties).  What is needed is a new  
WikIEngine.configureLog4j() method which knows how to handle all  
these special cases and call configureAndWatch() if the file is a  
real file.

So it's not like  changing a method call, but it's doable :-/

/Janne
Permalink | Reply | 0 comments |
headers
Janne Jalkanen | 1 Mar 2007 10:24

Re: A lot of listeners created from guestSession()

> Well, CVS is back up again so I've just downloaded 2.5.28 but I won't

Just to reiterate: the fixes I made are *not* in 2.5.  They are in  
2.4.  I won't forward port them until they turn out to be a good idea.

Having said that, we went through the night (my night) with only a  
single Tomcat crash, which is a better than what it used to be.  So  
while we still have some leaks, 2.4.97 seems somewhat healthier than  
2.4.96.

/Janne
Permalink | Reply | 0 comments |
headers
Murray Altheim | 1 Mar 2007 10:25
Favicon

Re: A lot of listeners created from guestSession()

Janne Jalkanen wrote:
>> I have no idea what you mean by "hundreds of guest sessions". Maybe I 
>> missed something and I should just RTFT. What's generating all of these?
> 
> ReferenceManager and ACL initialization.  In order to do that, we parse 
> the wikipages.  Parsing the wikipages creates a WikiContext.  Creating a 
> WikiContext creates a WikiSession.  Creating a WikiSession without a 
> HTTP request creates a new GuestSession for each parser...

Okay, I've downloaded 2.5.28 from CVS and got it running, and then
made the test mods I'd made to my earlier 2.5.23 working copy. In
looking at the place in WikiSession.guestSession() where listeners
are added to both GroupManager and AuthenticationManager, I added
a check for a new method in WikiEngine that I can't see would have
any side effects:

   /**
    *  Returns true if the WikiEngine has been configured (initialized).
    */
   public boolean isConfigured()
   {
       return m_isConfigured;
   }

If this is seen as a Bad Idea I could I suppose have the WikiSession
wait until the engine is configured (initialized, can we change the
name of that variable?) and sends its WikiEvent, but this is really
a lot simpler.

Anyway, I then made one change to WikiSession.guestSession():
(Continue reading)

Permalink | Reply | 0 comments |
headers
Terry Steichen | 1 Mar 2007 12:09

WeakReference

Out of total ignorance on the subject, I just did a little research on 
WeakReference.  My understanding is that the JVM's garbage collector 
will remove these when it encounters them, but it may take several 
passes for this to happen:

    *The WeakReference class*
    A typical use of the |WeakReference| class is for canonicalized
    mappings. In addition, weak references are useful for objects that
    would otherwise live for a long time and are also inexpensive to
    re-create. The key point is that when the garbage collector runs, if
    it encounters a |WeakReference|, it will free the object the
    |WeakReference| refers to. Note, however, that it may take multiple
    runs of the garbage collector before it finds and frees an object
    referenced by a |WeakReference|.

    If the garbage collector discovers an object that is weakly
    reachable, the following occurs:

        * The WeakReference object's referent field is set to null,
    thereby making it not refer to the heap object any longer.

        * The heap object that had been referenced by the WeakReference
    is declared finalizable.

        * When the heap object's finalize() method is run and its memory
    freed, the WeakReference object is added to its ReferenceQueue, if
    it exists.

I may be missing something, but that doesn't sound like the kind of 
object we want to be representing a WikiSession.  It sounds like the
(Continue reading)

Permalink | Reply | 19 comments |
headers
Janne Jalkanen | 1 Mar 2007 12:21

Re: WeakReference

> I may be missing something, but that doesn't sound like the kind of  
> object we want to be representing a WikiSession.  It sounds like  
> the result will be a more-or-less random disappearance of  
> WikiSessions.

Well, *after* there are no more references to the particular  
wikisession, *except* by the event manager which holds a *weak*  
reference to it, *then* the session will be released at a *random*  
garbage collection.

As long as you are using it for some real purpose, though, it *won't*  
disappear.  A normal reference prevents an object to be garbage  
collected, because it is still being used.   You can think of the  
WeakReference in EventManager to be a sort of a "well, as long as  
someone is using it, I will send messages to it, but once everybody  
else has released it and I am the only one left, I will release it  
too, because it's not my job to manage the life cycle of wiki  
sessions" -kind of a mechanism.

Trust me, WeakReferences are really nice once you wrap your brain  
around them.  It'll just take a while.

/Janne
Permalink | Reply | 16 comments |
headers
Murray Altheim | 1 Mar 2007 12:23
Favicon

Re: WeakReference

Terry Steichen wrote:
> Out of total ignorance on the subject, I just did a little research on 
> WeakReference.  My understanding is that the JVM's garbage collector 
> will remove these when it encounters them, but it may take several 
> passes for this to happen:
> 
>    *The WeakReference class*
[...]
> I may be missing something, but that doesn't sound like the kind of 
> object we want to be representing a WikiSession.  It sounds like the 
> result will be a more-or-less random disappearance of WikiSessions.

Terry,

Yup, I may not have made my point very well earlier, but that's what
I meant when I wrote that when I create something I want it around
until I destroy it or remove all references to it. I find not
knowing what the state of something is until you test it a bit like
Schrodinger's cat, with some of the same undesirable drama.

Murray

...........................................................................
Murray Altheim <murray06 <at> altheim.com>                              ===  = =
http://www.altheim.com/murray/                                     = =  ===
SGML Grease Monkey, Banjo Player, Wantanabe Zen Monk               = =  = =

        In the evening
        The rice leaves in the garden
        Rustle in the autumn wind
(Continue reading)

Permalink | Reply | 1 comment |
headers
Terry Steichen | 1 Mar 2007 13:26

Re: WeakReference

Janne,

OK, I hope I'm beginning to get my head around the concept.  But my 
understanding is that from the instant of creation of the WikiSession, 
the WikiEventManager holds a WeakReference to it.  So I presume from 
what you're saying that some other JSPWiki objects have regular (non 
weak) reference to the WikiSession (which prevents the random 
disappearance of the WikiSession)? 

And, if that's so, I presume you're also saying that when the container 
calls SessionMonitor's sessionDestroyed() method, these other regular 
references are (somehow?) removed (so that all that remains is the 
WeakReference, which will be taken care of by GC)?

The above notwithstanding, I think it's probably a prudent thing to 
explicitly remove the WikiSession, if you have a clear point where that 
can be reliably done (which we do, in the SessionMonitor).  Do you agree?

Terry

PS: I realize we're spending a lot of time on this, but it's an 
important part of the JSPWiki architecture.

Janne Jalkanen wrote:
>> I may be missing something, but that doesn't sound like the kind of 
>> object we want to be representing a WikiSession.  It sounds like the 
>> result will be a more-or-less random disappearance of WikiSessions.
>
> Well, *after* there are no more references to the particular 
> wikisession, *except* by the event manager which holds a *weak*
(Continue reading)

Permalink | Reply | 15 comments |

Gmane