Unexplained NPE

[Ian Clarke]

I'm seeing this when I call Morphia.createDatastore():

java.lang.NullPointerException
at java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:768)
at com.mongodb.Mongo.getDB(Mongo.java:165)
at com.google.code.morphia.DatastoreImpl.<init>(DatastoreImpl.java:61)
at com.google.code.morphia.DatastoreImpl.<init>(DatastoreImpl.java:55)
at com.google.code.morphia.Morphia.createDatastore(Morphia.java:156)
at net.uprizer.engine.db.Database.<init>(Database.java:30)
at net.uprizer.engine.db.DatabaseTest.setUp(DatabaseTest.java:14)
at junit.framework.TestCase.runBare(TestCase.java:125)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:118)
at junit.framework.TestSuite.runTest(TestSuite.java:208)
at junit.framework.TestSuite.run(TestSuite.java:203)
at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)

Here is the code I'm using to set it up:

final Mongo mongo = new Mongo(config.host, config.port);
final Morphia morphia = new Morphia();
morphia.mapPackage("net.uprizer.engine.db.orm");
datastore = morphia.createDatastore(mongo);

I'm pretty sure config.host and config.port are what they should be -
what would cause this?

Ian.

--
Ian Clarke
CEO, SenseArray
Email: i...@sensearray.com
Ph: +1 512 422 3588

[Scott Hernandez]

You probably want to specify the dbname as well. I think we used to
default to "test" but I think that changed. Different versions of the
driver may respond differently if no dbname is used.

[Ian Clarke]

Ah, ok - I think that was it.

Now I'm seeing another problem, a stack overflow error on
datastore.ensureindexes(), it looks like it is recursing
indefinitely... I don't think I'm doing anything especially out of the
ordinary - any ideas?

Ian.

[Scott Hernandez]

I can't think of anything obvious. If you can get a stack dump/trace
that would help.

I'll remove the createDatastore(Mongo) signature since it doesn't make
sense without a default database name, and the current driver throws
the NPE.

[Ian Clarke]

Sure, basically the exception is several hundred lines that look like this:

java.lang.StackOverflowError
at com.google.code.morphia.DatastoreImpl.ensureIndex(DatastoreImpl.java:197)

Ian.

On Thu, Jul 15, 2010 at 2:28 PM, Scott Hernandez

[Scott Hernandez]

You can turn on fine logging and that might help. It will at least
tell us what is going on.

If you have a repo case that would help too :)

[Ian Clarke]

Oh, BTW - you'll need Google Collections in the classpath for it,
sorry about that.

Ian.

On Thu, Jul 15, 2010 at 3:26 PM, Ian Clarke <i...@sensearray.com> wrote:
> Here is a repo case:
>
>  http://gist.github.com/477471
>
> Hope this helps!
>
> Ian.
>
> On Thu, Jul 15, 2010 at 3:06 PM, Scott Hernandez

[Ian Clarke]

Here is a repo case:

http://gist.github.com/477471

Hope this helps!

Ian.

On Thu, Jul 15, 2010 at 3:06 PM, Scott Hernandez

[Scott Hernandez]

Yeah, it was clearly bad code. I have fixed it, but until the fix is
out there you can use the longer format.

Just call ensureIndex(Ad.class, null, fieldSet, false, false)

It was just the short form that had a problem (the 2 args one).

[Ian Clarke]

Thanks Scott, will try that.

Ian.

On Thu, Jul 15, 2010 at 3:41 PM, Scott Hernandez

[Scott Hernandez]

Also, you should use an ordered set (like the one in the driver), not
a hashset. I have changed the interface to use arrays in the
future(0.95); it is clear then that they are ordered.

[Ian Clarke]

In that case wouldn't it make sense for IndexFieldDef to implement Comparable?

Ian.

[Scott Hernandez]

And what would it do? Are you suggesting we add an index-number to
specify the ordinal (position) for each def? It isn't like the compare
order is constant; it would need to change in every set in which it is
included.

[Ian Clarke]

I guess the real question is: why are we supposed to use an ordered set here?

By "ordered set", do you mean that it should implement SortedSet, like TreeSet?  That was why I made that suggestion, TreeSet requires the objects it contains to implement Comparable (or that you provide a Comparator).

Ian.

[Scott Hernandez]

Indexes with the same fields are not the same, if the order is
changed. They are ordered in the sense that you put them in a specific
order, and they stay that way; they are not sorted and the order is
not changed.

The index {b:1, a:1} is different than the index {a:1, b:1} .

I think an array conveys this concept best. Using a set (which is just
a unique collection/list) doesn't make sense because of the exact
discussion we are having... it doesn't make it clear that order
matters.

[Ian Clarke]

On Thu, Jul 15, 2010 at 4:57 PM, Scott Hernandez <scotthe...@gmail.com> wrote:

Indexes with the same fields are not the same, if the order is
changed. They are ordered in the sense that you put them in a specific
order, and they stay that way; they are not sorted and the order is
not changed.

In other words: they are a List, not a Set.

 

I think an array conveys this concept best. Using a set (which is just
a unique collection/list) doesn't make sense because of the exact
discussion we are having... it doesn't make it clear that order
matters.

Right, its not in the contract of a Set, it needs to be a List, and an array is a type of List.  In fact, I would suggest using a List rather than an Array, since Array is overly restrictive.

What container do you recommend I use in the meantime?

Ian.

 

[Scott Hernandez]

On Thu, Jul 15, 2010 at 3:03 PM, Ian Clarke <i...@sensearray.com> wrote:
> On Thu, Jul 15, 2010 at 4:57 PM, Scott Hernandez <scotthe...@gmail.com>
> wrote:
>>
>> Indexes with the same fields are not the same, if the order is
>> changed. They are ordered in the sense that you put them in a specific
>> order, and they stay that way; they are not sorted and the order is
>> not changed.
>
> In other words: they are a List, not a Set.

Yeah, except there are plenty of SortedList derivatives and other
implementations which are not order preserving.

>> I think an array conveys this concept best. Using a set (which is just
>> a unique collection/list) doesn't make sense because of the exact
>> discussion we are having... it doesn't make it clear that order
>> matters.
>
> Right, its not in the contract of a Set, it needs to be a List, and an array
> is a type of List.  In fact, I would suggest using a List rather than an
> Array, since Array is overly restrictive.

ArrayList maybe (I try not to use concrete types in public interfaces,
but this does make sense in this case); but I'm not sure how an array
is overly restrictive in this case. It is unlikely that you will be
add/remove from it. In fact, the new interface it very easy to use.

ds.ensureIndex(Ad.class, new IndexFieldDef("lastMod"), new
IndexFieldDef("active", IndexDirection.ASC));

This is nice since it takes "IndexFieldDef...fields" as the last arg;
this little syntactic sugar makes it easy to use.

> What container do you recommend I use in the meantime?

There are ordered set implementations, like the one if the driver that
works just fine (com.mongodb.util.OrderedSet).