I have a Wildfly 10 instance which defines a queue, publishes to that queue as well as receives from that queue via an MDB.
That has been have accomplished.
Now I want to add a second Wildfly 10 instance, running on another machine, which will also receive messages from that same (remote) queue defined in the first instance.
I've spent 2 days looking for a current example of how to do this.
There are tons of questions, and some outdated answers.
It seems like the one of the most trivial things to expect from a Q implementation, yet i cannot find any example.
Would someone please refer me to a good and current example (Wildlfy 10) of what needs to be done as far as annotation of the MDB, configuration of the standalone-full.xml, and and security requirements?
I looked into a similar scenario and I had as well trouble to find good documentation.
There are several ways to connect JMS-Queues together:
JMS core bridges
JMS bridges
Connections to a remote server (using a remote connector or properties directly in your MDB).
JMS-Clustering
… ?
I created a demo project at Github which uses "JMS-Bridges" to forward messages to another server. The project also uses remote connections to listen to messages of a remote server. The readme explains step by step how I would configure "Wildfly 10" servers that they use the same destination for JMS messages.
The best source of information concerning this topic seems to be the Messaging documentation of the Red Hat JBoss Enterprise Application Platform 7.0 which is as well valid for Wildfly 10.
I've read some articles recently on setting up AWS infrastructure w/o enabling SSH on Ec2 instances. My web app requires a binary to run. So how can I deploy my application to an ec2 instance w/o using ssh?
This was the article in question.
http://wblinks.com/notes/aws-tips-i-wish-id-known-before-i-started/
Although doable, like the article says, it requires to think about servers as ephemeral servers. A good example of this is web services that scale up and down depending on demand. If something goes wrong with one of the servers you can just terminate your server and spin up another one.
Generally, you can accomplish this using a pull model. For example at bootup pull your code from a git/mecurial repository and then execute scripts to setup your instance. The script will setup all the monitoring required to determine whether your server and application are up and running appropriately. You would still need an SSH client for this if you want to pull your code using ssh. (Although you could also do it through HTTPS)
You can also use configuration management tools that don't use ssh at all like Puppet or Chef. Essentially your node/server will pull all your application and server configuration from the Puppet master or the Chef server. The Puppet agent or Chef client would then perform all the configuration/deployment/monitoring changes for your application to run.
If you with this model I think one of the most critical components is monitoring. You need to know at all times if there's something wrong with one of your server and in the event something goes wrong discard the server and spin up a new one. (Even better if this whole process is automated)
Hope this helps.
I have a C# application that enables users to write a test and execute it (client). It also supports distributed execution over multiple machines using a central server and agents on said machines.
The agent is practically a duplication of the original execution ability but it is in a standalone solution.
We'd like to refactor that because:
Code duplication.
If a user will try to write and execute on a machine that runs an agent, there will be a problematic collision.
I'm considering 2 options:
Move this execution to a service, that both client and agent will use. I mean a service that will run locally, not a web service.
Merge client and agent - we'll have no agent, but the server will communicate with the client as an agent instead.
I have no experience in working with services. Are there any known advantages/disadvantages to either options?
A common library shared by both client and agent sounds more appropriate to allow simple cases such as just using the client and avoid the overhead of having to set up an extra service locally.
I am not a developer so please keep that in mind when reading the following message:
I need to be able to use Windows PowerShell to connect to a JMX RMI agent on a host, is this even possible ?
The example string from the java client I have been given is as below:
JMXServiceURL url = new JMXServiceURL("service:jmx:rmi:///jndi/rmi://localhost:7979/jmxrmi");
The reason for this is that I am doing other work in my PowerShell script and would like to keep it all in one place.
Thanks !
This is an unusual mix of two technologies, but it is possible.
On the off-chance that you are attempting to connect to a JBoss server, the quickest way may be for you to call twiddle, a command tool that will dispatch JMX requests to the target JBoss server and return the results to standard out.
Another way is to implement the Jolokia agent on the target servers. This will allow you to issue JMX requests using REST. Responses will also be returned in REST format which you can process in PowerShell using one of these solutions.
Thirdly, you can also deploy the JMX-WS service on your target servers which will allow you to communicate with the JMX server using web-services. This document provides some VBScript examples of this.
None of the above actually uses the JMXServiceURL syntax you outlined, and I cannot think of a way you could actually cleanly integrate this RMI based protocol into PowerShell, but hopefully one of the above will work for you.
========== UPDATE ==========
There may be a way to use the RMI implementation. Take a look at IKVM. It is a Java Byte Code to .NET compiler. I have successfully compiled JMX/RMI java code into a .Net assembly and used it from C#. I think PowerShell will do the same thing.
What are the different approaches for creating scheduled tasks for web applications, with or without a separate web/desktop application?
If we're talking Microsoft platform, then I'd always develop a separate Windows Service to handle such batch tasks.
You can always reference the same assemblies that are being used by your web application to avoid any nasty code duplication.
Jeff discussed this on the Stack Overflow blog -
https://blog.stackoverflow.com/2008/07/easy-background-tasks-in-aspnet/
Basically, Jeff proposed using the CacheItemRemovedCallback as a timer for calling certain tasks.
I personally believe that automated tasks should be handled as a service, a Windows scheduled task, or a job in SQL Server.
Under Linux, checkout cron.
I think Stack Overflow itself is using an ApplicationCache expiration to run background code at intervals.
If you're on a Linux host, you'll almost certainly be using cron.
Under linux you can use cron jobs (http://www.unixgeeks.org/security/newbie/unix/cron-1.html) to schedule tasks.
Use URL fetchers like wget or curl to make HTTP GET requests.
Secure your URLs with authentication so that no one can execute the tasks without knowing the user/password.
I think Windows' built-in Task Scheduler is the suggested tool for this job. That requires an outside application.
This may or may not be what you're looking for, but read this article, "Simulate a Windows Service using ASP.NET to run scheduled jobs". I think StackOverflow may use this method or it was at least talked about using it.
A very simple method that we've used where I work is this:
Set up a webservice/web method that executes the task. This webservice can be secured with username/pass if desired.
Create a console app that calls this web service. If desired, you can have the console app send parameters and/or get back some sort of metrics for output to the console or external logging.
Schedule this executable in the task scheduler of choice.
It's not pretty, but it is simple and reliable. Since the console app is essentially just a heartbeat to tell the app to go do its work, it does not need to share any libraries with the application. Another plus of this methodology is that it's fairly trivial to kick off manually when needed.
Use URL fetchers like wget or curl to make HTTP GET requests.
Secure your URLs with authentication so that no one can execute the tasks without knowing the user/password.
You can also tell cron to run php scripts directly, for example. And you can set the permissions on the PHP file to prevent other people accessing them or better yet, don't have these utility scripts in a web accessible directory...
Java and Spring -- Use quartz. Very nice and reliable -- http://static.springframework.org/spring/docs/1.2.x/reference/scheduling.html
I think there are easier ways than using cron (Linux) or Task Scheduler (Windows). You can build this into your web-app using:
(a) quartz scheduler,
or if you don't want to integrate another 3rd party library into your application:
(b) create a thread on startup which uses the standard Java 'java.util.Timer' class to run your tasks.
I recently worked on a project that does exactly this (obviously it is an external service but I thought I would share).
https://anticipated.io/
You can receive a webhook or an SQS event at a specific scheduled time. Dealing with these schedulers can be a pain so I thought I'd share in such case someone is looking to offload their concerns.