Mailing-List: contact dev-help@felix.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@felix.apache.org
Date: Thu, 31 Jan 2013 20:43:13 +0000 (UTC)
From: "Guillaume Nodet (JIRA)" <jira@apache.org>
To: dev@felix.apache.org
Message-ID: <JIRA.12535271.1323938146357.225275.1359664993036@arcas>
In-Reply-To: <JIRA.12535271.1323938146357@arcas>
References: <JIRA.12535271.1323938146357@arcas>
Subject: [jira] [Commented] (FELIX-3273) Possible exception when accessing
 headers
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/FELIX-3273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13568083#comment-13568083 ] 

Guillaume Nodet commented on FELIX-3273:
----------------------------------------

Yeah, the uninstall() path won't work, but I think the second use case I mentioned is valid.

bundle.getHeaders() does not hold any lock while calling getCurrentLocalizedHeader, so if the bundle is modified, and 2 threads call getHeaders() concurrently, there may be a problem.

The first one will clear the headers using
                else if (getLastModified() > m_cachedHeadersTimestamp)
                {
                    m_cachedHeaders.clear();
                }

while the second one may throw an exception because the updateHeaderCache will not be called yet by the first thread, thus having an empty map and throwing the exception.

                
> Possible exception when accessing headers
> -----------------------------------------
>
>                 Key: FELIX-3273
>                 URL: https://issues.apache.org/jira/browse/FELIX-3273
>             Project: Felix
>          Issue Type: Bug
>    Affects Versions: framework-3.0.9
>            Reporter: Guillaume Nodet
>             Fix For: framework-4.2.0
>
>
> {code}
> ERROR: Bundle org.ops4j.pax.logging.pax-logging-service [3] EventDispatcher: Error during dispatch. (java.util.NoSuchElementException)
> java.util.NoSuchElementException
> 	at java.util.HashMap$HashIterator.nextEntry(HashMap.java:796)
> 	at java.util.HashMap$ValueIterator.next(HashMap.java:822)
> 	at org.apache.felix.framework.BundleImpl.getCurrentLocalizedHeader(BundleImpl.java:334)
> 	at org.apache.felix.framework.Felix.getBundleHeaders(Felix.java:1428)
> 	at org.apache.felix.framework.BundleImpl.getHeaders(BundleImpl.java:311)
> 	at org.apache.felix.framework.BundleImpl.getHeaders(BundleImpl.java:293)
> 	at org.ops4j.pax.logging.service.internal.PaxLoggerImpl.setDelegateContext(PaxLoggerImpl.java:101)
> 	at org.ops4j.pax.logging.service.internal.PaxLoggerImpl.debug(PaxLoggerImpl.java:131)
> 	at org.ops4j.pax.logging.service.internal.PaxLoggingServiceImpl.log(PaxLoggingServiceImpl.java:149)
> 	at org.ops4j.pax.logging.service.internal.PaxLoggingServiceImpl.log(PaxLoggingServiceImpl.java:115)
> 	at org.ops4j.pax.logging.service.internal.FrameworkHandler.bundleChanged(FrameworkHandler.java:93)
> 	at org.apache.felix.framework.util.EventDispatcher.invokeBundleListenerCallback(EventDispatcher.java:807)
> 	at org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:729)
> 	at org.apache.felix.framework.util.EventDispatcher.run(EventDispatcher.java:949)
> 	at org.apache.felix.framework.util.EventDispatcher.access$000(EventDispatcher.java:54)
> 	at org.apache.felix.framework.util.EventDispatcher$1.run(EventDispatcher.java:106)
> 	at java.lang.Thread.run(Thread.java:680)
> {code}
> The problem happened on 3.0.9 but looking at the getLocalizedHeaders method, nothing has changed so the bug should still be valid for 4.0.x
> I suppose the problem is in the BundleImpl#uninstall method which may clear the cached headers without populating with the default.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira