Titan exception: "The specified attribute is already used for the given property key"

[Allan Johns]

I have a Titan db, and I'm getting this exception on the odd occasion:

The specified attribute is already used for the given property key

There are no unique property keys in my database.

The relevant Titan code looks to be this:

public TitanProperty addProperty(TitanVertex vertex, TitanKey key, Object attribute) {
        verifyWriteAccess(vertex,key);
        // Check that attribute of keyed propertyType is unique and lock if so
        final boolean isUniqueKey = key.isUnique() && !(vertex instanceof TitanRelation);
        if (isUniqueKey)
            keyedPropertyCreateLock.lock();
        InternalRelation e = null;
        try {
            if (isUniqueKey && config.hasVerifyKeyUniqueness() && getVertex(key, attribute) != null) {
                throw new InvalidElementException(
                        "The specified attribute is already used for the given property key: " + attribute, vertex);
            }
            e = edgeFactory.createNewProperty(key, (InternalTitanVertex) vertex, attribute);
            addedRelation(e);
        } finally {
            if (isUniqueKey)
                keyedPropertyCreateLock.unlock();
        }
        Preconditions.checkNotNull(e);
        return (TitanProperty) e;
    }


How can this occur when none of my keys are unique?

Furthermore, the exception has only been thrown so far on properties that I have not defined a type for - I have autotyping enabled (as it is by default), which certainly is not creating unique keys by default.

Thanks,
A

[Matthias Broecheler]

Somehow one of these must have gotten unique. Can you identify which one it is and invoke isUnique() on it as a sanity check?

--
You received this message because you are subscribed to the Google Groups "Aurelius" group.
To unsubscribe from this group and stop receiving emails from it, send an email to aureliusgraph...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
Matthias Broecheler
http://www.matthiasb.com

[Allan Johns]

I can, and it is not. Ie:

(stderr during test):
The specified attribute is already used for the given property key: category

rexster[groovy]> g.getType("category").isUnique()
==>false

Very odd. I should point out that it doesn't happen often - maybe once every few thousand queries. the code throwing the exception is as follows:

def update_vertex(_id, fields, overwrite) {
    try {
        v = g.v(_id);
        for(entry in fields.entrySet()) {
            if(overwrite || (v.getProperty(entry.key) == null))
                v.setProperty(entry.key, entry.value);
        }

        g.stopTransaction(TransactionalGraph.Conclusion.SUCCESS);
        return g.getVertex(v);
    } catch(e) {
        g.stopTransaction(TransactionalGraph.Conclusion.FAILURE);
        throw e;
    }
}

Thx
A

[Matthias Broecheler]

category is actually the attribute and not the key. It just a conincidence that you also have a key of that name. Do you know from the surrounding code what the key is or can you hit the debugger?

You received this message because you are subscribed to the Google Groups "Gremlin-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gremlin-user...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Allan Johns]

I can't debug it no, unfortunately I'm developing in Python not Java. What I can do is patch the code then reinstall with mvn, obviously this is a pretty slow turnaround though. What about the key would you like to know? If you could provide a code snippet, I could patch my code to include this key info in the exception string, and we can go from there.

Cheers
A

[Jonathan Haddad]

Hey Allan,

Are you hitting Rexster directly, or using one of the existing libraries?  

Jon

[Allan Johns]

I'm using Bulbs.

thx
Allan

[James Thornton]

Allan -

Like Matthias pointed out, it looks like you have a property key with the same name as the property itself -- not sure why this would cause an issue, but for clarity, it might be good to use "name" for the category key instead.

Does this only happen on the category key?

You said you have no unique property keys in your DB, but you might double check to make sure. -- I'm wondering if there's a chance a unique key was accidentally set on some other property and the keyedPropertyCreateLock isn't being released for some reason.

- James

[Allan Johns]

Hi James,

I definitely have not created a property key called "category". I only ever create property keys via g.makeType() in a database initialisation function that is only ever executed once, so I cannot be accidentally creating this property key either.

It doesn't just happen on "category", there are several other keys that cause the same problem, and all of them are on properties that I have not made a type for.

Wrt unique keys, I also am definitely not creating any unique keys. Also, I'm clearing the database before running the test, by deleting the entire db/, log/ and saved_caches/ subdirectories of the Cassandra backend.

Here is the function where all type creation takes place:


def init_db() {
    if(g.getType("_uri"))
        return;

    // vertex unique key (uri)
        g.makeType().name("_uri").dataType(String.class).functional(false).indexed().makePropertyKey();

    // vertex indexed keys
    g.makeType().name("element_type").dataType(String.class).functional(false).indexed().makePropertyKey();
    g.makeType().name("job").dataType(String.class).functional(false).indexed().makePropertyKey();
    g.makeType().name("seq").dataType(String.class).functional(false).indexed().makePropertyKey();
    g.makeType().name("shot").dataType(String.class).functional(false).indexed().makePropertyKey();
    g.makeType().name("task").dataType(String.class).functional(false).indexed().makePropertyKey();
    g.makeType().name("component").dataType(String.class).functional(false).indexed().makePropertyKey();
    g.makeType().name("filepath").dataType(String.class).functional(false).indexed().makePropertyKey();
    g.makeType().name("guid").dataType(String.class).functional(false).indexed().makePropertyKey();
    g.makeType().name("user").dataType(String.class).functional(false).indexed().makePropertyKey();

    g.makeType().name("version").dataType(Integer.class).functional(false).indexed().makePropertyKey();
    g.makeType().name("_published").dataType(Integer.class).functional(false).indexed().makePropertyKey();
    g.makeType().name("_external").dataType(Integer.class).functional(false).indexed().makePropertyKey();

    // vertex non-indexed keys
    g.makeType().name("timestamp").dataType(Integer.class).functional(false).makePropertyKey();

    // edges
    g.makeType().name("identifies").functional(false).simple().makeEdgeLabel();
    g.makeType().name("has_thumb").functional(false).simple().makeEdgeLabel();
    g.makeType().name("comments_on").simple().makeEdgeLabel();
    g.makeType().name("has").simple().makeEdgeLabel();
    g.makeType().name("had").simple().makeEdgeLabel();
    g.makeType().name("created").simple().makeEdgeLabel();
    g.makeType().name("used_by").simple().makeEdgeLabel();
}


Matthias, are you guys running any kind of concurrent unit tests on Titan at all, is there some way we could verify what's happening my end is happening for you also?

Thanks
A

[Allan Johns]

*clearing and resetting the database, ie restarting a new rexster server each time.

[Allan Johns]

Also, I'm a bit under it at the moment but when i get a chance, I'll try and get together perhaps a curl-based script that reproduces the problem, that will take my code out of the picture and give you a good repro. This isn't holding me up right now anyway, since it happens infrequently and recovers after a retry.

Thx again
A

[Matthias Broecheler]

Hey Allan,

yes we are running concurrent unit tests, but that does not seem to be the issue here. Note that "category" is not the key, its the value. It's printed out because this value already exists, however, the key is defined unique or functional.

So, what might be happening here is that you are trying to add a property "key=value" to a vertex that already has a property "key=value" and since "key" is defined functional it will complain.

Unfortunately, Titan 0.2 does not lock inside the transaction up front, so you get the exception later. Titan 0.3 has locks in the transaction.

HTH,

Matthias

[Allan Johns]

Hang on I think I might get what's going on... you say that "category" is the value here, not the key.

Would the issue here be Titan's own type creation? If I have multiple concurrent processes causing the same auto type to be created at the same time, wouldn't Titan need to do some kind of locking, since it needs to enforce uniqueness wrt types? And a type is a vertex... right?

This makes sense because I'm certain I'm never setting a vertex property to the value "category". Also, if I run the same test but I don't reset the database, these exceptions go away - because I'm not creating any new types, presumably.

Also wrt functional causing the problem, to be clear are you referring to both locking and non-locking functional? Because all of my functional types are non-locking.

thx
A

[Matthias Broecheler]

I think the issue is this:

You have some key, lets call it "somekey", that is defined as functional but not locking. Then you set the property somekey=category and, possibly in another thread, try to set the same property again somekey=property. If those assignments overlap, this can cause the exception you are seeing. The new version of titan is better at this.