We Keep Coding

Implementing a persistent redelivery in a Java Boot integration microservice using Apache Camel and/or ActiveMQ [closed]

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 1 year ago.
Improve this question
I want to develop a small integration microservice, which implements communication between two existing systems.
System A has an Apache Kafka topics producing and consuming messages.
System B has a REST API and is capable calling a REST API callbacks.
Solution I'm trying to develop has to be able to communicate with each system, transform the messages and deliver it to another system (while doing extensive logging etc). The amount messages and the size of messages is small. Performance will not be an issue.
My chosen stack is Spring Boot + Apache Camel for routing + ELK for logging (+ templating engine etc, which is not really relevant).
My main concern is the requirement for a guaranteed delivery. From what I've read Camel stores the messages in memory, which means restarting/updating my microservice could lose some data which is inacceptable.
What are the relevant industry standards for implementing the guaranteed delivery?
I'm looking into ActiveMQ, but not sure if I need to bring the big guns since the solution is small and the amount of data is small. I'm not too opposed to the idea though.
I guess my questions are
What are the elegant ways of implementing persistent guaranteed delivery when integrating a 3rd party Kafka with a 3rd party REST systems.
Is bringing a whole message broker for the sake of a small microservice too much?

In short-- no, there is not an 'elegant' way to implement that. Kafka really can't do guaranteed delivery in the original sense of the meaning. Kafka solutions generally rely on all endpoints supporting the ability to replay the same data multiple times (or consumers having the ability to track what has been delivered already and drop repetitive messages). Same with REST-- REST endpoints (and HTTP in general, do not support guaranteed delivery.
This is a subjective question, but I'll try to answer objectively-- ActiveMQ has a smaller footprint than Kafka. If you are using Camel, you can readily co-locate small footprint ActiveMQ brokers with the Camel routes. This is a common architecture-- and one that has been around since Camel's inception. Alternatively, if the message volume is low a stand-alone ActiveMQ broker is as simple as running a single container or Java process.
"Kafka to Queued Messaging" is a common pattern to then provide guaranteed delivery to other systems. This centralizes the error handling and retry for network links to the queued messaging broker. Your Camel routes would then read from the queue(s). You can safely treat a queue-to-one-REST-endpoint as XA-like guaranteed delivery using JMS local-transactions.

Spring boot API - How to scale an App as users grow [closed]

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
I am making an API with Spring boot which will maybe have requests peaks.
So let's get into the worst scenario. Imagine that suddenly I have 2 million API requests.
What can I do to be able to handle this?
I read something about queues and workers but I don't know if that's the best way.
Is there some way to do it with something with AWS?

This is always a tricky question to answer. Firstly does your app really need to scale to 2 million API requests at peak? I ask because it is easy to over-engineer a solution 'to deal with future scale' which ends up a bit buggy and not even dealing with current scale very well as a result.
But assuming you really will have massive request peaks, the current microservice approach (or buzzword?) is quite a popular way of dealing with these periods of high demand. Basically you split your application up into smaller, self contained services ('microservices') which can be more-easily scaled as required.
Individual microservices can then be scaled up and down to match the load, using something like Kubernetes or Amazon ECS.
In terms of where Spring ties into this, Spring has a handy set of technologies called Spring Cloud - you'll notice Spring Cloud AWS there, too (although Spring Cloud in general can also work fine on bare metal servers, Docker, Kubernetes etc etc). A year ago I put together a simple Spring cloud/microservices demo on Github which shows how different Spring-powered microservices can fit together, which you may find useful.
The other nice thing with microservices is that you can swap out the language that a particular service is written in fairly easily, especially if the microservices 'speak' to each-other in a general format (such as JSON via REST requests). So if you had 10 different microservices, all powered by Spring Boot, but you find that a couple of them are better written in another language, you can just rewrite them: as long as they send and receive data in the same way, then the other parts of your system don't need to care.
Okay, that's a lot of buzzwords and new concepts. Feel free to ask questions if I can clarify anything, but microservices + kubernetes/AWS is a popular solution.
Other approaches which will probably work equally well, however, are:
Serverless - this is where you use a bunch of cloud-provider's tools and solutions to power your webapp, including things like lambdas, instead of hosting your application on a traditional server/VM. This medium tutorial gives a simple introduction to serverless.
Monoliths - this is a traditional web application which is a single, large, sprawling codebase, but this doesn't mean you can only have one instance of it running (i.e. you can still scale it). This very site is a successfully scalable monolith.

Your question is very broad, as there are lots of different solutions:
1) Use a load balancer and have multiple instances of your application
2) Use a containerization tool like docker and kubernetes to increase the amount of instances depending on current load. You can essentially scale on demand
3) We don't know what your app actually does: is it read heavy, is it write heavy? Will users be downloading content? The answers to this question can change whether or not a specific solution is feasible
4) You can maybe use a messenger queue like RabbitMQ to assist with distributing load across different services. You can have multiple services reading from this queue and performing actions at the same time...but again, this depends on what your app will actually be doing.
Check out AWS EC2 and Elastic Beanstalk. You can also get a simple load balancer up and running with nginx. Good luck

What are the Netty alternatives for high-performance networking? [closed]

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.

Cloud Services - EC2 vs. GAE vs. Lunacloud vs. Jelastic vs. [closed]

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
I am planning to program a software (in java), which will be (hopefully) used very much. In the beginning I may run it on my own server, but if it becomes popular my server will most likly crash.
So my plan is to program it for a cloud service like Amazon EC2, Google App Engine, Lunacloud or others.
The application will not have a gui for now. It will concentrate on SOAP or JMS (or something like that) and should store a lot of data in a relational database (PostgreSQL would be nice).
Since I am new to the cloud services, I tried a little bit with GAE. The main use is easy, but as soon as I use JPA and ManyToMany-Relations GAE is shit. Also making a SOAP or JMS Server in GAE is not simple.
Since I lost my weekend with trying GAE, I thought it would be a good idea to ask the community.
Which cloud service will fit best for my requirements? What are the benefits and differences between these services? What else can you recommend?

This is question is too wide open to provide a good answer, but here is some tips that should help.
There is a difference between platform as a service (GAE, Jelastic, Heroku) and Infrastructure as a Service (EC2).
In the platform as a service category, you have more of an automated infrastructure, and often very little visibility of the underlying components. This can make things easier from a developer perspective, but it has its downsides. You are often locked into how a provider works and it may be difficult to switch. You may also have limitations as to what you can do with your application.
In the Infrastructure as a Service category, you get access to virtual machines that you can configure and automate yourself. You have more flexibility on this type of platform, but you are generally expected to handle more of the work yourself. EC2 does have its own version of platform as a service with elastic beanstalk.

i would recoomend also heroku because it does not have a traffic limit and you can run a basic instance for free. if you dont need nosql dbs and extra software it will be very cheap and the unlimited traffic is good for your webservices. Gae has is own filestructure so i can understand your problems with your db structure very good. heroku and ec2 does not restrict your plans but ec2 is generally expensive if you dont plan to scale up and down often. heroku gets also very expensive when you want to add extra software and scale up. i dont know if youre able to scale up as good as with ec2 if you want to use jelastic.
another but complex approach would be renting some normal root servers with unlimited traffic where one instance act as load balancer but you would have to do the configuration by yourseld

Broadcast to everyone on lan [closed]

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.