Unable to bring DB's online in Stardog studio

Hi folks,
Yesterday I was working in Stardog studio just fine. Today, I can't bring any of my databases online.
I can bring them online from the command line, or from the Web console. I uninstalled and re-installed Studio with no change.

My machine updated some software yesterday. Perhaps a Java issue is at play:
Windows OS
Java 1.9.0_152
Stardog Server 6.1.0
Stardog Studio 1.13.0

The problem:
In Studio, I connect to Stardog server just fine. All databases appear offline (odd). I right click on a database (named TESTDB) and select Bring Online. I get message: "Database TESTDB is offline." I try again and get the message "Invalid Database State: Cannot offline."

Error reported in stardog.log:
ERROR 2019-11-01 09:29:30,821 [stardog-user-31] com.stardog.http.server.undertow.ErrorHandling:writeError(138): Unexpected error on the server
com.complexible.stardog.StardogException: Database 'TESTDB' is not online.
at com.complexible.stardog.StardogKernel.assertOnline(StardogKernel.java:2808) ~[stardog-6.1.0.jar:?]
at com.complexible.stardog.StardogKernel.getConnection(StardogKernel.java:1139) ~[stardog-6.1.0.jar:?]
at com.complexible.stardog.protocols.http.server.KernelHttpService.openConnection(KernelHttpService.java:101) ~[stardog-protocols-http-server-6.1.0.jar:?]
at com.complexible.stardog.protocols.http.server.KernelHttpService.openConnection(KernelHttpService.java:93) ~[stardog-protocols-http-server-6.1.0.jar:?]
at com.complexible.stardog.protocols.http.server.SPARQLProtocol.executeQuery(SPARQLProtocol.java:109) ~[stardog-protocols-http-server-6.1.0.jar:?]
at com.complexible.stardog.protocols.http.server.SPARQLProtocol.post(SPARQLProtocol.java:91) ~[stardog-protocols-http-server-6.1.0.jar:?]
at com.stardog.http.server.undertow.jaxrs.ExtractRoutes.lambda$handleIt$5(ExtractRoutes.java:192) ~[stardog-protocols-http-server-6.1.0.jar:?]
at org.apache.shiro.subject.support.SubjectRunnable.doRun(SubjectRunnable.java:120) [shiro-core-1.2.3.jar:1.2.3]
at org.apache.shiro.subject.support.SubjectRunnable.run(SubjectRunnable.java:108) [shiro-core-1.2.3.jar:1.2.3]
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) [?:1.8.0_152]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) [?:1.8.0_152]
at java.lang.Thread.run(Unknown Source) [?:1.8.0_152]

Thanks in advance,


To clairify the problems that you're having, when you say "I can brring them online from the command line, or from the Web console" was that before of after you experienced the problem in studio?

What do you get when you run stardog-admin db status TESTDB from the command line?

If it's offline can you online it from the CLI? starodg-admin db online TESTDB

If you can online it, does relaunching Studio and connecting change the state back to offline?

After further investigation:
From the command line, I can determine the databases that should be online actually are online, but are not showing as such in Studio and I can't edit the database properties in Studio. Could this be an authentication issue I am having in Studio where it thinks I do not have the permissions to bring the db's on/offline or alter the database configuration? I am logged in as admin when I connect to Stardog via Studio...

I've attached a view from Studio that seems to indicate TESTDB is offline, since the only menu choice is "Bring online", yet this command line output shows the DB is already online, and I can even query TESTDB from Studio. When I double click on TESTDB in Studio, I do not get a view of the database configuration.

C:>stardog-admin db status TESTDB
Database : TESTDB
Status : Online
Size : 104 triples
Queries : None running
Open Connections : 0
Open Transactions : 0
Query Avg. Time : 0.02 s
Query Rate : 0.01 queries/sec
Plans Cached : 4
Plan Cache Hit Ratio : 63.64%

I'm seeing something similar with Studio 1.13.0/Stardog 7.0.2

I can right click on the database and click "Take offline" and the database is successfully taken offline but when I right click and select "Bring Online" I get the error "Invalid database state. The database is offline (internal server error)"

The rocker button next to the label "Database status: Offline" will successfully online the database.

Can you try rocker button and see if you can online the database that way?

It's probably related to this report against 1.12.0 but it looks like the behaviour has slightly changed in 1.13.0

Sorry for the inconvenience here. We're investigating this issue and hope to have a fix pushed soon. Currently, we cannot reproduce this on Stardog 7.x, so we suspect that there is an issue at the intersection of Studio and Stardog 6.x.

