I am a beginner in openmrs developping. I work in a project in with we have download the openmrs core master in github and deploy it in a server an in a pc. We want the server and the pc to synchronize their data; the server will be the father and the pc the child.
The problem is when I install the sync module, I have the following error:
Error while trying to start module
Error while running sql: INSERT INTO scheduler_task_config (name, description, schedulable_class, start_time, start_time_pattern, repeat_interval, start_on_startup, started, created_by, date_created, changed_by, date_changed, uuid) VALUES ('Cleanup Old Sync Records', 'This task deletes old rows in the sync_record and sync_server_record tables. The default settings work on all servers, but for advanced users, you can change the properties to suit your needs.', 'org.openmrs.module.sync.scheduler.CleanupSyncTablesTask', '2009-12-18 17:26:31', 'MM/dd/yyyy HH:mm:ss', '604800', '1', '0', '1', '2009-12-18 17:28:39', null, null, 'd3122955-00d7-454c-b17f-e3f87206c74b') . Message: Duplicate entry 'd3122955-00d7-454c-b17f-e3f87206c74b' for key 'scheduler_task_config_uuid_index'
So I have look for a solution and one of them said that it is a problem of version. The version of my openmrs is 1.12.0 and in the downloading sync module page, it is specify that the version required is 1.9.0. I have supposed that it is the smallest version, otherwise openmrs 1.12 could not be synchronised. One other solution told me to check the version in global_property table and I do it and the problem stay.
Please, anyone of you, can he know how could I start sync module in openmrs 1.12.0? Thanks in advance.
An openmrs developper said to me that to his knowledge, he did not yet see an openmrs project with use sync module that has a version greater than 1.9. Base on that, and on the fact that in the mostly modules we talk of versions 1.7, 1.8, 1.9, I decided to come back to an openmrs core version 1.9.x and at the first try it works. The sync module started perfectly.
Related
I've been following the 5 min how to for setting up an htap databse with tidb_tispark and everything works until I get to the section Launch TiSpark. My first issue occurs when executing the line:
docker-compose exec tispark-master /opt/spark-2.1.1-bin-hadoop2.7/bin/spark-shell
But I got around that by modifying the spark version to the version I found inside the container:
docker-compose exec tispark-master /opt/spark-2.3.3-bin-hadoop2.7/bin/spark-shell
My second issue occurs when executing the three line block:
import org.apache.spark.sql.TiContext
val ti = new TiContext(spark)
ti.tidbMapDatabase("TPCH_001")
When I run the last statement I get the following output
scala> ti.tidbMapDatabase("TPCH_001")
2019-07-11 16:14:32 WARN General:96 - Plugin (Bundle) "org.datanucleus" is already registered. Ensure you dont have multiple JAR versions of the same plugin in the classpath. The URL "file:/opt/spark/jars/datanucleus-core-3.2.10.jar" is already registered, and you are trying to register an identical plugin located at URL "file:/opt/spark-2.3.3-bin-hadoop2.7/jars/datanucleus-core-3.2.10.jar."
2019-07-11 16:14:32 WARN General:96 - Plugin (Bundle) "org.datanucleus.api.jdo" is already registered. Ensure you dont have multiple JAR versions of the same plugin in the classpath. The URL "file:/opt/spark/jars/datanucleus-api-jdo-3.2.6.jar" is already registered, and you are trying to register an identical plugin located at URL "file:/opt/spark-2.3.3-bin-hadoop2.7/jars/datanucleus-api-jdo-3.2.6.jar."
2019-07-11 16:14:32 WARN General:96 - Plugin (Bundle) "org.datanucleus.store.rdbms" is already registered. Ensure you dont have multiple JAR versions of the same plugin in the classpath. The URL "file:/opt/spark/jars/datanucleus-rdbms-3.2.9.jar" is already registered, and you are trying to register an identical plugin located at URL "file:/opt/spark-2.3.3-bin-hadoop2.7/jars/datanucleus-rdbms-3.2.9.jar."
2019-07-11 16:14:36 WARN ObjectStore:568 - Failed to get database global_temp, returning NoSuchObjectException
This doesn't prevent me from running the query:
spark.sql("select * from nation").show(30);
But when I follow the further steps of the tutorial to modify the db from MySQL, the changes are not reflected immediately in Spark. Furthermore, at some point in the future (I believe > 5 minutes later), the row that was modified stops showing up in Spark SQL queries.
I'm rather new to this kind of setup and don't really know how to debug this issue. Searches for the warnings I received weren't illuminating.
I don't know if it's helpful but when I connect MySQL this is the server version I get:
Server version: 5.7.25-TiDB-v3.0.0-rc.1-309-g8c20289c7 MySQL Community Server (Apache License 2.0)
I'm one of the main dev of TiSpark. Sorry for your bad experience with it.
Due to my docker problem, I cannot directly reproduce your issue but it seems you hit one of the bug fixed recently.
https://github.com/pingcap/tispark/pull/862/files
The tutorial document is not quite up-to-date and points to an older version. That's why it didn't work with spark 2.1.1 as in tutorial. We will update it ASAP.
Newer version of TiSpark doesn't use tidbMapDatabase anymore but hooks with catalog directly instead. Method tidbMapDatabase remains for backward compatibility. Unfortunately, the tidbMapDatabase had a bug（when we ported it from older version） that it retrieves timestamp for query only once you call the function. That causes TiSpark always uses old timestamp to do snapshot reading and newer data would never be seen by it.
In newer version of TiSpark (TiSpark 2.0+ with Spark 2.3+), databases and tables are directly hooked into catalog services and you can directly call
spark.sql("use TPCH_001").show
spark.sql("select * from nation").show
This should give you fresh data.
So try restart your Spark driver, just try the two lines of code above and see if it works.
Let me know if this fix your problem. On the other hand, we will check our docker image to make sure if it contains the fix already.
If things still get wrong, would you please help to run below code and let us know the version of TiSpark.
spark.sql("select ti_version()").show
Again, sorry for causing you trouble and thanks for trying.
EDIT
To address your comment:
The warning is due to spark itself will try to locate the database in its native catalog first and this will cause a Failed to get warning. But the failover process will delegate the search to tispark and then behave correctly. So this warning can be ignored. It's recommended that add below lines to your log4j.properties in conf folder of your spark.
log4j.logger.org.apache.hadoop.hive.metastore.ObjectStore=ERROR
We will polish the docker tutorial image soon. Thank you so much for trying.
I have a service fabric application stuck in "Upgrading" mode.
The exception is:
Could not load type 'DB.IAddUser' from assembly 'DB' at
WebApi.Startup.ConfigureServices(IServiceCollection services)
My change was that of renaming the name space, from 'DB' to 'DB.Interfaces'.
This class is only used as a constructor dependency, and registered as such
Startup.cs
services.AddSingleton<IAddUser, AddUser>();
UserController.cs
private IAddUser addUser;
public UserController(IAddUser addUser){
this.addUser = addUser;
}
Why would this cause SF to get stuck?
Additionally, it only got stuck on the last upgrade domain, and not on the others.
I might be mistaken but if upgrade was successful on other upgrade domains then it is not code related issue.
Try to rollback the application upgrade and upgrade again:
Start-ServiceFabricApplicationRollback -ApplicationName fabric:/MyApp
documentation
It turns out that this had nothing to do with service fabric (as expected and as #SteppingRazor said).
The problem seems to be related to MSBuild/Azure devops build task, I had upgraded nuget package
Microsoft.VisualStudio.Azure.Fabric.MSBuild
from 1.6.7 to 1.6.8 and it seems that the build was still using older code (confirmed via a decompiler).
Reverting back to 1.6.7 solved the issue (albeit its just a workaround)
I use feathers for some months now and I already created and used several services. The app is generated with feather/cli command: 'feathers generate app'.
Today I tried to generate a new service with the usual command:
feathers generate service
only to get the error:
× This version of the generator will only work with Feathers Buzzard (v3) and up. Please runfeathers upgradefirst.
Fine. Run the upgrade. Got new error:
throw new Error('It looks like#feathersjs/feathersis already a dependency. I can not run the upgrade again.');
^
checked the version: is 3.9.0
Uninstalled/re-installed feathers/cli
Nothing works. Not sure what I broke as I did not (remember to) upgrade anything since a couple of days ago when I created the last service. Feathers was not updated in the last 4 months.
I tried googling my error but it seems like nobody else has this problem so it has to be something I've done.
Any suggestions?
LE: I have in package.json dependencies:
"#feathersjs/errors": "^3.3.6",
"#feathersjs/express": "^1.3.1",
"#feathersjs/feathers": "^3.3.1",
"#feathersjs/socketio": "^3.2.9",
"feathers-knex": "^5.0.7",
"feathers-memory": "^3.0.2",
"feathers-rest": "^1.8.1",
"feathers": "^2.2.4",```
This error will be shown if you still have the feathers module in your dependencies in your package.json. If #feathersjs/feathers is already included as well you can just remove the feathers dependency (after making sure it is not used anywhere else in your application which it shouldn't).
I'm seeing dozens of entries, daily, in my cgi_error_log file like this:
20151214T183710: www.example/index.php
Failed loading /usr/local/lib/ioncube/ioncube_loader_lin_5.2.so: /usr/local/lib/ioncube/ioncube_loader_lin_5.2.so: wrong ELF class: ELFCLASS32
Failed loading /usr/local/Zend/lib/ZendExtensionManager.so: /usr/local/Zend/lib/ZendExtensionManager.so: wrong ELF class: ELFCLASS32
I changed the URL in the error message because the site is not yet ready for the public and I don't want any links to the site or even text in posts like this laying around.
As the site is still in testing, these messages are coming from my accessing pages and all of the pages have loaded correctly.
What does this message mean? I have no clue other than that ioncube is some sort of PHP Encoder.
Could this have something to do with the 32bit version of ioncube being run on a 64bit system? I've found references to that sort of problem.
Did some more digging - could this be happening because the version of PHP on the server is not 5.2? Error about ioncube shows 4.2 in the file name.
The version I'm using on the server if 5.5. They have 5.3 and 5.6.
If they had 5.2 I'd give it a try but it is not available.
More digging - found this set in my php.ini file for all my sites.
[Zend]
zend_extension = /usr/local/lib/ioncube/ioncube_loader_lin_5.2.so
zend_extension_manager.optimizer=/usr/local/Zend/lib/Optimizer-3.2.0
zend_extension_manager.optimizer_ts=/usr/local/Zend/lib/Optimizer_TS-3.2.0
zend_optimizer.version=3.2.0
zend_extension=/usr/local/Zend/lib/ZendExtensionManager.so
zend_extension_ts=/usr/local/Zend/lib/ZendExtensionManager_TS.so
So - do I need to install newer versions of one or more of the items listed above?
If so - where do I start and can I do it myself or does the hosting company staff have to do it?
Does anyone know how to solve this Error on RAD Studio XE6 Delphi
If you take the sample app supplied by Embarcadero
FireDAC\Samples\Comp Layer\TFDConnection\DLL_Sharing and change the FDConnection to use a MySQL server instead, you get this error.
[FireDac][Phys][MySQL]-1101. Unsupported MySQL version [0]. Supported are client and server from v 3.20 to v6.2.
The connection in the exe works, using the MySQL server, but the sharing in the DLL does not.
Even though the steps in the FireDAC DLL_Sharing are followed..
Copy the file FireDAC.Phys.MySQLWrapper.pas (from source\data\firedac directory) to your project directory, edit the file, and look for the following three lines:
if (FVersion < mvMySQL032000) or (FVersion >= mvMySQL060200) then
FDException(OwningObj, [S_FD_LPhys, S_FD_MySQLId], er_FD_MySQLBadVersion,
[FVersion]);
Remove them (or place them in comments), and rebuild your project. Make sure that it uses the FireDAC.Phys.MySQLWrapper from your project directory (you may have to close and re-open the project to ensure it uses your local unit).
That way, you still won't be able to connect at design-time, but at least it will work at runtime.
Groetjes, Bob Swart
Use the "original" mysql libmysql.dll and its work fine ;)
the mariadb's libmysql.dll causes this error