Connection commit working on Windows but not on Linux

[emmelie....@gmail.com]

Hi,

I have a project in OSGi that I now want to test on a Linux server. The bundles are started through Felix (4.4.1). I am trying to add a graph to the Stardog store. This is done in following code (where context is null and the amount of statements is 24405 when executing the code):

The addGraph method looks like this:

When I execute this locally on my Windows PC, there are no problems. Everything is committed. On the other hand, when I want to execute this on a Linux (Ubuntu 12.04) server, the commit does not complete. The debugger in Linux shows:

Based on this debug information, I assume the problem is the conn.commit() that does not complete. Are there some properties that I should change if I launch the bundle on the Linux server in stead of my Windows PC? I do not get a Stardog exception, so I do not think that the commit is aborted.

Thanks in advance,

Emmelie

[Mike Grove]

The debug information indicates that prior to commit the client is attempting to flush the data in the commit to the server before it invokes the commit operation; add/remove data to a transaction is a lazy operation, the data isn't pushed until it's absolutely required.

Further, the calls between client & server are asynchronous, so if that's the last message you're seeing, it suggests the server as not yet responded.

Did you try your application with a non-modified version of Stardog?  There's no reason Stardog would work on Windows, and not on Linux.  Our CI server runs the same version of Ubuntu, so I know it works fine on there.

Cheers,

Mike

 

Thanks in advance,

Emmelie

--
-- --
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

[Bram]

Hi Mike,

Thank you for your reply. Emmelie is a colleague of mine.

This issue is not yet resolved.

We have 2 different test environments. The first consists of 2 ubuntu servers and the second of only one ubuntu server. It is the installation where the client and stardog server runs on the same ubuntu server that we do not get any reply from the server after this particular line of code.

The code also works fine when we execute it from our eclipse development environment from a Windows client. But then again the test consists of a client and a server.

I've tried enabling the audit and access logging but I only see 1 line in both files on stardog server startup. Could we maybe alter the log level somewhere?

I'll try and create a non OSGi test application that uses the regular stardog client libraries and see if this works. If you have any thought meanwhile, please let me know.

With kind regards
Bram


Op donderdag 28 augustus 2014 13:21:51 UTC+2 schreef Michael Grove:

[Mike Grove]

On Thu, Sep 25, 2014 at 8:35 AM, Bram <bgad...@intec.ugent.be> wrote:

Hi Mike,

Thank you for your reply. Emmelie is a colleague of mine.

This issue is not yet resolved.

We have 2 different test environments. The first consists of 2 ubuntu servers and the second of only one ubuntu server. It is the installation where the client and stardog server runs on the same ubuntu server that we do not get any reply from the server after this particular line of code.

The code also works fine when we execute it from our eclipse development environment from a Windows client. But then again the test consists of a client and a server.

I've tried enabling the audit and access logging but I only see 1 line in both files on stardog server startup. Could we maybe alter the log level somewhere?

Stardog uses the standard JDK logging, just put a logging.properties file into the STARDOG_HOME directory and it will grab it on startup.

Cheers,

Mike

[Bram]

Hi Mike,

I found the issue. It was a dependency on sun.misc.Unsafe. This was not yet enabled in our OSGi container.

Thank you for the quick reply!

With kind regards
Bram

Op donderdag 25 september 2014 14:40:30 UTC+2 schreef Michael Grove: