I am developing an application to run as a command line tool, and I am using Scala/Akka. I would like for this command line tool to use a client/server architecture. When the first instance of this tool is launched, it launches an instance of a server in the background that actually does all of the processing. If a user then opens multiple terminal windows and launches more instances of this app, it will connect to the existing server rather than launch a new one. Basically I need multiple clients talking to a single server. Can this be accomplished with Akka's remoting, or do I need to run a more classic client/server architecture with a message broker in there somewhere?
Yes, it can be done with Akka remoting.
You'll want to configure the "server" ActorSystem with a well-known port. Then use system.actorFor in the clients to get an ActorRef to an actor running on the server.
Make sure the hostname that you use in the config is the same hostname that you use in the path that you use in actorFor.
Related
I am having an incredibly difficult time finding any information by IBM on how to connect to our company's queue. Some more specific questions:
do I need the queue manage?
how do I know which queue connection factory to use?
how do I connect to the queue from a standalone java application?
I honestly can't find any MODERN, up-to-date resources explaining the websphere mq and how to make use of it (this includes within my own company).
Thanks!
You can connect to a queue manager in either binding mode or client mode. Binding mode allows an application to connect to the queue manager only when they are both running on the same machine. Client mode allows an application to connect to the queue manager when the two a running on separate machines. You can use client mode when they are both running on the same machine but its not as efficient as binding mode.
If you want to use binding mode then you only need to know the queue manager name.
If you want to use client mode then you will need to know the queue manager name, hostname, listener port number, and channel name.
The following URL provides some information on using JMS to connect to MQ:
http://www-01.ibm.com/support/knowledgecenter/SSFKSJ_7.5.0/com.ibm.mq.dev.doc/q031500_.htm
I have an application that I inherited that listens on port 7001 for UDP broadcasts from our in-house test equipment, and I recently updated another application that needs to do the same thing. Both applications must be able to coexist on the same computer.
Currently, when my recently updated application attempts to bind to the port to listen for UDP broadcasts and fails, it simply reports that the port is not available and suggests that the inherited application is probably running. How can I get my application to detect what application is actually listening on that port? I've done a Google search and have even searched this site, but so far I have been unable to find anything except to use Task Manager, TCPView, or netstat at the command line.
I would prefer a technique that either uses the Windows API or a Windows system COM component, since both applications are written in Visual Basic 6.0. (I know, I know, but I must maintain these applications since they are mission critical.) However, a .NET solution would would also be useful in case I need it in my new development efforts.
Use:
netstat -n -o
That will show the process ID and from there you can either look in the Task Manager's process viewer, go to menu View → Columns... and check the Process ID (PID). Then you can see the name of the process listening on that port.
Of course, you're wanting a programmatic way of accomplishing this and the GetTCPTable2 API is best as was already suggested. In fact, if you look at the IAT (Import Address Table) for netstat.exe, it actually uses that API to get that information.
There is a way to communicate directly with a command window and get its output using pipes and it would work fine, but the ideal way is to simply use the same API netstat uses.
I want to create a XMPP server on my network and then send message to it with python so that this server can restart the target computer on the network , now how can i set up this server and how can i do the rest of the process?
tnx
I am not sure in what context you are trying to do this, but XMPP has been used in context outside of usual chat and instant messengers (e.g. load balancers, rpc, ...).
There can be several ways of doing this. One way I can think right now is by using Jabber RPC xep-0009 which says:
This specification defines an XMPP protocol extension for
transporting XML-RPC encoded requests and responses between two XMPP entities.
The protocol supports all syntax and semantics of XML-RPC except that
it uses XMPP instead of HTTP as the underlying transport.
Workflow wise here is how you can make this work:
You will need a jabber server which is up and running say on host-A
You will need to configure a startup service on other hosts in the network (say on host-B, host-C, host-D). This startup service is nothing but a xmpp client daemon which will start in the background whenever host is started.
This xmpp client configured as startup service are special in the sense that they will accept incoming rpc calls (support for XEP-0009) and execute received commands on the host.
Received RPC commands can be synonymous to shutdown, kill -9 xxxx depending upon your specific needs.
Finally, xmpp client on host-C can send one or more commands wrapped inside an stanza to xmpp client running on host-B.
You can use one of the existing python xmpp client library and simply extend their working examples for your use case. You will also need to check details on how to configure startup service depending upon your Operating System (e.g. update-rc.d for ubuntu or sc.exe for windows)
I am currently using Remote Method Invocation to interact with a windows service. As services cannot be interactive (UI) strictly from Vista and above, I cannot directly call those methods. So I am using Remote Method Invocation to access those methods. How safe is RMI?
Are there any better alternatives to using RMI? Like File channeling/ sockets and Listeners.
edit: Let me make it clear,
I have a java application which runs as a windows service. But I would like to manipulate the service and the way it works from an user interface but When I try to do that, Windows wont allow me to do that. So I am using RMI to manipulate the windows service from an user interface.(interactively).
Keep in mind that there is a reason for windows services not being able to have an UI. If you need an UI to interact with the service, what's the reason for running the program to interact with as a service anyway?
That being said, I'm using RMI to interact with the service (simply to do some configuration, poll status information; the program being executed as a service usually runs without any user interaction) - it's worked out pretty well so far.
You could of course use simple sockets (however, RMI is also built on sockets). A simple Listener won't work since you'll need some inter process communication.
What is the best way to access a running mono application via the command line (Linux/Unix)?
Example: a mono server application is running and I want to send commands to it using the command line in the lightest/fastest way possible, causing the server to send back a response (e.g. to stdout).
I would say make a small, simple controller program that takes in your required command line arguments and uses remoting to send the messages to the running daemon.
This would be similar to the tray icon controller program talking to the background service that is prevalent in most Windows service patterns.
Mono's gsharp tool is a graphical REPL that lets you Attach to Process.
#Rich B: This is definately a suitable solution, which I already had implemented - however on the server I have to use, the remoting approach takes around 350ms for a single request.
I've measured the time on the server side of the request handling - the request is handled in less than 10ms, so it has to be the starting of the client program and the tcp connection, that takes up the time.
Hence the hope that I can find another way to post the requests to the server application.
You can use the system.net.sockets abstractions to create a service on a TCP port, and then telnet to that port.
Check the library status page; Mono's coverage here is a bit patchy.