Thanks for your patience while we look into this.

It looks like the issue I'm seeing with 7.0.2 is slightly different. I don't have any problem seeing the db properties and there isn't any discrepancy with the database online/offline state between stardog and studio.

Thanks, everyone, for the reports. We've located this issue and have pushed a fix for it. We will let you all know when the updated version of Studio is available (likely within about 30 minutes).


Please could you update the Stardog Studio release notes at the same time you make a new release?

There's a been a lot of confusion here over the last 24 hours because Stardog Studio clients have spontaneously updated to v1.13.0 and have stopped working correctly with Stardog server, which was made more confusing because the latest official release according to the release notes page is v1.12.0.

Because auto-updating is causing us problems - it would be desirable if there was a downgrade or rollback path available. For example, our team would like to downgrade to Stardog Studio v1.12.0 today, whilst we wait for further releases to try out, but there doesn't seem to be a facility to do that.

Is there preference config key to disable auto-updating? Perhaps this is something that we've missed.

Regardless, I look forward to today's release.

Hi Scott - Yes, we will get the 1.13 release notes up soon and will have them more tightly coupled with code releases going forward.

There is not currently a way to downgrade but it's something we've discussed and we will add your +1 to the idea.

1 Like

Perhaps something like what iTerm2 for OSX does? It says something like "There's a newer version. Would you like to upgrade...Now/Later?"

That way you'd get a notification that there was a newer version and you lacked impulse control you could upgrade immediately or if you were the more sceptical type you could go off and pour over the release notes before reluctantly upgrading.

We will let you all know when the updated version of Studio is available (likely within about 30 minutes).

Following up on this: Studio v1.13.1 should now be available, and it should resolve the issues mentioned in this thread regarding offline DBs. The release notes have also been updated both on our website and inside of Studio itself. You'll of course need to restart Studio to get it to ping for updates.

Thanks for your patience and your feedback. Please let us know if the issue persists.


Thanks to the Stardog team for jumping on this so quickly on a Friday.

Another +1 to Scott's remarks. I'd like to see both a way to configure turning off auto updates and the ability to roll back if needed. I also prefer the ability to confirm the update before proceeding.

I'm still sitting at version 1.13.0 so I will let you know when the update arrives and I've confirmed the fix.


Studio 1.13.1 looks good with Stardog 7.0.2

I'm still at 1.13.0. I've closed and restarted Studio multiple times. Is there something else I can do to pull the update?

I pulled a new docker image. I'm not sure if there's a way to force the autoupdate but you can always download it again from https://www.stardog.com/studio/ . I just checked and it's downloading 1.13.1

The installer for windows is still pulling 1.13.0 as of 15:32pm Eastern. I'm not using Docker for the installs yet. I plan to switch over to Docker installs when I move to Stardog 7.x in the near future.

Stardog : Please add a "Check for Updates" option in Studio when you switch over from auto updates. :slight_smile:

I just auto-pulled 1.13.1 with Stardog on OSX so hopefully it will be working for you as well.

The impact of this issue just increased for me (Sunday morning.)

Studio 1.13.0 is still being pushed and it has now impacted the server setups for the upcoming PhUSE Linked Data Workshop sessions. I was on one of the PhUSE servers this morning testing configuration and Studio auto-updated to 1.13.0. The problems in this release mean students will be unable to follow the instructions in the exercises I have prepared, and I am currently unable to test and confirm the servers.

Please facilitate the push of 1.13.1. Thankfully we've caught this now and not next week.



Is downloading it from https://www.stardog.com/studio/ an option? I don't have access to a windows machine but the Linux binary is 1.13.1.

Is there possibly a permission issue where the user running Studio doesn't have permission to update the installed files?

You can try taking a look at the Studio logs to see if there is anything in there that might indicate why it's not updating. The Studio logs should be located at USERPROFILE%\AppData\Roaming\Stardog Studio\log.log

I don't know if it's not updating because 1.13.1 for windows isn't available or because there is a problem with your particular installation.

Tim, thanks for letting us know about this (and Zachary, thanks for trying to debug). I went ahead and looked at our build pipeline for Windows (which had indicated a successful build and release on Friday for v1.13.1) and discovered that the "code signing" step in the deployment failed for some reason. The CI pipeline did not register this as a failure, which is why it wasn't apparent until now (so, thanks again for the report!). I'm not sure why the failure occurred, as our Windows code signing certificate is still valid and should "just work." I've re-triggered the build to see if it will just right itself on its own. If that doesn't work, we'll investigate this further.

Thanks, and sorry for the inconvenience.