Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 9 years ago.
Improve this question
We want to push data from a server to clients but can only use HTTP (port 80). What is the best solution for messaging? One idea is Comet. Are there other ideas or frameworks which offer lets say JMS over HTTP. (Yes, ActiveMQ supports it too, but waggly IMHO. And JXTA supports it too but the configuration is complicated. Something simple is preferred.)
The simplest solution for many, many reasons is to use a Comet based approach (like you mention). This means the clients (to whom you want to "push" messages) open long-lived HTTP connections. Those connections stay open until they time out or you send the client a message. As soon as either happens the client opens a new connection.
Directly connecting to clients could be problematic for many reasons: they could be behind firewalls that disallow that, they could be behind proxies and so on.
Unless your clients are real servers (in which case you're really the client), have them contact you and send a response to mimic push.
Atmosphere and DWR are both open source frameworks that can make Comet easy in Java.
We used COMET in conjunction with JMS using WAS Web 2.0 Feature Pack; in effect the server did the JMS subscribe and COMET-pushed the message to the browser. as a developer it "felt" like the browser was subscribing to JMS. This "just worked" so we didn't look further for alternatives.
I could imagine a pure JavaScript JMS implementation in the browser, using HTTP as a transport but my instict is that this would be very heavyweight. I know of no such implementations.
The alternative approach to those already discussed (i.e. Comet etc.) is to implement polling in the client. The downside of that approach is that you inevitably have a delay from the time of the message/event and until the client receives it. If your application is very sensitive to such delays, polling is out.
If a certain amount of delay (at minimum in the order of a few seconds) is acceptable, polling is less of an abuse of the HTTP protocol. It is also more robust against temporary network troubles as the server by default queues messages and wont get upset if the client isn't available on its schedule.
I created an example app using Comet, Raphael, Bayeux, Java and Maven running PaaS Cloudbees and wrote a blog post about it, hopefully it will be helpful to someone.
http://geeks.aretotally.in/thinking-in-reverse-not-taking-orders-from-yo
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 6 years ago.
Improve this question
I am in the process of choosing a networking library to implement a client/server system that cannot spare any microsecond. It will implement its own protocol to send and receive messages. I am looking for a good NIO framework that will allow me to easily develop the server and the client, without having to worry too much about the low level selector details. Everyone recommends me Netty but I would like to experiment with 2 or 3 other alternatives before committing my team with a framework. One thing I did not like very much about Netty is how it handles ByteBuffers with its own ByteBuf implementation and reference counting. Can anyone share your thoughts and alternatives?
We have developed a NIO networking library that performs under 2 microseconds over loopback without producing any garbage for the GC. As Peter Lawrey mentioned, the native JDK selector produces a lot of garbage but we have fixed all these garbage leaks by implementing our own epoll selector. Busy waiting the selector thread is great for latency but there must be a balance not to burn the chip or consume a lot of energy. Our selector implementation use low-level tricks to implement a kind of energy saving mode that takes care of that balance.
Besides CoralReactor, you can also take a look on Grizzly and Mina, but we haven't played with these frameworks yet.
For some Netty TCP performance benchmarks you can take a look here.
This is assuming you really want to save every micro-second. Most applications don't have such strict requirements.
If you want to save micro-seconds, you will want to use busy waiting non-blocking NIO for threads on dedicated cpus. This doesn't scale well as you need to have plenty of CPU but does minimise the latency for handling IO. I suggest you also bind the isolated CPUs to minimise jitter.
You will want to avoid using Selectors as they block and/or create quite a bit of garbage adding to GC pauses.
Also to minimise latency you will want to use a low latency, kernel bypass network adapter such as Solarflare.
You will want to use a push parser so long messages can be decoded/parsed as they download. i.e. you won't want to wait until the whole messages is received before starting.
Using these tricks in combination can save 10 - 30 micro-seconds off every request or inbound event.
Netty is a better solution for scalability ie, higher net throughput, but at a small cost to latency, as do most frameworks which are based on support web services where milli-seconds delays are tolerable.
If you are okay with using at least some Scala, Spray is a great alternative to Netty. On the long run, the Play framework is for example intending to migrate from Netty to Spray. Spray offers different levels of TCP abstractions. Those are:
Chunk level
Request level (HttpRequest / HttpResponse)
Marshalled object level
The deeper you dig down into the stack, the more raw the delivered information is. In the chunk level API, you come pretty close to original byte buffers. I never used this low abstraction level myself, but I heard good things.
Spray builds on top of Akka IO which is again built on top of Java NIO. All functionality wraps around Actor abstractions what makes it easy to build parallel applications using Spray. I think a chat server would be a perfect use case. Since Akka offers a Java API, you should be able to use Spray with mostly this API. However, you will probably need to read some Scala sources every now and then. Eventually, Spray will merge completely into Akka.
Edit: Quote from the Spray web site: "Spray is no longer maintained and has been superseded by Akka HTTP. Playframework started experimentally supporting Akka HTTP Server backend starting from Play 2.4.X. In Play 2.6.X versions, play completely migrated to Akka HTTP server backend.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
We are currently running a distributed Java application connected by a set of JMS queues (no topics). The Java application makes heavy use of the Apache Camel framework, which is also used to communicate via JMS. As JMS provider we have ActiveMQ in use. Our requirements on the queuing solution are quite basic in terms of features - somehow comparable to local Java queues and Camel SEDA queues:
The queues need to be highly available
In average the message is quite small (several KB), but there must not be a restriction on the size (i.e., a small percentage of the messages transferred have several MBs)
Delivery must be "exactly once" (Amazon SQS, for example, guarantees "at least once" only, which is not acceptable for us)
We do not require persistent queues, since messages are stored in a database before entering the queuing system. So far, ActiveMQ is working quite well for us after spending some time on the setup. However, there are two issues because of which we are searching for a different solution:
We currently achieve high-availability by running AMQ in JDBC Master-Slave-Mode. Failovers work quite ok, but not as transparent as desired.
The JDBC store has a negative impact on performance, especially if we transfer larger messages (>= 2-3 MBs) over several (> 6) queues. Furthermore, we have the feeling to unnecessarily bother our database.
We know that AMQ supports HA using Zookeeper since version 5.9. Some time ago, however, we started to consider/evaluate Hazelcast as a replacement for AMQ. So long, Hazelcast looks quite charming, since it seems to fulfill all of our requirements and seems to be much simpler to run than AMQ with Zookeeper. Furthermore, Camel provides nice support for using Hazelcast as queuing solution via its Hazelcast SEDA features. Given the fact that Hazelcast seems to be the perfect replacement for AMQ for us, we somehow wonder that there is not much information available on the Web discussing Hazelcast as a (serious) replacement for JMS. Thus, we would like to know:
Are there any drawbacks from replacing JMS with Hazelcast (performance, reliability,...)?
Has anyone experienced problems with multi-MB messages in Hazelcast?
Has anyone experienced any reliability issues with Hazelcast? We are still using 2.6 at the moment (because the Camel component is currently using that version) and have daemonized it on Ubuntu. So far it seems to be running flawlessly, but some additional experiences would be nice to hear.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 9 years ago.
Improve this question
I've been asked to implement a notification system in a Cloud Java application. The premise is that administrators or components of the application can send either specific messages to individual users, or broadcast announcements to all users.
Notifications would be categorized by severity, type (outages, new services, etc.), and corresponding component.
Users would be able to select types and components they're interested in, and how they'd like to receive those notifications (by e-mail, just shown on dashboard, SMS, etc.). Users could acknowledge or delete notifications, so they won't show up for that user anymore.
Although I'm sure this would be interesting to implement from scratch, it just feels like there should be an existing system, Apache project, commercial project, etc. that does just this and would avoid me having to reinvent the wheel.
My question is: Can anyone recommend a framework for notification tracking that could be integrated into an existing application and automatically handle all the back end stuff? Commercial or open source are fine, as long as the licensing terms are commercial friendly (no GPL or LGPL, please).
I guess what you are looking for is something similar to Amazon Simple Notification Service (SNS). But first let's set some things straight:
You're trying to send Email/SMS - and both require Infrastructure, not just frameworks/libraries. I guess your client (or any client for that matter) would have an Email server running somewhere, so you won't have a direct cost impact. But sending SMS does incur an infrastructure overhead.
You won't have an out-of-the-box solution. Since you'll be having additional infrastructure, you will end up at least writing a good level of integration with this infrastructure.
Keeping all that in mind, here are the options, listed in order of difficulty:
Use Amazon SNS
Use Cloud Message Bus (CMB) - an open-source clone of Amazon SNS. It has the same API format as Amazon SNS, so you'll use this the same way you use Amazon SNS
Use Apache Camel with its various Email/SMS Components. Apache Camel is an enterprise routing framework. It has a Message Queue where developers can push messages into, and then it has various routers which take these messages and send them elsewhere. It has routers for sending Email/SMS out-of-the-box. You would first create a topic to which you post messages. Then when a user registers for email notifications, you would add an email endpoint for him/her. And when they opt-out of Email, you will remove that endpoint. Basically its very close to designing your own solution - except you don't have to write code for sending SMS/Email, it has out-of-the-box components for doing that, and you just have to write integration code to add those endpoints as and when the user subscribes for notifications.
Roll your own. Your solution would end up being very similar to the Apache Camel approach. You will have a message queue, you will have topics and listeners. Except you'll be writing your own code to send all the emails/SMS.
Edit: Minor clarifications
It looks like your requirement is some sort of live data in a browser based web application. If that is correct, there have been great strides in some of the HTML 5 apis, specifically web sockets.
Websockets are an extension of the HTTP protocol that allow for bi channel communication between client and server. There is a downside however. Believe it or not, browser support is still pretty scarce, and some complications arise with http proxies in the wild.
Typically, to circumvent the lack of widely accepted support, there have been quite a few javascript/server side frameworks that have surfaced that seem really promising. These frameworks typcially take care of fallback support when websockets aren't supported. Some fall back technologies include server sent events, jsonp, long polling, short polling etc.
2 excellent open source projects come to mind:
1). Atmoshphere: https://github.com/Atmosphere/atmosphere
2). Socket-io - http://socket.io/
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 2 years ago.
Improve this question
I am attempting to contact everyone on a LAN to discover which devices are currently using the ip and running my service. Every device running the service will know which other devices are connected when they come online. I have basic networking experience(tcp/udp), but I haven't done much with more complicated communication packages. I wanted to post what I have researched/tried so far and get some expert responses to limit my trial and error time on future potential solutions.
Requirements:
Currently using java, but require cross-language communication.
Must be done in an acceptable time frame(couple seconds max) and preferably reliably.
I would like to use similar techniques for both broadcast and later communications to avoid introducing added complexity of multiple packages/technologies.
Currently I am planning on a heartbeat to known ip's to alert that still connected, but I may want to continuously broadcast to lan later.
I am interested in using cross-language rpc communication for this service, but this technique doesn't necessarily have to use that.
Later communication(non-broadcast) must be reliable.
Research and things attempted:
UDP - Worried about cross-language communication, lack of reliable delivery, and would add another way of communicating rather than using one solution like the ones below. I would prefer to avoid it if another more complete solution can be found.
Apache Thrift - Currently I have tried to iterate through all potential ip's and try to connect to each one. This is far too slow since the timeout is long for each attempted connection(when I call open). I have yet to find any broadcast option.
ZeroMQ - Done very little testing with basic zeromq, but I have only used a wrapper of it in the past. The pub/sub features seem to be useful for this scenario, but I am worried about subscribing to every ip in the lan. Also worried what will happen when attempt to subscribe to an ip that doesn't yet have a service running on it.
Do any of these recommendations seem like they will work better than the others given my requirements? Do you have any other suggestions of technologies which might work better?
Thanks.
What you specify is basically two separate problems; discovery/monitoring and a service provider. Since these two issues are somewhat orthogonal, I would use two different approaches to implement this.
Discovery/monitoring
Let each device continuously broadcast a (small) heartbeat/state message on the LAN over UDP on a predefined port. This heartbeat should contain the ip/port (sender) of the device, along with other interesting data, for example an address (URL) to the service(s) this device provides. Choose a compact message format if you need to keep the bandwidth utilization down, for example Protocol Buffers (available in many languages) or JSON for readability. These messages shall be published periodically, for example every 5th second.
Now, let each device listen to incoming messages on the broadcast address and keep an in-memory map [sender, last-recorded-time + other data] of all known devices. Iterate the map say every second and remove senders who has been silent for x heartbeat intervals (e.g. 3 x 5 seconds). This way each nodes will know about all other responding nodes.
You do not have to know about any IP:s, do not need any extra directory server and do not need to iterate all possible IP addresses. Also, sending/receiving data over UDP is much simpler than over TCP and it does not require any connections. It also generates less overhead, meaning less bandwidth utilization.
Service Provider
I assume you would like some kind of request-response here. For this I would choose a simple REST-based API over HTTP, talking JSON. Switch out the JSON payload for Protocol Buffers if your payload is fairly large, but in most cases JSON would probably work just fine.
All-in-all this would give you a solid, performant, reliable, cross-platform and simple solution.
Take a look at the Zyre project in the ZeroMQ Guide (Chapter 8). It's a fairly complete local network discovery and messaging framework, developed step by step. You can definitely reuse the UDP broadcast and discovery, maybe the rest as well. There's a full Java implementation too, https://github.com/zeromq/zyre.
I would use JMS as it can cross platform (for the client at least) You still have to decide how you want to encode data and unless you have specific ideas I would use XML or JSon as these are easy to read and check.
You can use ZeroMQ for greater performance and lower level access. Unless you know you need this, I suspect you don't.
You may benefit from the higher level features of JMS.
BTW: These services do service discovery implicitly. There is no particular need (except for monitoring) to know about IP addresses or whether services are up or down. Their design assumes you want to protected from have to know these details.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
what would be the good starting point to learn TCP Socket programming using java.
I have reasonably good experience in java software programming but new to netwrk/socket programming.
I am working on to develop a proxy cache server. But not able to read post requests/302/405 requests.
I referred to this below code.
http://blog.edendekker.me/a-java-proxy-server-with-caching-and-validation/
But unable to modify the code to read urls like www.gmail.com that return 302 Moved Permanently Error OR 405 Method Not valid Error. And also not able to read POST requests.
What would be the starting point where I can read about handling errors and handling POST requests.
Any reference links, example codes would be helpful.
My prev question in similar topic:
Handle a POST request and write response to client socket
Thanks
It looks like your problems are more related to HTTP than to TCP as such. Do you want to implement a proxy server in order to learn the HTTP protocol? If not, there are several good proxies freely available, often including source code. If you just want to learn TCP socket programming, try something simpler such as e.g. POP3. Also, if you want to do TCP in Java, be aware that there are 2 major ways to implement them:
One thread per connection
One thread per application, shared between connections (Java NIO and NIO2)
Assuming you really want to tackle the HTTP proxy. HTTP is not trivial if you want to implement all of the functionality that e.g. browsers use, like caching, authentication, etc. plus the additional complexities that incurs when implementing a proxy.
If you really want to bite the bullet, here's a more lightweight version of the HTTP protocol, for all the details, refer to RFC 2616 . But be aware that RFC 2616, the HTTP 1.1 specification, refers to other RFCs that you might have to consult as well for specific areas such as authentication.
Update:
One other thing that might be easier in some cases is using an HTTP proxy to sniff the communication between say a browser and an off-the-shelf proxy to quickly see what others are doing.