I'm currently leveraging the features in Spring Boot Admin that allow changing log levels and clearing caches. Best as I can tell, one is able to change the log levels for all instances at once, but the caches seem to only affect a single instance.
Is there a configuration option that allows for clearing the cache for all instances with a single click? If not is this something that could added via custom view?
We are not currently leveraging a centralized cache solution such as Redis so I think being able to clear the cache for an individual instance and all instances would be very helpful.
Thanks in advance for your time.
As of Spring Boot Admin version 2.7.5 this appears to be working.
The "Instance" button on the page now toggles to "Application" if clicked upon. This allows using clearing the cache across all instances.
At the time of my original question I was on 2.7.1. Not sure if there was a bug or if this feature wasn't implemented yet in this version.
Related
I am using eclipseLink JPA and i am using same db for two different EJB applications deployed in two different servers. I am getting concurrency issues due to JPA cache if other application is doing some modification on the same object. Is there any way i can manage this concurrency issues. Using native query for db operations is not an option. I am using oracle db and glassfish server. is there any solution available for this.
Let me explain why you have issues:
Imagine you have cached data for object. So the first application will work with that cached data and there are no need to this application to go to database (as it already have the value in memory). It can upgrade that cached data if you will perform another modifying query on the same entityManager. It in no way can know that the other application changed state of your data.
So isolation level won't help as there will be no read query from first application as it already have cached value. And as far as entityManager know is only the operations from that same manager. It have no way to know about another entityManager on different application.
The solution is to not to cache. Or you can configure external cache as your second level cache which you can evict from both applications (like hazelcast cache for example).
I'm using Spring Data for Neo4j and MongoDB, I find it awesome, but now I just found out about the embedded and not embedded DB stuff.
Here's my situation :
Using Spring Data with the annotations, repositories, templates and thinking that I just need to change the DB address to make it work elsewhere.
My questions :
1) I don't even understand what they mean by embedded vs non embedded (on the same machine vs on a distant machine ?)
2) Do I have to change all the work I've done to make it work with a 'non embedded' DB ?
What I wan't to do is to deploy my Spring Boot app that is using Neo4j to Heroku or CloudFoundry and use Graphen (Neo4j paas) for the DB. But when I saw all this story about Spring Data working only for embedded, I just lost all the hope and happiness I had when building my app.
3) If 2) is Yes, is it an easy transition ? is there a lot of things to change ?
EDIT :
Here's what I'm talking about :
http://inserpio.wordpress.com/2014/04/30/extending-the-neo4j-server-with-spring-data-neo4j/
He's adding some custom boilerplate code to make it work with a non embeded DB, is it ok ? Why it doesn't work as any other DB (like with JPA, where you just specify the address of the DB).
inserpio here. Don't lose your happiness, please: Spring Data Neo4j team is working hard to implement a new release that improves remote performances.
When Spring Data Neo4j started neither Cypher nor Neo4j-Server existed, while only the embedded version was available. As the server version was delivered SDN team provided a quick solution that works well if you only use repositories, but becomes a little bit too chatty is you want to use #Entity too. The problem is matching those #Entity with the returned nodes.
Since the new version is still not completed, for the moment, you could move you persistence-logic more tight to the database as a server extension. I explained it on the link you mentioned. It's a really fast refactoring: just move your entities and repositories to a new simple java project, install the resulting jar in the 'plugins' folder, one line configuration in the neo4j-server.properties and expose your queries as simple REST services.
Hope this could help.
Do not hesitate to contact me for any further question.
Cheers,
Lorenzo
Can someone please point me to the right direction.
I need to be able to host my GWT application in a way that it allows multiple clients to use the same application which could be separated by url's but internally using the same application.
the different sites would probably be seperated by different configurations. eg. different database, different log path etc, etc,
any ideas.?
You could use the following way to arrange your projects :
- my.application.core.project : it holds all the business logic and views for the application except for the entry point
-my.application.customerX.project : it holds only the entry point and the property files used for having the connection to the db, probably customerX specific theme
-my.application.customerY.project : it holds only the entry point and the property files used for having the connection to the db, probably customerY specific theme
Such an organization of the projects would allow you to have a common core that is distributed to each of the customers and also the ability to build on top of the core customer-specific impelementations.
The url's per client can be done with URL rewriting. Be it with an apache server in front of your application and/or in combination with a Filter in your web application.
As for the configuration, logging, and/or database per client you want a solution that doesn't store a file per client on the file system next to your application. Preferable you store client specific settings in one database and have an admin interface to manage it. For the client's data you also don't want a separate database per client, because it doesn't scale well, and would be a maintenance mess if you need to upgrade your application and databases to a newer version. Look for a multitenant architecture.
I admit this is a vague answer, but without specific system and software descriptions it's kind of hard to give a concrete answer. Nevertheless I hope this answer does give you some direction.
I have successfully achieved this by setting up separate directories in tomcat for different clients and then creating soft-links to the main application within that folder. when it comes to database connection properties and other configuration properties, instead of pointing them to the main application I just created them separately.
I'd like to be able to have an admin app and a client app for my project. Ideally, I'd like to be able to have a shared MongoDB collection. How would I be able to accomplish this?
I tried creating collections with the same name in two different apps, but found that Meteor will keep the data separate. Any idea what I can do? Thanks.
export MONGO_URL=mongodb://localhost:3002/meteor
Then run meteor app, it will change the default database meteor uses. So share databases or collections won't be a problem!
For administrative reason, I would use a individual MongoDB server managed by myself other than using meteor's internal MongoDB.
A reasonable question and probably worth a discussion in excess of this answer:
The MongoDB connection is handled by the Meteor application process itself and this is - as far as I read and understood - part of Meteors philosophy targeting an approach that might be described like: One data source serves one application belonging to it but many clients subscribing to it.
This in mind, combining "admin" and "client" clients in one application (i.e. your Meteor app) is probably the preferred way.
From a server administrative view, however, connections are handled by Meteor in that way that there is always the default local data source which resides in your project directory (.meteor/local/db, try meteor mongo --url to obtain the mongo connection string while the meteor application process is running). But nevertheless one may specify an optional data source string for deployment purposes like described in these deployment instructions.
So you would need to choose a somewhat creepy way of "local development deployment" for your intended setup to get working. Or you go and hack the sources and... no, forget it. You probably want your application and clients to take advantage of e.g. realtime UI updates (publish) and that is why the Meteor application is tied to an "application data source" and vice-versa by now. When connecting from another app, events that trigger changes in the model would not be transported across those applications. The mongoDB instance itself of course isn't aware of that.
I'm sure the core team won't expose the data source connection to a configuration section for considered reasons unless they extend their architecture with some kind of module concept which provides a common service layer of core Model/Collections abstraction across Meteor instances - at least supporting awareness of publish/subscribe events.
Try this DDP test I hacked together for a way to bridge two apps (server A and B).
Both servers can manipulate data, but data is only stored in one collection on server A.
See this link as well
I am planning a Catalyst application, that will be deployed over a number of servers. It will be used internally by support staff to control aspects of an operational system that runs on those servers.
The application will run much in the same way on each server, save for a limited amount of site specific behaviours. Some actions will only apply to some servers, and some actions will behave differently on other servers.
Are there any recognized design patterns/practices that enable site-specific customization of a Catalyst application?
I am currently thinking of deploying a site configuration file alongside the application, that will be used to determine what actions to enable, and set parameters that control other action's behaviour. Ideally this customization would happen when the application is loaded by mod_perl (Apache2) - but I am not sure if that would even be possible.
Any suggestions welcome!
Catalyst::Plugin::ConfigLoader has code to help you with site-specific configuration in the form of the MYAPP_CONFIG_LOCAL_SUFFIX environment variable. Since Controllers are Components and config is available at setup_components time, you can do whatever foolery you want with action registration when your controller is compiled. There's not much pre-rolled for it, because everyone's requirements are so different, but it's not exceptionally hard, and there's advice to be found on the mailing list.
You can set templates, or have conditional behaviour in the controllers based on the value of $c->req->host.
I always use the unique combination of $HOSTNAME and $USER to define the specific configuration file to be loaded, e.g.
conf => "my_app_${hostname}_${user}.conf"