Re: [Bigdata-developers] NPE on BlazeGraph 1.5.1

[Bryan T. <br...@sy...>]

The NPE is on the bold lines below. getSPORelation() is returning null.

final public IAccessPath<ISPO> getAccessPath(final IV s, final IV p,
            final IV o,final IV c, final RangeBOp range) {

*        return getSPORelation()*
*                .getAccessPath(s, p, o, c, range);*

    }

The code for this method is below.  It uses what amounts to a
double-checked locking pattern to avoid synchronization in the common case
where the value is already set on the atomic reference.  abort(), create(),
destroy() and this method can all set its value, but this is the only
method that will set it to a non-null value.

    final public SPORelation getSPORelation() {

        if (spoRelationRef.get() == null) {

            /*
             * Note: double-checked locking pattern (mostly non-blocking).
Only
             * synchronized if not yet resolved. The AtomicReference is
reused
             * as the monitor to serialize the resolution of the
SPORelation in
             * order to have that operation not contend with any other part
of
             * the API.
             */
            synchronized (this) {

                if (spoRelationRef.get() == null) {

                    spoRelationRef.set((SPORelation) getIndexManager()
                            .getResourceLocator().locate(
                                    getNamespace() + "."
                                            + SPORelation.NAME_SPO_RELATION,
                                    getTimestamp()));

                }

            }

        }

        return spoRelationRef.get();

    }

    private final AtomicReference<SPORelation> spoRelationRef = new
AtomicReference<SPORelation>();

My most likely interpretation for this is that the operation has been
cancelled and this represents the asynchronous case where the
spoRelationRef value was cleared by abort().  However, you might want to
turn on logging @ INFO on the DefaultResourceLocator class.  This is the
class that is being called by the *locate()* call above.  This *can* return
null, but it should only return null if the index does not exist.  This
should not be true when it is running a query against an existing triple
store.

This might be related to #468 (rare interrupt of rangeCount during query on
cluster).  That is, it is possible that an interrupt is coming through in a
race with the rangeCount() call and you are seeing this NPE when the
abort() is executed before the rangeCount() and the thread calling
rangeCount() might have been interrupted, but it has not observed the
interrupt yet (has not hit a lock or IO, etc.).

Both of these potential explanations would beg the questions:

a. why is abort() being called (rollback() of the connection running the
query or canceling the query could do this).
b. why is an interrupt being raised (if we believe that abort() was called
due to query termination by interrupt)?  Is this to cancel the query?  Or
is it spurious?

So the question is whether this is a data race that is triggered by an
intentional cancellation of the query (which could also be due to an error
during query processing) or a data race triggered by a spurious interrupt
(which would be unpleasant) or something else?

Yes, it is worth looking into further.

Thanks,
Bryan


----
Bryan Thompson
Chief Scientist & Founder
SYSTAP, LLC
4501 Tower Road
Greensboro, NC 27410
br...@sy...
http://blazegraph.com
http://blog.bigdata.com <http://bigdata.com>
http://mapgraph.io

Blazegraph™ <http://www.blazegraph.com/> is our ultra high-performance
graph database that supports both RDF/SPARQL and Tinkerpop/Blueprints
APIs.  MapGraph™ <http://www.systap.com/mapgraph> is our disruptive new
technology to use GPUs to accelerate data-parallel graph analytics.

CONFIDENTIALITY NOTICE:  This email and its contents and attachments are
for the sole use of the intended recipient(s) and are confidential or
proprietary to SYSTAP. Any unauthorized review, use, disclosure,
dissemination or copying of this email or its contents or attachments is
prohibited. If you have received this communication in error, please notify
the sender by reply email and permanently delete all copies of the email
and its contents and attachments.

On Thu, Apr 23, 2015 at 3:50 PM, Stas Malyshev <sma...@wi...>
wrote:

> Hi!
>
> I've encountered an NPE exception running Blazegraph with our data
> update tool, the dump is here:
> https://gist.github.com/smalyshev/6b8b318c8449bfb837e1
>
> This seems to be random (the same query runs again with no issue) and
> happened under some load, but does not seem to be reproducible since. I
> am still worried it may hint at some bug. Any ideas of how to
> investigate it further and if there's a reason for worry?
>
> Thanks,
> --
> Stas Malyshev
> sma...@wi...
>
>
> ------------------------------------------------------------------------------
> BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
> Develop your own process in accordance with the BPMN 2 standard
> Learn Process modeling best practices with Bonita BPM through live
> exercises
> http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual-
> event?utm_
> source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
> _______________________________________________
> Bigdata-developers mailing list
> Big...@li...
> https://lists.sourceforge.net/lists/listinfo/bigdata-developers
>