I've implemented tigase component with certain functionality and now trying to figure out how to use it as an external component.
For now it seems I have to set up separate tigase server with my component on it and then configure main tigase server to refer to that separate server as an external component.
What I would like to do is to assemble that external tigase into a single jar in order to be able to run it with one line command without installing tigase upfront.
Question is is it possible at all?
It seems that tigase needs database to run and administration guide encourages to use shared main server's database for external components. I'm not sure if tigase can start without database which makes it rather hard to run with simple java -jar command.
For now it seems I have to set up separate tigase server with my component on it and then configure main tigase server to refer to that separate server as an external component.
This is correct. Tigase XMPP server follows XEP-0114: Jabber Component Protocol and XEP-0225: Component Connections in this regard. Please refer to
External Component Configuration for details how to configure it in Tigase.
What I would like to do is to assemble that external tigase into a single jar in order to be able to run it with one line command without installing tigase upfront.
Question is is it possible at all?
You could create an "uber jar" - yes, that's possible. One of the possible solutions would be to create your component as a separate maven project, configure tigase-server as dependency and then take advantage of jar-with-dependencies of Apache Maven Assembly Plugin. It will pull all required, configured dependencies and place them in single jar file. Please note however, that for example database drivers won't be included.
It seems that tigase needs database to run and administration guide encourages to use shared main server's database for external components. I'm not sure if tigase can start without database which makes it rather hard to run with simple java -jar command.
Database is indeed required - this has the benefit of keeping your configuration consistent of many nodes that may run your external component (you need to updated only once on one node and all remaining nodes will update it automatically), but you don't have to use the main server database. Please see Usage with a separate database for details.
If you are using only single, local instance of your external component then you can create a simple derby database and place your configuration in etc/externalComponentItems file
Yes, the Tigase component Framework/API requires Tigase Server core to run. And you only load the Tigase server core with your custom component.
Shared database between Tigase main XMPP Server and component instance is recommended for simplicity but not mandatory. I think the external component instance could be even run with dummy DB connector, if DB is really not needed.
Related
I'm looking at using hawtio for our app as a support console. We're not currently using camel or the like, but I am impressed by the ability to connect to remote JVM's via Jolokia/JMX and the logging features and was wondering:
Our use case would be that we have a weblogic server hosting our web app and my thought would be to include hawtio as a war alongside it. In addition to monitoring the web app, we have a number other JVMs running on different servers.
Is it possible to create a dashboard using values from the local JVM, as well as some of the remote JVMs?
Or must one always manually connect to the instance to see the dashboard for that particular JVM?
The current dashboard and JMX plugin does not support that.
Though there is works planned to support gathering statistics from remote JMVs etc. And there is also work on elastichsarch with a kibana web ui.
I'm going to start developing a Java web app that I believe I will be deploying to CloudBees, but am concerned about what JRE/sandbox restrictions may apply.
For instance, with Google App Engine, you're not allowed to execute any methods packaged inside java.io.file or java.net. You're not allowed to start threads without using their custom ThreadFactory. You're not allowed to use JNDI, JMX or make calls to remote RDBMSes hosted on 3rd party machines. You're not allowed to use reflection. With GAE, there's a lot you're not allowed to do.
Do these same restrictions hold true for CloudBees? I'm guessing no, as I just read their entire developer docs and didn't run across anything of the sort.
However, what happens if my app tries to write to the local file system when deployed to their servers? They must have certain restrictions as to what can run on their machines, if for no other reason than security!
So I ask: what are these restrictions, or where can I find them listed in their docs? Thanks in advance!
Last I checked (a) there is no sandbox; (b) you can write to the local filesystem, but any files you write there may be discarded if the application is reprovisioned for any reason, i.e. use it for temporary files only. (An optional permanent file store service has been considered as a feature useful for certain applications.)
I am new to Chef. I just finished creating a cookbook that deploys a node.js app, configures Nginx, and then starts the app as 1 or more workers that are "load balanced" by Nginx. It works great. I made sure to keep it pretty generic, and all the app level config is done via attributes.
Now I am trying to think about an instance where I have multiple node.js apps running on the same server. For example, the primary API app, and another app that registered itself as a Gearman worker.
How would I go about doing this? Would I simply create another cookbook that is specific to that app, make sure it includes the generic cookbook's recipe, and then do attribute overrides just for that app's recipe?
Or, would it be better if I moved away from using attributes for the app config, and used data_bags instead?
Any help is appreciated.
I would have separated nginx and node.js installation/configuration into separate cookbooks.
If you must have several different applications running on node.js, I think it's ok to add a recipe for every application inside node.js cookbook and make sure each of them includes installation of node.js itself.
If you must have several instances of 1 and the same application/service running, then it is better to use one recipe with different attributes or data bags to introduce differences among instances.
Any more specific questions?
You should use roles Roles to manage multiple cookbooks on a server.
I'm not exactly sure of your scenario, but from your description, I would create 3 cookbooks. One that installs nginx, one that installs your app, and one that does node specific configuration and deployment. Bundle these into a role 'app_server' and put the role in the run_list.
This makes your app more composable, and it's easier to change out any of the pieces in the future.
grails run-app will start my app in an embedded tomcat server.
I would like to configure this embedded server so that only a single request processor thread is available and that multiple threads are processed serially rather than concurrently (similar to default webrick behaviour in the rails world)
Is it possible? If so, how do I do it?
As far as I know, this is not directly supported by the Tomcat plugin. But you could easily modify the Tomcat plug-in and run your own version.
If you look at the class org.grails.tomcat.TomcatServer, you will see it starts a Tomcat instance.
Here is the doc for this class: http://tomcat.apache.org/tomcat-7.0-doc/api/org/apache/catalina/startup/Tomcat.html
There is a getConnector() method which will return the default HTTP connector. Once you have it, you can probably change the settings, like maxThreads.
But be careful the performance will be awful. But I guess you already know that.
I'm looking at an existing website, deployed on an NFS server. I'd like to rewrite some portions of it to run on nodejs. As far as I can tell, nodejs isn't supported by the NFS folk, but I am constrained to using their servers.
So, is there a way to shoe-horn nodejs onto a nearlyfreespeech server? Has anyone tried this successfully?
As of 24/September/2014 NFS now support persistent processes:
Intro and overview - More power, more control, more insight, less cost
Official example - How-To: Django on NearlyFreeSpeech.NET
3rd party example - Run node.js on NearlyFreeSpeech.Net
To summarise the process described in mopsled.com's third-party example:
1) In NFS.N's admin UI, select your site's domain shortname under Sites, then change that site's "Server Type" to "Custom" instead of PHP / Apache.
2) Put your Node server code somewhere in /home/protected/
3) Create a shell script (eg run.sh) file somewhere in /home/protected/ that contains the command(s) to start your server (eg npm run start or node server.js). NFS.N will automatically run this script as a continuous process using a "Daemon", which we'll configure in the next step.
4) Select "Daemons" in your site's NFS.N admin UI, and enter your server's startup shell script path in the "command line" field. Complete the other fields as you see fit.
5) NFS.N will now ensure that your custom server process will run indefinitely. Your web server will now be available at the port your server listens at. However, NFS.N doesn't give root access for your server to communicate through the normal "low-level" internet ports (eg :80 and :443), so if you want to serve those, you must use NFS.N's "Proxy" feature described in the next step.
6) If you need to listen on low-level ports: select "Add a Proxy" in your site's NFS.N admin UI and enter the relevant settings, checking the "Bypass Apache entirely" option and giving the port your server is listening on for the "Target Port" option.
That's it! You can now stop/restart the server's continuous process (the shell script that the Daemon is maintaining) in the Daemon's configuration page.
NFS.net have a new "NFGI" architecture that may open the possibility to this:
NFGI can be made to work with other languages as well, making them first-class citizens of our service, just as fast and integrated as PHP currently is. This paves the way for making all sorts of frameworks viable that have traditionally been too slow when run through CGI. Rails. Catalyst. Django. We also believe it can be leveraged to make node.js work on our service, but we’re not 100% sure about that.
(Source: http://blog.nearlyfreespeech.net/2013/09/21/cgissh-upgrades/)
If you want this feature you can vote for it in their feature request system at https://members.nearlyfreespeech.net/support/voting
Although to be honest, I concur with earlier answers, using Node via CGI would lose some of the benefit...but would not be without its charms. Something like http://larsjung.de/node-cgi/ for NFS.net would be an interesting JavaScript replacement for PHP.
The problem is not that NFS.net will not support NodeJS. The thing is that you can't have "long running processes", i.e. servers. Since you can't run servers, you can't run Node.
In fact, the only way you can have anything dynamic there is by using CGI. There's no reason why Javascript engine could not be used to generate pages in response to requests, but I am not sure that can be done with node.