I want to use ehcacheas distributed ehcache.By distributed i mean i have number of appserver each having its own ehcache and if i put/update a object in one appserver cache all other caches(in other app servers) must automtically synchronize /update.
Now i dont want the address(hostname) of all other caches to be hardcoded in some config.
Because i can deploy my code in multiple boxes and new boxes can be added at any time and i dont want to modify the config file in all machines.
Can i pull the config file remotely?
Can i add list of servers in form of ip range? or network host class?
Consider using Terracotta if you don't want to implement it by your own. You can find a sample here.
Related
I would like to know if I can start a ignite cache from java client . I am using Cassandra as the persistence store and use POJO configurations to work with the cache and Cassandra. With out providing any named cache configuration in server side is it possible ?
Please share your thoughts.
Cache itself can be dynamically started using Ignite#createCache method. However, classes that are required for this cache need to be deployed explicitly in advance, before servers are started.
In your case you will have to deploy POJO classes because they are currently required by Cassandra store. You will be able to skip this step though after this ticket is implemented: https://issues.apache.org/jira/browse/IGNITE-5270
In my project, I am using jboss 4.0 and tomcat 6.0 servers,
and have a Defaultconstant.java file which is not a servlet class (i.e Separate entity class)
Values of DefaultConstant.java are stored as static variables and written in static block.
When i starts my jboss server, Defaultconstant.java file is getting loaded with all required values and I'm storing it in a map.
When i run my tomcat server.
Same file is gets loaded for second time and **it creates another map for storing the Tomcat initialised values.
My Required output is:
I need to hold those map values and should not allow the map to reload once again during tomcat startup.
Use a System property to define a path where Defaultconstant can save/load it's data.
Depending on how Defaultconstant works, you can either save the data when it doesn't change anymore or you can use a ServletContextListener to notify the class when the app server is shut down.
EDIT Java offers no simple way to share data between processes. So when Tomcat starts, you need a way to tell the JBoss server "hey, I also need the values". There are several options:
You can save the values to a file from JBoss and read the file in Tomcat. That will give you a copy of the values (-> doesn't help if you want to be able to pass changes from Tomcat back to JBoss).
Create a web service in JBoss that Tomcat uses during startup to ask for the values.
Store the values in a database and configure the same database connector for both web servers. That way, Defaultconstant can read and write the values to the same shared storage.
I want to be able to deploy my app using ANT to Tomcat.
I don't want the process to be any different for dev and prod. However the two use different databases i.e. myapp and myapp-dev
How can I make this happen? Can I store a variable in the different tomcat containers and make the application call the name of the database from Tomcat.
Or if what I am asking is ridiculous what is the generally accepted way to achieve deploying to dev and prod with the same process.
The generic way is to put the configuration string in a JNDI entry.
If JNDI is not a possible solution, then a property file in the right location (so it shows up in the classpath of the WAR files) is also useful, but needs careful documentation.
Have you considered letting the web container manage the database connection pool, so you only need a single one pr container, which then can be retrieved through JNDI?
Is there a way to find all nodes belonging to the cluster of the web-application? I know on JBoss i can use HAServiceMBeanSupport to get information about all nodes(hostname, IP-adress), but how can I achieve something similar on Tomcat, WebSpere, Glassfish, Oracle AS, Jetty, WebLogic?
(Best would be an interface which works for all of them)
There is no standard drop-in solution for what you are asking for.
Technically it can be achieved in many ways - both within java ecosystem and outside e.g. Jgroups cluster forming, Zookeeper or simple Redis or other K/V server where each server instance would register upon startup and subscribe for changes in the cluster group.
The support and required effort will vary though. The general approach would be to use some startup hook e.g. Servlet container initialization or EJB #Startup #Singleton to contact the topology discovery service(your redis server for example), provide the info about your instance and query info about the other instances already active. If you need leader election, you can use many algorithms, e.g. first come-first serve basis, or based on voting. Then you need to subscribe and actively listen for changes in topology, and possibly provide some kind of health metric - e.g. periodically let others know, that your instance is still active
On a general note, can you elaborate why would your app need to have the knowledge about other instances of the same type? Do you need Master election or HA cluster-wide singleton functionality? The best practice for building stable scalable solutions is to keep the app stateless and unaware of the scaling details.
Functions, that need to be only executed in sequence or on a single node at the time, could be extracted into a dedicated service e.g. batch job service, scheduler service etc.
Most JEE server vendors offer some custom solution for this e.g. JBoss HASingleton service, or HA singleton deployment(app will always run only on a single instance in the cluster) which also takes care of failover.
As far as I know, it depends of the capabilities of your Applicationserver.
There is no "standardway" to do this.
You can try the following:
The class ServletContextListener has two methods. You can calculate the hostname and the IP-Adress(es) within the create method, and delete the node in the destroy method.
This way has problems during a VM-crash the destroy-method will not be called, for instance.
EDIT:
Does your software need a Database? If so, all clusternodes have to use the same database instance. If your app is deployed without a cluster it uses a "private" database. You need a shared DB:
Table: NODES
HOST | IP
as1.cluster | < ip >
as2.cluster | < ip2 >
If only onne line inserted to that DB, there is no cluster.
But this table may be corrupted, if a node crashes and does not remove its entry from this Table.
I have a set of EJBs and other Java classes which need to be configured differently based on the system environment in which they are deployed: production, test, or lab. The configuration information includes stuff like URLs and database connection information.
We'd like to deploy the same exact product (EAR file) in each environment, and have the code then figure out where it is and what its configuration should be, without having to reach out to each deployment server in each environment to make changes.
What is the best way to configure all these components in a centralized, reliable, easy-to-maintain fashion?
Thanks for your thoughts.
The best, IMHO, is to use JNDI entries.
You may have to recode some parts of your application in order to use theses entries instead of plain vars, but with this setup:
Configuration is server-independant: each vendor provides its own implementation, but spec is a standard.
In a clustered environment, config can be persisted in a cluster-wide JNDI tree (see JBoss)
Configuration can be changed thru webadmin without restarting server.
How database connection pool information is stored / configured depends on the app server vendor. Put other variable stuff in property files on the classpath.
If you are deploying the exact same EAR to three different instances of a certain container than you will have to edit the deployment settings as there is no way that the deployment process could have any idea about which one of your three versions you would like to use at a particular deployment.
Deployment settings should go into JNDI entries as Piere-Yves said above.
If I were you, I would have my deployment-script (Ant?) properly populate the JNDI entries depending upon which environment you are deploying to.