I have developed a hybrid worklight app and everything is set up. Now my case is that I have a load balance and two clusters. These two clusters have been synchronized with only one WAR file. Due to some reason, we have a server java file in the WAR for sharing some global variables with worklight adapters.
The problem now is that these 2 clusters are working independently (will be redirected by the load balance). The global variables in the JAVA file inside their WAR will not be shared. How can we maintain only one set of global variable in this case?
Or is there any method for the JAVA to read the current cluster detail(for example cluster id or IP address) so that I can write logic to point to different properties in worklight.properties
[PS: not good at English. I will clarify more if you guys don't understand me]
What you actually need here is not to use static variables to share this information.
I suggest using Redis or Memcached (or some other free solution) to share information across the cluster.
A simpler solution (but less efficient) can be using an SQL database to store/load those shared properties. You can actually create a "configuration" adapter (SQL adapter) which will be called by the other adapters to read/write the configuration properties.
Related
I have some experience developing in the xs classical apps in the SAP Cloud platform neo evironment. And plan to migrate to xsadvanced in the cloud foundary landscape. I have a few fundamental doubts which sadly i could not get answers to even after reading the documentation.
If i understand correctly XSA is cloud foundary extented by SAP to support SAP HANA 2.0 as a service via the HDI Container, allowing the tradional xsjs to run as a node.js container and bunch of other SAP specefic serivces ?
the MTA (mutlti target application) development promoted by SAP looks neat however i have a few questions when it comes to working in a env where multiple developers work with the same MTA in the "dev" space for example.
the typical MTA is combined of a web module where the UI part resides , node module to hold the services and a db module that is the entire HDI container which holds tables,views and the actual data .
the developers dont work with WebIde and use VSS code and cf CLI.
Question 1 : if i want each developer to have an isolated MTA when developing , then each developer must push the same MTA app with a different name when he works with works for some feature development ? (preferably some feature brach that gets pushed as a new app) . every line of code change then needs a push to CF
Question 2: Pushing the app with the same schema name in MTA file creates a new schema for the second developer in the same HDI cointainer (i am not sure if this correct however this what i understand from : here
But the second schema will remain empty and many not contain data, do we then take care about data replication from schema 1 to schema 2. wont this explode the space usage ?
As i said, i did not find documentation about how multiple developers can work on the same MTA app in the shared space so any guidance will help
thank you
Multiple developers are able to work on the same MTA app, because of git functionality and different workspaces dedicated for each developer. More to that, you can even personally have even more that one workspace, which means you can have different features developed by yourself separately.
When you build your container or run your application in your space, each time get a unique schema name or application url, this means you can work independently.
A bit tricky part is when you want to join your commited code with other developers. Basically, it depends of how big your project is. If you have a large project, it's better to control merges using Code Review and Unit tests, or maybe you are in a small project and work on different files, which means you can merge your code easily to master branch by yourself.
I would like to have two separate Parse servers (configured with a different app ID) connect to the same mongodb, so they can see the same set of users, so that I can create 2 different apps that share the same userbase.
Is this something Parse would support? Are there any expected conflicts or config caveats? I was unable to find info about this on Parse's github..
thanks
There's nothing to do, besides setting the database URL option to the same value on both servers, and that your database is accessible from both servers.
I'm not sure why you would need two different applicationId's as you want the same data and likely, logic running on both apps.
No, Parse Server does not support sharing classes between applications.
What you could do is have one of the instances or maybe a third one handle authentication and store your user information. I am pretty sure this would mean you will have to manually set user info on your requests and objects to save on the other two instances.
Another option is for each of the instances have an afterSave hook on the user class that saves and updates the info at the other instance. This seems easier to do and maintain.
I would choose the second option.
My app consists of two containers: the app itself and a database. I'm planning to wrap the app into a chart, thus paving a way for easy reproducible deployment.
Apart from setting/reading environment envs (which helm+kubernetes seems to handle really well), part of app's configuration is:
making sure the database is pre-filled with special auxiliary data (e.g. admin user exists, some user role names required to create new users are there, etc.).
I like the idea of having readable yaml files hold the entire configuration in a human readable format. However at a glance it doesn't seem that helm in any way would help with this (DB records) kind of configuration.
That being said, what is the best place to put code/configuration ensuring that DB contains certain auxiliary records? A config yaml file? An container init script, written in bash?
You are right, Kubernetes or Helm cannot help with preparing your pre-filled database records/schema.
You should probably have your application initialize those pre-filled data. If you don't want to put this logic into your application, you can ship an initialization script and configure an init container with Kubernetes.
Kubernetes makes sure every time your application container is restarted, the init container runs first. In the init container, you can execute a bash/python/... script that makes sure the records you want are there.
In my project I am trying to do the setting where in I can update the dynamic properties in the server/application without even restarting it.
We face this problem that whenever we have to update or change some properties which are dynamic in nature, then every time we have to restart the server/application and this results in unavailability of the server for that time stamp.
I have already found one tool Archaius-ZooKeeper to set it.https://github.com/Netflix/archaius/
We are trying to do it for JBoss servers where we use war file to deploy on server.
Please suggest are there any other method or tool or technology that can be used to set it.
Thanks in advance.
You could consider jRebel, allows you to redeploy your app without any downtime, then you can use jRebel Remoting to redeploy from eclipse to a remote server
You may use Zookeeper. You have to create a Znode and add the properties in the Znode. All your servers/applications should read from this Znode and also put an watch on this Znode for data changes.
Alternately, you may use a database to store the properties along with their modification time. Whenever you change the value of a property, the corresponding modification time is changed. All your applications/servers keep pulling the delta at some intervals (may be 2 secs/ 5 secs etc.).
Or you may have the properties hosted on a web server, or on NFS, or on some distributed cache etc. All your applications/servers keep reading it at some intervals for detecting any changes.
You can use Spring Cloud Zookeeper. I shared a little example here.
Im looking for an alternate way to store "environment variable" in the current environment that I'm currently working on. (IBM WebSphere)
We are currently in a situation where we have to many property files that it has become difficult to manage.
Im looking for a way to consolidate all these properties into a central place that is easily administered by the admin team.
Some of the options I have explored include :
Storing properties in the database.
Consolidation into a single text file
Any other suggestions would be most welcome!
#Nic Willemse: you may want to use jndi namespace binding provided by websphere...go to admin console-> environment and specify new namespace binding key,value pair.
It depends on the kinds of properties you want to be edited by the admin team. Usually for us those are the items that should be managed as JEE Resources in web.xml, which allows them to be configured in standard locations in the WebSphere admin console.
We keep most of our property files in c:\cfg\<>\
Makes it easy to have different configurations for different servers.