> --- David Sean Taylor <[EMAIL PROTECTED]> wrote: > > > > > > > > > > I have no idea what's going on, or why it thinks there's a > > > cache miss, but more importantly, why it gives up the ghost > > > and stops responding. > > > > > > > Try pressing Ctrl-Break (at least this works on Windows) to get > the > > state of the active threads > > That can least give us a starting point. > > > > OK - I did this. These seem to be the key points: > > > THE GET PORTLET IS WAITING TO GET A LOCK ON THE DISK CACHE > INSTANCES > HASHTABLE > > "Thread-7" prio=5 tid=0x0EFF2C20 nid=0x4d8 waiting for monitor > entry > [f5ee000..f5efdb4] > at > org.apache.jetspeed.cache.disk.JetspeedDiskCache.getInstance(JetspeedDiskCache.java:490) > - waiting to lock <032686E0> (a java.util.Hashtable) > at > org.apache.jetspeed.cache.disk.JetspeedDiskCache.getInstance(JetspeedDiskCache.java:478) > at > org.apache.jetspeed.portal.portlets.JetspeedContent.parse(JetspeedContent.java:176) > at > org.apache.jetspeed.portal.portlets.JetspeedContent.init(JetspeedContent.java:142) > at > org.apache.jetspeed.services.portletfactory.JetspeedPortletFactoryService.getPortlet(JetspeedPortletFactoryService.java:310) > ... > > > > HAS THE INSTANCES HASHTABLE LOCK, WAITING ON URL MGR INIT > -BUT THE MESSAGES SEEM TO INDICATE THE URL MGR HAS DONE THE EARLY > INIT - SO IT SHOULD HAVE FINISHED THE EARLY INIT... > > "DaemonThread:diskcachedaemon" daemon prio=2 tid=0x0AC51668 > nid=0xa30 > waiting on monitor [f35f000..f35fdb4] > at java.lang.Thread.sleep(Native Method) > at > org.apache.jetspeed.services.urlmanager.JetspeedURLManagerService.init(JetspeedURLManagerService.java:107) > at > org.apache.turbine.services.BaseServiceBroker.getService(BaseServiceBroker.java:306) > - locked <06E9EA00> (a java.lang.Class) > at > org.apache.jetspeed.cache.disk.JetspeedDiskCache.initEntries(JetspeedDiskCache.java:151) > at > org.apache.jetspeed.cache.disk.JetspeedDiskCache.getInstance(JetspeedDiskCache.java:496) > - locked <032686E0> (a java.util.Hashtable) > at > org.apache.jetspeed.cache.disk.JetspeedDiskCache.getInstance(JetspeedDiskCache.java:478) > at > org.apache.jetspeed.daemon.impl.DiskCacheDaemon.run(DiskCacheDaemon.java:98) > ... > > > > WAITING FOR INSTANCES HASHTABLE > > "DaemonThread:feeddaemon" daemon prio=2 tid=0x0AB73D48 nid=0xc5c > waiting for monitor entry [f31f000..f31fdb4] > at > org.apache.jetspeed.cache.disk.JetspeedDiskCache.getInstance(JetspeedDiskCache.java:490) > - waiting to lock <032686E0> (a java.util.Hashtable) > at > org.apache.jetspeed.cache.disk.JetspeedDiskCache.getInstance(JetspeedDiskCache.java:478) > at > org.apache.jetspeed.util.SimpleTransform.SAXTransform(SimpleTransform.java:430) > at > org.apache.jetspeed.daemon.impl.FeedDaemon.getEntries(FeedDaemon.java:256) > at > org.apache.jetspeed.daemon.impl.FeedDaemon.run(FeedDaemon.java:194) > ... > > > So - why is JetspeedURLMgrService is hanging on late init when its > done the early init... >
But anyway, how can 2 threads be inside the synchronized section of the JetspeedDiskCache.getInstance method - isn't that the point of the sync... Any reason why instances needs to be a Hashtable - can we make it a non-sync'd Hashmap instead - I'll try it and see... Chris ===== ------------------------------------------ http://www.soccer2002.org.uk - The Game is On! __________________________________________________ Do You Yahoo!? Yahoo! Shopping - Mother's Day is May 12th! http://shopping.yahoo.com -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
