I've been running usergrid-stack commit 08f26cc865c96185d11990bf622730beff59971a for a while using the built-in cassandra db.
I need to migrate to another server and thought I'd take the chance to update.
I tried copying the folder standalone/target/tmp to the new installation but doing so gives me the error below.
null; Can't construct a java object for tag:yaml.org,2002:org.apache.cassandra.config.Config; exception=Cannot create property=hinted_handoff_throttle_delay_in_ms for JavaBean=org.apache.cassandra.config.Config#6b7b9f29; Unable to find property 'hinted_handoff_throttle_delay_in_ms' on class: org.apache.cassandra.config.Config
Invalid yaml; unable to start server. See log for stacktrace.
Is there any way to migrate the db to a newer version?
If not, is there at least a way to migrate the db using the old version?
iirc hinted_handoff_throttle_delay_in_ms is a setting from Cassandra 1.1 which was removed in Cassandra 1.2 so you might need to edit the conf file (cassandra.yaml) and remove this setting.
Related
I have installed thingsboard on Linux. initially it was using Cassandra database, but now i have changed it to postgresql. But the issue is that both the thingsboard and postgresql are not running. The only error in postgresql log file is "Incomplete startup Packet" and thingsboard log file has "all hosts tried query failed(tried: /127.0.0.1:9042)" error.
I have stopped the Cassandra service and also configured the thingsboard.yml file to use postgresql database.
How to fix this issue.
Without knowing more log details, I suggest to fresh install a new ThingsBoard+PostgreSQL instance and migrate the Cassandra db to the new instance using the REST API feature of ThingsBoard, this way you avoid the corruption of PostgreSQL.
The steps are:
Install a new instance of ThingsBoard and PostgresSQL
Retrieve data via REST API from old instance
Send data via MQTT or other supported protocols to new instance
You can find a script which does this automatically in this repo.
I am not sure but In my experience that you should check up as below.
install PostgreSQL on your server.
create database like thingsboard inside postgreSQL.
configure for using PostgreSQL in thingsboard.yml
Run installation script again
https://thingsboard.io/docs/user-guide/install/linux/#memory-update-for-slow-machines-1gb-of-ram
I published my app on play store and I have made an update that may cause the older one to crash due to some database structure changes that I have made and I have had a hell of hustle trying to automate DB migration upon installation. So I want the to completely auto-uninstall the old one from users phone before new one is installed during update as an easy solution. Is there a way I can include such configurations?
No, there is no way to force uninstallation before installation. But it sounds like you could just delete your DB on upgrade using SQLiteOpenHelper
If you use GreenDAO
you can use the schema version
Schema schema = new Schema(, "greendao");
when increasing the schema version GreenDAO will empty your DB and update the schema, and then you can repopulate it from the server (if applicable)
I'm trying to look at using the Stratios Lucene index plugin (on Windows)installation of Cassandra (Datastax v3.5) but can't get Cassandra to recognize it.
I'm aware that you must use the corresponding version to Cassandra and have tried with 3.0.5 & 3.5 but both with the same results. The service is stopped, the index .jar file is copied to the lib directory & then the service is restarted. Then using CQLSH, I can create the relevant keyspace & table (as described in the Stratio documentation) but when attempting to create the index it fails with the following message:
Query invalid because of configuration issue: message="Unable to find custom indexer class 'com.stratio.cassandra.lucene.Index'"
https://github.com/Stratio/cassandra-lucene-index/tree/branch-3.5
Does anyone have any idea how to get this implemented & working?
Is there a central forum or a point of contact for Stratios Lucene index support?
This resource https://github.com/Stratio/cassandra-lucene-index/issues/118#issuecomment-211796434 suggests that only open source Apache Cassandra is officially supported by this plugin. It might work with DSE, might not. I checked 3.5.0 version works on Linux with Apache Cassandra but does not work on Windows with DSE :( According to Datastax docs, it should support custom secondary indexes. So, it might be the plugin does not run on Windows?
I have an app in appstore and in which I had setup my magicalrecord using setupCoreDataStack method. I have since then versioned the data model and added an attribute to an existing entity. Now when I use setupCoreDataStackWithAutoMigratingSqliteStoreNamed to perform lightweight migration over the released app, the debug app opens with no data.
The new version of data model is currently selected with the green tickmark in xcode and is based on the old data model. The default value for the new attribute is set. If I install released version again without deleting the debug app from the device then I see the old data, means the old data is never wiped off (which is good), it's just not shown after setting up new version of the model and performing magicalrecord lightweight migration. What am I missing here?
There is no error in debugger while loading new debug version over existing released version. The filemerge diff performed on the contents of the data model versions only show the addition of the new attribute.
Any insight into this problem or pointers will help!
Huh, read somewhere that you can't auto-migrate if the datastore was not setup as an auto-migrate store in the first place. Someone suggested doing it over multiple releases. So assuming that was true, I tried
[MagicalRecord setupAutoMigratingCoreDataStack];
right before
[MagicalRecord setupCoreDataStackWithAutoMigratingSqliteStoreNamed:#"XYZ"];
and it worked.
Anyone else with same problem, no need to delete data store and create new with setupAutoMigratingCoreDataStack or try manual migration. Just setup as auto-migrate store and do auto-migration one after another in the same build. Hope it works for your too!
I have a XPage application where I use JavaMail in one of my managed beans. Currently I have added the jar-file C:\Programme\IBM\Notes\framework\shared\eclipse\plugins\com.ibm.designer.lib.javamail_9.0.0.20130301-1431\lib\mail.jarto the build-path of the manged bean. This works well. But now I want to use a newer version of JavaMail as the Domino server uses version 1.3 but I need version 1.4.x.
I have downloaded the new JavaMail jar-files from Oracle. In Domino Designer (version 9) I add this jar-file to the new design element "Code / Jars" and remove the old jar-files from the build path.
My managed bean is still compiling and running as desired, but if I check the version the bean is using it reports still version 1.3. To check the version number I use the debug property of JavaMail and it's reporting version 1.3 to the domino server console.
Is there a way to tell the domino server to use the jar-files in the application (i.e. the nsf) and not his own? Is there another approach to update the JavaMail version?
The reason I want to use a newer version of JavaMail is as follows: I want to read mails from an imap server with ssl. To avoid the problem of importing ssl-certificates I simply want to trust all hosts. This can be be done via MailSSLSocketFactory, but this is only available since version 1.4.2. Therefore I want to use a newer version of JavaMail.
Another reason I want to use a newer version is as follows: the method "getSortedMessages" of "IMAPFolder" is only available since version 1.4.4. (and so are some other features of JavaMail).
This may be a little too late for you... I think the right approach may be to include the jar file as an OSGi plugin.
I have spent some time to figure out how to do that - and recently succeeded :-) I have described the steps to perform to make this work in two articles. The first is about wrapping a JAR into a plug-in: http://www.dalsgaard-data.eu/blog/wrap-an-existing-jar-file-into-a-plug-in/ - the second is about deployment (and there is a link in the first one).
/John
You can solve the problem by creating an OSGi plug-in that supersedes the one that sports the JavaMail library: com.ibm.designer.lib.javamail.
In order to do that do the following:
Create an OSGi plugin whose id is com.ibm.designer.lib.javamail (Dalsgaard's tutorial on how to do it)
Set its version to a higher number than the one the Domino server is shipped with (to know the version type tell http osgi ss com.ibm.designer.lib.javamail). As of now using 9.0.1.qualifier should be fine
Deploy the plugin either through an update site or by directly copying it under the domino\workspace\applications\eclipse\plugins folder.
Restart the HTTP service. The higher version - the one you created - will now be used
I've got the same problem here, but found a solution. Be warned, this is not the best answer but it will work. Simply download the latest javamail jar here and rename the jar file to 'mail.jar'. Just replace the current file in IBM\Notes\framework\shared\eclipse\plugins\com.ibm.designer.lib.javamail_9.0.0.20130301-1431\lib\mail.jar with this file. Quit the http task and restart it. The code will now work with the latest version.