commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Bessie <tbes...@meez.com>
Subject Re: [configuration] How to get threadsafe subset() config in a threadsafe way?
Date Wed, 14 Mar 2012 21:51:01 GMT
Excuse me, mistake on the stacktrace commented "NullPointerException
on read of a configuration property" - that was a property setting,
not getting; if we find a non-existent property, we add it with a
default value.

- Tim

On Wed, Mar 14, 2012 at 2:48 PM, Tim Bessie <tbessie@meez.com> wrote:
> Surely - here's a few - these are all using commons-config 1.7.  Don't
> know if 1.8 would fix these; since they seemed linked to concurrency,
> I doubt it, but perhaps you know?
>
> ---------------------------------------------------------------
>
> I attempted to avoid ConcurrentModificationExceptions by creating a
> new HashMap from an existing SubsetConfiguration which I'd converted
> to a ConfigurationMap.  Unfortunately, the HashMap creation iterates
> through the underlying Configuration objects, and generates this
> error:
>
> [00:00:37.609]java.util.ConcurrentModificationException
> [00:00:37.609]  at
> org.apache.commons.collections.map.AbstractLinkedMap$LinkIterator.nextEntry(AbstractLinkedMap.java:559)
> [00:00:37.609]  at
> org.apache.commons.collections.map.AbstractLinkedMap$KeySetIterator.next(AbstractLinkedMap.java:459)
> [00:00:37.609]  at
> org.apache.commons.collections.iterators.FilterIterator.setNextObject(FilterIterator.java:183)
> [00:00:37.609]  at
> org.apache.commons.collections.iterators.FilterIterator.hasNext(FilterIterator.java:93)
> [00:00:37.609]  at
> org.apache.commons.configuration.CompositeConfiguration.getKeys(CompositeConfiguration.java:236)
> [00:00:37.609]  at
> org.apache.commons.configuration.SubsetConfiguration.getKeys(SubsetConfiguration.java:196)
> [00:00:37.609]  at
> org.apache.commons.configuration.ConfigurationMap$ConfigurationSet$ConfigurationSetIterator.<init>(ConfigurationMap.java:158)
> [00:00:37.609]  at
> org.apache.commons.configuration.ConfigurationMap$ConfigurationSet$ConfigurationSetIterator.<init>(ConfigurationMap.java:151)
> [00:00:37.609]  at
> org.apache.commons.configuration.ConfigurationMap$ConfigurationSet.iterator(ConfigurationMap.java:202)
> [00:00:37.609]  at java.util.HashMap.putAllForCreate(HashMap.java:536)
> [00:00:37.609]  at java.util.HashMap.<init>(HashMap.java:269)
>
> ---------------------------------------------------------------
>
> NullPointerException on read of a configuration property.  Digging
> into it, it *looks* like there's a null key value in a Map, but we
> don't put any null key values into our configuration.  Could be
> another error caused this to happen, or some concurrent modification
> elsewhere:
>
> java.lang.NullPointerException
>        at org.apache.commons.collections.map.AbstractLinkedMap.removeEntry(AbstractLinkedMap.java:292)
>        at org.apache.commons.collections.map.AbstractHashedMap.removeMapping(AbstractHashedMap.java:542)
>        at org.apache.commons.collections.map.AbstractHashedMap.remove(AbstractHashedMap.java:324)
>        at org.apache.commons.configuration.BaseConfiguration.clearPropertyDirect(BaseConfiguration.java:133)
>        at org.apache.commons.configuration.AbstractConfiguration.clearProperty(AbstractConfiguration.java:503)
>        at org.apache.commons.configuration.CompositeConfiguration.clearPropertyDirect(CompositeConfiguration.java:269)
>        at org.apache.commons.configuration.AbstractConfiguration.clearProperty(AbstractConfiguration.java:503)
>        at org.apache.commons.configuration.AbstractConfiguration.setProperty(AbstractConfiguration.java:483)
>        at com.dm.avatar.configuration.Configuration.getProperty(Configuration.java:880)
>        at com.dm.avatar.configuration.Configuration.getProperty(Configuration.java:835)
>        at com.dm.avatar.configuration.Configuration.getProperty(Configuration.java:830)
>        at com.dm.web.util.CommonService.getHostString(CommonService.java:795)
>
> -------------------------------------------
>
> Another NullPointerException case when wrapping a SubsetConfiguration
> in a ConfigurationMap with a new HashMap:
>
> [08:05:18.787]java.lang.NullPointerException
> [08:05:18.787]  at
> org.apache.commons.configuration.AbstractConfiguration$3.evaluate(AbstractConfiguration.java:577)
> [08:05:18.787]  at
> org.apache.commons.collections.iterators.FilterIterator.setNextObject(FilterIterator.java:184)
> [08:05:18.787]  at
> org.apache.commons.collections.iterators.FilterIterator.hasNext(FilterIterator.java:93)
> [08:05:18.787]  at
> org.apache.commons.configuration.CompositeConfiguration.getKeys(CompositeConfiguration.java:236)
> [08:05:18.787]  at
> org.apache.commons.configuration.SubsetConfiguration.getKeys(SubsetConfiguration.java:196)
> [08:05:18.787]  at
> org.apache.commons.configuration.ConfigurationMap$ConfigurationSet.size(ConfigurationMap.java:189)
> [08:05:18.787]  at java.util.AbstractMap.size(AbstractMap.java:67)
> [08:05:18.787]  at java.util.HashMap.<init>(HashMap.java:267)
> [08:05:18.787]  at
> com.dm.avatar.configuration.Configuration.getPropertiesAsMap(Configuration.java:607)
>
>
>
>
> On Wed, Mar 14, 2012 at 1:24 PM, Oliver Heger
> <oliver.heger@oliver-heger.de> wrote:
>>
>> Am 13.03.2012 19:05, schrieb Tim Bessie:
>>
>>> That's a possibility which I'll look into.
>>>
>>> In the meantime, after initializing our main Configuration wrapper object
>>> with all of our static configuration data, I copy slices of it to static
>>> maps that I know will never change, and provide convenience accessors to
>>> those maps' data.  Since the calls that access the data placed in these new
>>> maps were the only ones asking for slices of config data, this eliminates
>>> our problem.  I was just hoping for a more elegant solution.  But at least
>>> this way there's no locks necessary.
>>>
>>> I'll take a look at your suggestions, however - thanks much!
>>>
>>> A nice feature in the future could be something like
>>> ConfigurationUtils.getSynchronizedInstance(Configuration), for example.
>>>  I'm sure it's been discussed before. :-)
>>>
>>> - Tim
>>
>>
>> You are right, support for concurrent access to Configuration objects can certainly
be improved.
>>
>> Can you provide a stack trace of such a ConcurrentModificationException you receive
occasionally?
>>
>> Thanks
>> Oliver
>>
>>
>>>
>>> On Tue, Mar 13, 2012 at 1:43 AM, Luc Maisonobe<Luc.Maisonobe@free.fr>wrote:
>>>
>>>> Le 13/03/2012 07:34, Tim Bessie a écrit :
>>>>>
>>>>> Hi all...
>>>>
>>>>
>>>> Hi Tim,
>>>>
>>>>>
>>>>> So we're keeping some config information CompositeConfiguration object,
>>>>
>>>> and
>>>>>
>>>>> we need to get subsets of this configuration data.
>>>>>
>>>>> When I call .subset(...), and then do some checks on the subset
>>>>
>>>> (isEmpty(),
>>>>>
>>>>> etc.), I sometimes get ConcurrentModificationExceptions.  I'm not sure
>>>>> what's modifying the underlying configuration, although we do have
>>>>> occasional setting of configuration values throughout the running of
our
>>>>> app.
>>>>>
>>>>> What would be *ideal* would be to:
>>>>>
>>>>> 1. NOT have to synchronize every access to the configuration object,
>>>>
>>>> since
>>>>>
>>>>> we have a high-volume application
>>>>> 2. To allow read and write operations to happen to the configuration
>>>>
>>>> object
>>>>>
>>>>> without worrying about ConcurrentModificationExceptions
>>>>> 3. To be able to call .subset(...) on the configuration object and 1)
not
>>>>> risk a ConcurrentModificationException during this operation, and 2)
get
>>>>
>>>> a
>>>>>
>>>>> COPY of the subset back, so that further operations on the subset don't
>>>>> risk ConcurrentModificationExceptions
>>>>>
>>>>> Does anyone know of a way to do this?  Or is the ONLY way to guarantee
>>>>
>>>> lack
>>>>>
>>>>> of CMEs to synchronize EVERY access (reads, writes, subsets, iterations,
>>>>> etc.)?
>>>>
>>>>
>>>> Perhaps you could try java.util.concurrent.locks.ReadWriteLock ? You
>>>> would have to put the protection by yourself so it may require lots of
>>>> code wrapping. One of the good thins is that it allows concurrent read
>>>> (but when a write occurs, only one thread can write and reads are blocked).
>>>>
>>>> Luc
>>>>
>>>>>
>>>>> If this is the case, how have others dealt with situations like ours,
>>>>
>>>> where
>>>>>
>>>>> you do mostly just reads on a Configuration object, but very occasional
>>>>> writes, and need to take subsets, and need to avoid exceptions while
>>>>
>>>> doing
>>>>>
>>>>> this?  With a high volume app, synchronizing every access would slow
>>>>
>>>> things
>>>>>
>>>>> waaaaaay down, thus my question.
>>>>>
>>>>> - Tim
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: user-help@commons.apache.org
>>>>
>>>>
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
>> For additional commands, e-mail: user-help@commons.apache.org
>>
>
>
>
> --
>
> Tim Bessie
> Meez, Inc.
> tbessie@meez.com



-- 

Tim Bessie
Meez, Inc.
tbessie@meez.com

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org


Mime
View raw message