NoSuchMethodError on createLiteral starting server

Installation was running fine with Stardog 5 Beta, I then downloaded Stardog 5 RC-1, stopped the server, and replaced the software directory (home directory was separate and not changed except for copying in new license). Now starting server gives the error below.
I obviously screwed something up since copying back the Beta files causes the same error. Or possibly someone else installed an incompatible library but the stack seems to involve only Stardog classes:

Exception in thread “main” java.lang.NoSuchMethodError: com.complexible.common.rdf.model.StardogValueFactory.createLiteral(JLcom/complexible/common/rdf/model/StardogValueFactory$Datatype;)Lorg/openrdf/model/Literal;
at com.complexible.stardog.index.dictionary.ValueInliner$IntegerInliner.extract(ValueInliner.java:428)
at com.complexible.stardog.index.dictionary.ValueInliner.extract(ValueInliner.java:108)
at com.complexible.stardog.index.dictionary.InliningMappingDictionary.getValue(InliningMappingDictionary.java:91)
at com.complexible.stardog.index.dictionary.DelegatingMappingDictionary.getValue(DelegatingMappingDictionary.java:67)
at com.complexible.stardog.security.index.SecurityIndexes.getSecurityIndexVersion(SecurityIndexes.java:176)
at com.complexible.stardog.security.index.SecurityIndexes.initialize(SecurityIndexes.java:83)
at com.complexible.stardog.security.index.IndexSystemSecurityManagerFactory.create(IndexSystemSecurityManagerFactory.java:58)
at com.complexible.stardog.BaseStardogModule.getSystemSecurityManager(BaseStardogModule.java:202)
at com.complexible.stardog.BaseStardogModule$$FastClassByGuice$$920e5968.invoke()
at com.google.inject.internal.ProviderMethod$FastClassProviderMethod.doProvision(ProviderMethod.java:272)
at com.google.inject.internal.ProviderMethod.get(ProviderMethod.java:172)
at com.google.inject.internal.ProviderInternalFactory.provision(ProviderInternalFactory.java:81)
at com.google.inject.internal.InternalFactoryToInitializableAdapter.provision(InternalFactoryToInitializableAdapter.java:53)
at com.google.inject.internal.ProviderInternalFactory.circularGet(ProviderInternalFactory.java:61)
at com.google.inject.internal.InternalFactoryToInitializableAdapter.get(InternalFactoryToInitializableAdapter.java:45)
at com.google.inject.internal.ProviderToInternalFactoryAdapter$1.call(ProviderToInternalFactoryAdapter.java:46)
at com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1103)
at com.google.inject.internal.ProviderToInternalFactoryAdapter.get(ProviderToInternalFactoryAdapter.java:40)
at com.google.inject.internal.SingletonScope$1.get(SingletonScope.java:145)
at com.google.inject.internal.InternalFactoryToProviderAdapter.get(InternalFactoryToProviderAdapter.java:41)
at com.google.inject.internal.SingleParameterInjector.inject(SingleParameterInjector.java:38)
at com.google.inject.internal.SingleParameterInjector.getAll(SingleParameterInjector.java:62)
at com.google.inject.internal.ConstructorInjector.provision(ConstructorInjector.java:104)
at com.google.inject.internal.ConstructorInjector.construct(ConstructorInjector.java:85)
at com.google.inject.internal.ConstructorBindingImpl$Factory.get(ConstructorBindingImpl.java:267)
at com.google.inject.internal.FactoryProxy.get(FactoryProxy.java:56)
at com.google.inject.internal.InjectorImpl$2$1.call(InjectorImpl.java:1016)
at com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1103)
at com.google.inject.internal.InjectorImpl$2.get(InjectorImpl.java:1012)
at com.google.inject.multibindings.Multibinder$RealMultibinder.get(Multibinder.java:375)
at com.google.inject.multibindings.Multibinder$RealMultibinder.get(Multibinder.java:258)
at com.google.inject.internal.ProviderInternalFactory.provision(ProviderInternalFactory.java:81)
at com.google.inject.internal.InternalFactoryToInitializableAdapter.provision(InternalFactoryToInitializableAdapter.java:53)
at com.google.inject.internal.ProviderInternalFactory.circularGet(ProviderInternalFactory.java:61)
at com.google.inject.internal.InternalFactoryToInitializableAdapter.get(InternalFactoryToInitializableAdapter.java:45)
at com.google.inject.internal.InjectorImpl$2$1.call(InjectorImpl.java:1016)
at com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1103)
at com.google.inject.internal.InjectorImpl$2.get(InjectorImpl.java:1012)
at com.google.inject.spi.ProviderLookup$1.get(ProviderLookup.java:104)
at com.google.inject.spi.ProviderLookup$1.get(ProviderLookup.java:104)
at com.google.inject.internal.ProviderMethod.get(ProviderMethod.java:167)
at com.google.inject.internal.ProviderInternalFactory.provision(ProviderInternalFactory.java:81)
at com.google.inject.internal.InternalFactoryToInitializableAdapter.provision(InternalFactoryToInitializableAdapter.java:53)
at com.google.inject.internal.ProviderInternalFactory.circularGet(ProviderInternalFactory.java:61)
at com.google.inject.internal.InternalFactoryToInitializableAdapter.get(InternalFactoryToInitializableAdapter.java:45)
at com.google.inject.internal.ProviderToInternalFactoryAdapter$1.call(ProviderToInternalFactoryAdapter.java:46)
at com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1103)
at com.google.inject.internal.ProviderToInternalFactoryAdapter.get(ProviderToInternalFactoryAdapter.java:40)
at com.google.inject.internal.SingletonScope$1.get(SingletonScope.java:145)
at com.google.inject.internal.InternalFactoryToProviderAdapter.get(InternalFactoryToProviderAdapter.java:41)
at com.google.inject.internal.SingleParameterInjector.inject(SingleParameterInjector.java:38)
at com.google.inject.internal.SingleParameterInjector.getAll(SingleParameterInjector.java:62)
at com.google.inject.internal.ConstructorInjector.provision(ConstructorInjector.java:104)
at com.google.inject.internal.ConstructorInjector.construct(ConstructorInjector.java:85)
at com.google.inject.internal.ConstructorBindingImpl$Factory.get(ConstructorBindingImpl.java:267)
at com.google.inject.internal.ProviderToInternalFactoryAdapter$1.call(ProviderToInternalFactoryAdapter.java:46)
at com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1103)
at com.google.inject.internal.ProviderToInternalFactoryAdapter.get(ProviderToInternalFactoryAdapter.java:40)
at com.google.inject.internal.SingletonScope$1.get(SingletonScope.java:145)
at com.google.inject.internal.InternalFactoryToProviderAdapter.get(InternalFactoryToProviderAdapter.java:41)
at com.google.inject.internal.FactoryProxy.get(FactoryProxy.java:56)
at com.google.inject.internal.InjectorImpl$2$1.call(InjectorImpl.java:1016)
at com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1092)
at com.google.inject.internal.InjectorImpl$2.get(InjectorImpl.java:1012)
at com.google.inject.internal.InjectorImpl.getInstance(InjectorImpl.java:1051)
at com.complexible.stardog.Stardog.initKernel(Stardog.java:218)
at com.complexible.stardog.Stardog.(Stardog.java:211)
at com.complexible.stardog.Stardog.(Stardog.java:65)
at com.complexible.stardog.Stardog$StardogBuilder.create(Stardog.java:560)
at com.complexible.stardog.cli.impl.ServerStart.call(ServerStart.java:144)
at com.complexible.stardog.cli.impl.ServerStart.call(ServerStart.java:43)
at com.complexible.stardog.cli.CLIBase.execute(CLIBase.java:55)
at com.complexible.stardog.cli.admin.CLI.main(CLI.java:182)

After posting this I tried starting the server in the directory where I had unzipped the files and it ran fine. I used cp -R to copy from those directories to the official installation directory. And even deleted the subdirectories first to ensure a clean slate.

So is everything working correctly or are you still having trouble?

I’m up and running with the directory under my user where I unzipped to, but would eventually like to get it working in the official directory, so am curious what this error is a symptom of - to help me track down the issue.

I’m still a little unclear about what exactly you’ve done. If you include a more detailed description of what exactly you’ve done and what problems you might be experiencing I could provide better feedback.

That being said, there is no official installation location other than the location pointed to by the STARDOG_HOME evironment variable. You are free to place it where ever you like. It sounds like you may not have it set. Are you running on Linux or Windows?

I’m running on the Amazon Linux (on AWS).
I’m setting STARDOG_HOME on the command line when trying to start server as follows (after adding /opt/stardog/bin to the PATH); and the devdb directory does contain the license.
stardog-admin server start --port 5860 --home /var/opt/stardog/devdb
This command line gves the error with /opt/stardog/bin on the PATH
When I use the identical command line but with the unzip location ~/stardog-5.0-RC1/bin on the path it all works fine.

I’m sure it’s something silly I’ve done so please don’t waste time on this - I was just looking for any pointers in case this symptom was a well-known indicator of a specific configuration/missing file issue.

