As for the nullness, you can see this if the ServiceRegistry is reused.
I have not come up with a good solution for that aside from us
explicitly checking (after adding needed method to ask) that the passed
registry is still valid.
Not getting the concern here about concurrency. The map and list in
question are immutable after the registry instantiation is complete,
which has to happen on a single thread. But its way complicated to code
that. We would need a "InitializationContext" or something to hold them
during the constructor processing. I used a ConcurrentHashMp because
sure it will be *accessed* concurrently. This is stuff held at the
SessionFactory level.
On 06/22/2011 11:00 AM, Scott Marlow wrote:
Also appears that AbstractServiceRegistryImpl.serviceList is a
mutable
object and accessed through a mutable object reference.
AbstractServiceRegistryImpl.serviceList should also be changed to an
immutable object reference (final and let
AbstractServiceRegistryImpl.destroy just clear it).
Something also needs to be done to make updates to the
AbstractServiceRegistryImpl.serviceList object thread safe (used to
ensure services are destroyed in reverse order). Maybe Steve should
make this change, so he can choose the concurrent data structure (maybe
CopyOnWriteArrayList?) Or maybe rolling our own concurrent ArrayList
for needs like this.
I'd jump on IRC but the place I'm at this week, seems to be blocking
freenode irc...
On 06/22/2011 11:30 AM, Scott Marlow wrote:
> Good point, it should be "final".
>
> I'll make that change (if not done already).
>
> On 06/22/2011 11:20 AM, Emmanuel Bernard wrote:
>> Could it be some thread concurrency visibility?
>> Since it's a concurrent hashmap, I'd venture it's accessed
concurrently :)
>>
>> Try and make the variable final (or volatile) to ensure proper visibility across
threads.
>>
>> On 22 juin 2011, at 02:44, Scott Marlow wrote:
>>
>>> I'm not sure if we will see this NPE again but found the location
>>> interesting. I wanted to report the failure in case it happens again in
>>> the future or anyone else is interested in playing detective for
>>> mysteries like this. ;)
>>>
>>> The exception call stack is here
http://pastie.org/2104060
>>>
>>> It looks to me like AbstractServiceRegistryImpl.serviceBindingMap is
>>> null for some reason. It makes me wonder if
>>> AbstractServiceRegistryImpl.destroy() was called prematurely for some
>>> reason (for some unexpected reason).
>>>
>>> I wanted to mention the NPE here in case it happens again, so we can see
>>> what is in common with this one. Next time, we will have to capture the
>>> AS server.log output which might have additional clues but didn't this
time.
>>>
>>> Scott
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev(a)lists.jboss.org
>>>
https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/hibernate-dev
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev