On 04-09-17 12:38, Andrea Aime wrote:
https://github.com/geotools/geotools/blame/master/modules/extension/xsd/xsd-fes/src/main/java/org/geotools/filter/v2_0/bindings/BBOXTypeBinding.java#L91
I am wondering, is there any specific reason why it's there? Could it
be moved to a static initializer
rceforge.net
> *Subject:* Re: [Geoserver-devel] I'm a victim of GEOS-7961 NullPointer
> closed as cannot-reproduce but I make it happen all the time
>
>
>
> Hi Walter,
>
> I believe the synchronization you're proposing is too wide and will cause
> significant s
Behalf Of Andrea
Aime
Sent: Monday, September 4, 2017 5:53 AM
To: Walter Stovall ; Niels Charlier
Cc: geoserver-devel@lists.sourceforge.net
Subject: Re: [Geoserver-devel] I'm a victim of GEOS-7961 NullPointer closed as
cannot-reproduce but I make it happen all the time
Hi Walter,
I believ
Hi Walter,
I believe the synchronization you're proposing is too wide and will cause
significant scalability degradation,
a more localized solution needs to be searched.
Which binding class are you referring to? The one
in org.geotools.filter.v2_0.bindings ?
(there are a few others, I believe this
Walter,
I have reopened GEOT-7961 and linked and pasted your email.
Kind regards,
Ben.
On 02/09/17 22:31, Walter Stovall wrote:
https://osgeo-org.atlassian.net/browse/GEOS-7961
This bug happens under load as a result of a multithreading bug in the
implementation of BBOXTypeBinding.getPropert
https://osgeo-org.atlassian.net/browse/GEOS-7961
This bug happens under load as a result of a multithreading bug in the
implementation of BBOXTypeBinding.getProperties. More specifically, the
partical.getContent() value there will be be corrupted/set to null by another
thread executing that sa
