First of all I've read this post and it partially answered my question but here's my dilemma: I'd like to install ServiceMix on two different machines, and I want them to be working on failover. Which means if one instance dies for whatever reason the other one takes over control, and if I have to install a third instance of ServiceMix it would be easy to do so.
What I'm planning on installing and using is basically : Camel (with Jetty extension), ActiveMQ, Karaf, hawt.io and webconsole.
So basically what I want to do is to have the same bundles in both OSGis, same configuration for both instances, when I change something on one it gets propagated to the second.
Any Idea on how I could get that done? Thank you in advance.
You have to experiment a bit, but I think it is a reachable task.
First of all for the propagation Task you'll need to use the Apache Karaf Cellar clustering solution, it will help you propagate all your changes throughout your Cluster-Group. Second you'll need to configure a fail-over mechanism as described in the documentation. For this you most likely need to switch to Container-level locking. The crucial part is to make sure all your own bundles aren't stopped while the Karaf Cellar ones are already working. You might need to tweak the startlevels for your own apps and the default startlevel a bit.
Related
I have implemented 2 services A,B in my bundle. I would like to change the code of service A by building a new jar file and do update command but keep the service B running without start it again.
Sounds like you have 2 services in 1 bundle. The unit of deployment is a bundle, so my recommendation is to split the two services into two bundles. Otherwise, undeploying your existing bundle will naturally also tear down Service B.
Alternatively, in case the API/interface resides in a separate bundle, you could deploy a new service-implementation for A in a separate bundle, with a higher priority, and rewire all uses of the service. Which typically is rather confusing, so it's a distant second place recommendation.
Edit: You comment that you are combining services in a bundle to minimize the number of jars, but you want to update the services independently. Specifically for minimizing the number of jars: Are you trying to solve a problem that you indeed had? I'm mainly working with Liferay, which is fully OSGi, and a plain vanilla installation comes with more than 1000 bundles - the runtime handles it just fine. Make sure you're not preemptively optimizing something that doesn't need optimization.
If your components have different maintenance intervals, then deploy them in different bundles. Period. No use working against the system, which has no problem with the number of bundles at all.
I want to create another instance of dspace to work on different projects. however I do not know how or if it will conflict with this running.
While it's technically possible, I would advise against this for the following 3 key reasons:
Quite a few configuration aspects of DSpace still count on a Tomcat restart to take effect. If you have two instances running in the same Tomcat, it means you have to bring both of them down when you want to update one of them.
Performance related issues are already far from trivial to debug in DSpace, even if you have only one instance running in one Tomcat. If you run two instances, it is very likely that you will only make this more difficult.
This kind of setup is non-standard. As with all non-standard setups, you will find it much harder to get community support, as very few other people will be in the same boat.
So ... either run two VMs, or just two Tomcat processes on one VM.
If after these warnings, you still want to do it, the basics would be to run all of the webapps you want twice in the tomcat, on different ports. The minimum you would need are 2x XMLUI OR JSPUI and 2x SOLR. It could be possible to run one solr webapp, and keep 2 search, statistics, authority and oai indexes in this one SOLR webapp, but I don't know what the side effects could be.
1) Obviously each instance should be installed to a different set of directories.
2a) Create a separate Context for each instance. That will give them different paths: http://legion.example.com/one/, http://legion.example.com/two/.... I do this on my development workstation all the time.
2b) You can also create separate domains and IP addresses, bind them to multiple Host objects in a single Tomcat configuration: http://one.example.com/, http://two.example.com/.... I have four low-volume production DSpace instances running in one Tomcat instance on a midsized host.
Each DSpace instance needs its own database, but PostgreSQL can host dozens. You should consider creating separate database user accounts for each.
You'll also need separate Handle resolvers for each DSpace, just the same as if each instance was on its own host. When configured for DSpace, the Handle resolver uses the DSpace database instead of its own, so it's specific to a single instance.
Solr ought to be able to serve several sets of cores for several DSpaces, but you'll have to do a fair amount of configuration to keep them distinct and ensure that each DSpace is using its own set. You'll learn a lot more about Solr than you need to know for the captive Solr instance that gets installed with a single DSpace.
But then, you'll also learn a lot more about Tomcat than you need to know for a single DSpace....
If you declare your Contexts in external files ([Tomcat]/config/Catalina/localhost/one.xml etc.) and you have automatic deployment set up right, you can just 'touch' one of the Contexts to restart it without restarting a whole Tomcat. Otherwise you can use the Tomcat Manager webapp to do this. Consider well whether you want to have the Manager running, though, because it is quite powerful and it is exposed on the network. I run such applications on yet another, non-routable address so they can't be reached from Outside.
DSpace is not small, so you will need to ensure that you have enough memory to run several instances and that Tomcat's memory limits are adjusted accordingly. I would suggest also installing a resource monitor such as Psi Probe and glancing at it regularly. The above comments on performance are spot-on.
Learning to make all this work was loads of fun, and took quite some time. On the other hand, for development you may prefer something like https://github.com/DSpace/vagrant-dspace, a packaged virtual machine with DSpace and friends inside.
When running Spring XD in Distributed Mode, there will be many JVM's running the XD Container.
Is there a "slimmed down" version of the XD distribution that includes only the bins/libs that are necessary to run the container?
there currently isn't. But I'm not 100% sure the container-only version would be that slim (it's the container that needs to know about the many frameworks supported). So if we ever hard-separate the two, I'd bet that the admin would benefit.
If this is really a concern for you, I'd invite you to create a JIRA issue to track this (ideally motivating the concern). We always aim for better modularity, but this hasn't been on the top of our list, for now.
I have a requirement where, if one bundle fails to start because of some internal state issue, the entire application should not be running and thus the platform should be shutdown (bundleCtx.getBundle(0).stop()).
Because of OSGi's nice modularity and so on, other bundles might've started up just fine.
It feels kinda wrong for bundles to be calling bundleCtx.getBundle(0).stop() (or System.exit(nn) if a BundleException occurs) in different places.
Is there a common way to implement this? One way may be Declarative Services, but those are only notified when a given component starts, right? It cannot tell if something has failed (AFAIK).
Ah, here is one possibility I just stumbled upon.
I have a bootstrap bundle which is responsible for starting all of the other bundles in my app. It does this with START_TRANSIENT.
I could put logic into this bundle to do certain things depending on which bundle failed.
So one idea would be to have one bundle that checks if all needed services and bundles come up. It can then stop the framework if one or more services are missing or if a bundle does not start. This would allow to centralize the checking logic at one place.
How can I get the number of active session counts at the Jboss AS 7.2 (all sessions, not at single war)? I looked deeply for a MXBean that could give me that information but I didn't find one. There are a lot of information about that, but just for older versions. This seens to be an easy thing to do, but it's been very difficult to find an answer.
JMX is not a must if I can get this programatically by another way. I just cant modify the older projects to add listeners to check for that.
Well, after some digging I found an way using JBoss CLI (just google a little about it and the special syntax called Detyped Management Model). With that in mind just call this command at the CLI:
/deployment=<YOUR-EAR-NAME>.ear/subdeployment=<YOUR-WAR-NAME>.war/subsystem=\"web\"/:read-attribute(name=active-sessions)
With that you can know the connected users for that specific war. This can be tunned with different ways to look for all wars, so just play with it. There's an API to do that programatically too.