I think you’re almost there. I’m not sure where the devdb directory is coming from but if you start with a clean install, removing everything under /opt/stardog

unzip the Stardog distribution unzip stardog-5.0-RC1.zip and move the resulting directory to the opt directory mv stardog-5.0-RC1 /opt/stardog. Add STARDOG_HOME and modify the PATH in your environment by either running export STARDOG_HOME=/opt/stardog followed by PATH=$PATH:$STARDOG_HOME/bin which will set it for just that console session. To make it permanent add it to either the .bash_profile of the user you intend to run Stardog as or you can add it globally by creating and adding it to the file /etc/profile.d/stardog.sh

Next you’ll need to log out and log back in if you added it to your profile for it to be picked up. Start Stardog with `stardog-admin server start --port 5860. No need for the --home option because it will be picked up from the env variable.

Stardog does everything it can to give you sensible defaults and will default STARDOG_HOME to the current directory so if you just moved the distribution to /opt/stardog and didn’t do anything else you should be able to cd /opt/stardog followed by ./bin/stardog-admin server start --port 5860 and everything should start normally. Setting the PATH is just a convenience so you don’t have to add the full path to stardog-admin and STARDOG_HOME so you don’t have to execute it from the Stardog distribution directory.

Hopefully this gets you going. Let me know if you have any more problems.

Hi,

We actually have an internal Amazon Linux box on EC2 running stardog. I’ll quickly cover here how we got that running. Most of it has already been touched on by Zach, but I’ll try to be complete:

  • Create a stardog user to run the server as
  • Make your STARDOG_HOME at /var/opt/stardog, putting your license in there
    • Ensure that this directory is owned by stardog:stardog
  • sudo unzip ~/stardog-5.0-RC1.zip -d /usr/share
    • Again, /usr/share needs to be owned by stardog:stardog
  • Remove any existing /opt/stardog
  • Create a symlink at /opt/stardog
    • sudo ln -s /usr/share/stardog-5.0-RC1 /opt/stardog
    • sudo chown -R stardog:stardog /opt/stardog
  • Now you can put /opt/stardog/bin in your PATH or .bash_profile (or /etc/profile.d/stardog.sh as Zach said)

At that point you should be able to start the server with your stardog-admin command, or even use the bin/stardog-server script with something like httpd to have the system manage it.

I put together a spec file a while ago for building an rpm for installing Stardog located at https://github.com/semantalytics/stardog-rpm . It’s not officially supported so caveat emptor

I’ve also put it on my to-do list to do something similar for deb files for all the Ubuntu/Debian folks. Anyone expressing interest gets it bumped up the list :wink:

Thanks I repeated what I thought I did and it all worked fine this time round. I think I probably had not cleared out the previous directories fully.
Not sure if it’s best practice but FWIW I departed from your advice in one main way:

  • I didn’t want to set FIBO_HOME since I want to start different servers on different ports for different environments all using the same database name e.g. we have dev, test and prod directories each with a database called fibo and accessed via different ports. Hence the --home parameter is pretty useful.
    BTW, as feedback, it seems a bit odd to have to copy the license to each one of these data directories - it seems more appropriate for the license to be in the software installation directory.

Glad to hear you got everything working. No problem departing from the recommendations. It’s just a good place to start. The only comment I’d make about your setup is to be careful about your memory allocation. Memory is one of the most important resources for Stardog and you’re going to have to split it between three instances.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.