On 10/28/2014 9:36 AM, Jason Ricles wrote:
Thanks Tim,
That seems like the way to go. IT avoids us having to write our own
protocols and everything and instead just code the logic for what action to
take when a certain message is received.
Hi, Jason-
RMI seems reasonable if foo and bar might end up on different servers.
However, if they will always reside on the same server, why not execute
foo from within the web application? If you're polling, scheduling
background threads is fairly straightforward.
-Terence Bandoian
On Tue, Oct 28, 2014 at 10:27 AM, Tim Watts <t...@cliftonfarm.org> wrote:
Any IPC that you have to write from scratch is going have a not
insignificant level of complexity whether it's raw sockets, pipes, http,
whatever. Since it sounds like you can't introduce any additional
software packages, you might want to consider using RMI (see the
java.rmi package). At least then, you're coding to an API instead of
having to invent message formats and protocols.
On Tue, 2014-10-28 at 10:16 -0400, Jason Ricles wrote:
Yes we are trying to portable, well the socket is the last resort. We are
trying to avoid it until now but will go that way if we have to if there
is
no other way. Mostly due to the data coming in and out writing our own
socket will be complex but doable. As far as messaging broker, they are
not
approved for use on our system so thus can not be used.
On Tue, Oct 28, 2014 at 10:13 AM, Tim Watts <t...@cliftonfarm.org> wrote:
On Linux/Unix you could use a FIFO (aka named pipe) and have each side
connect to it with a stream. But that's non-portable and probably not
too elegant/robust. What's the problem with using a socket? Or better
yet, a message broker like ActiveMQ like someone else has already
suggested?
On Tue, 2014-10-28 at 09:46 -0400, Jason Ricles wrote:
Communicate means something happens that the daemon is monitoring, so
thus
the daemon sends a message to the websocket server running on the
webapp,
so that message can get relayed to the webpage from the server and
the
daemon will also need to get messages from the webapp. It will then
be
two
way and just regular messages.
On Tue, Oct 28, 2014 at 9:42 AM, chris derham <ch...@derham.me.uk>
wrote:
On 28 October 2014 11:06, Jason Ricles <jgr...@alum.lehigh.edu>
wrote:
Ok so here is the problem I have been spinning my wheels on for
day
let
me
just lay it out.
I have a daemon written in java running lets call it foo for
simpleness
on
a linux machine that has the tomcat server running. On the tomcat
server
is
a WAR file for a webapp called bar. In that webapp is a webpage
with
JavaScript websocket communication that connects to a websocket
server
that
is also a part of the WAR file. So I have a webpage and a
websocket
server
communicating with each other.
I want the foo daemon and the websocket server on bar (web
application)
to
be able to communicate with each other. Is there any way outside
of
sockets
to have foo and the websocket server on bar do this?
Define communicate - what kind? One way, two way, what kind of
data,
frequency, size, type?
Chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
