java.util.ConcurrentModificationException
at java.util.HashMap$HashIterator.nextEntry(HashMap.java:782)
at java.util.HashMap$KeyIterator.next(HashMap.java:818)
at org.apache.avalon.excalibur.component.ExcaliburComponentManager.dispose( ExcaliburComponentManager.java:607)
at org.apache.cocoon.components.CocoonComponentManager.dispose(CocoonCompon entManager.java:468)
at org.apache.avalon.framework.container.ContainerUtil.dispose(ContainerUti l.java:345)
at org.apache.cocoon.Cocoon.dispose(Cocoon.java:489)
Now, let's see code snippet...
602 while( m_componentHandlers.size() > 0 )
603 {
604 for( Iterator iterator = m_componentHandlers.keySet().iterator();
605 iterator.hasNext(); )
606 {
607 final Object role = iterator.next();Ok, this call is enclosed in a "synchronized(this)" statement, BUT:
At line 246 I have a m_componentHandlers.put(...) call which is not synchronized (might be a cause of the exception on the Iterator), at line 752 I have a m_componentHandlers.remove(...) on an iterator (????????????????????) which might cause MORE troubles, and definitely addComponent at line 847 where there is a m_componentHandlers.put(...) could be another culprit.
I seriously think (I can't see it but can definitely smell it) that it happens because one of those handlers (somehow) gets recycled, and it's reused before it's actually fully disposed...
So, I _seriously_ think that by fixing the problem adding the appropriate synchronizations, we'll not solve a deeper bug somewhere in the pools...
(CRAP CRAP CRAP CRAP CRAP)
Pier
smime.p7s
Description: S/MIME cryptographic signature
