Connection pool creation hang when using Guice

1 view
Skip to first unread message

Tze-John Tang

unread,
Mar 1, 2015, 12:02:51 AM3/1/15
to sta...@clarkparsia.com
After upgrading to Stardog 2.2.4, I am seeing an issue that I did not see in the 2.1.x release. I have attached a simple stripped down example to show the issue.

If I create a ConnectionPool without using Guice injection, then the code executes fine. If I create the ConnectionPool within the Guice injection flow, then it just hangs in ConnectionPool.create() method. It seems to be something in the SNARLClient where it is sitting in an Object.wait().

There are two unit tests in the GuiceIssueTest class. testGeneralStardogConnection() should just work as that is showing the first example. testConnectionPoolProvider() is showing the latter example, and should hang.

Thanks.

-tj

guice_issue.zip

Mike Grove

unread,
Mar 2, 2015, 9:19:22 AM3/2/15
to stardog
Thanks for the test case, I was able to reproduce the behavior locally.  I can see where it's deadlocking during object creation inside Guice.  It's happening when creating one of the codecs for the SNARL protocol, HTTP is not affected.

We'll fix this for the pending 3.0 release.

Cheers,

Mike


--
-- --
You received this message because you are subscribed to the C&P "Stardog" group.
To post to this group, send email to sta...@clarkparsia.com
To unsubscribe from this group, send email to
stardog+u...@clarkparsia.com
For more options, visit this group at
http://groups.google.com/a/clarkparsia.com/group/stardog?hl=en

TJ Tang

unread,
Mar 2, 2015, 9:38:59 AM3/2/15
to stardog
Thanks Mike.

So a possible workaround in the meantime would be to switch from the SNARL protocol to something else? I am currently using the connection pooling, and I believe that only works with SNARL?

-tj

To unsubscribe from this group and stop receiving emails from it, send an email to stardog+u...@clarkparsia.com.

Mike Grove

unread,
Mar 2, 2015, 9:54:48 AM3/2/15
to stardog
On Mon, Mar 2, 2015 at 9:38 AM, TJ Tang <ta...@pobox.com> wrote:
Thanks Mike.

So a possible workaround in the meantime would be to switch from the SNARL protocol to something else? I am currently using the connection pooling, and I believe that only works with SNARL?

Yes, if you use the HTTP protocol, the instantiation order is vastly different, so you should not hit the deadlock issue.  The ConnectionPool class is protocol independent and should work just as well with HTTP-based connections.

Cheers,

Mike
Reply all
Reply to author
Forward
0 new messages