Develop Reference

Configuration for scaling Grpc Server for blocking calls

I was learning GRPC as we are planning to expose GRPC server (instead of Rest Endpoint) within spring boot microservice which will be listening on dedicated port. I am using following code snippet to create GRPC server.
io.grpc.Server server = ServerBuilder.forPort(port)
.addService(new MyServiceImpl())
.build()
.start();
Here server object which is encapsulating unerlying NettyServerBuilder object is being initialized with default values. We are planning to deploy it in production (powerful hardware) where we are expecting huge traffic (approxy 10k calls per second) from the grpc clients. My question is like For scaling How should I configure underlying NettyServerBuilder. Which are the important configs that I need to tune? Any suggestions and best practices are welcome

You should:
Use serverBuilder.executor() and set a ForkJoinPool as the executor. This executor is where the gRPC Callbacks (i.e. the methods on ServerCall.Listener) are invoked. ForkJoinPool is a heavily optimized, more concurrent executor, and allows the network threads to get back to handling things like HTTP/2 and SSL.
Use nettyServerBuilder.workerEventLoopGroup() and provide an EpollEventLoopGroup. This allows you to use an optimized network thread implementation that is more efficient than the default Nio Java network implementation. The number of threads you provide to the group will depend on your benchmarks, but a good rule of thumb is 2-4 workers. gRPC uses EventLoops somewhat differently than netty, so you don't usually need 1 per core.
Use netty-tcnative for your SSL implementation. It is a enormously faster SSL implementation that wraps OpenSSL and BoringSSL.
We try hard to make the default implementation of gRPC's server to be fast without any extra configuration, so even if you don't use these, it's still going to be pretty fast.

Migrate Netty Websocket to Jetty Websocket

My application uses a custom binary protocol which is implemented with Netty. Recently I changed it to use Netty's websocket implementation. It works quite well.
My application also has a Jetty web server included and it offers websockets, too. Now I want to reduce the opened ports my server needs and handle all http traffic with one port.
I see three options:
Use either Netty or Jetty to proxy the traffic which belongs to the other implementation.
Reimplement the custom protocol on Jetty without the use of Netty's channels and piplines.
Create a custom implementation of Netty's channels that sends and receives it's data not over a socket but the methods Jetty's WebSocketListener offers.
Since Netty provides such a good api for writing binary protocols and a proxy sounds like extra problems to me I tend using the third approach. It shouldn't be too difficult to implement even though I don't know how to do it, yet.
Any thoughts what would be the best option and how I should implement it?

Java: HTTP asynchronous non-blocking remote logging server?

I'm looking for a way of implementing a simple API to receive log messages (for various events across various systems).
We've concluded an HTTP get request is the most open (lowest barrier to entry) for the different code bases and systems that would need to post to this server.
The server itself needs to provide an HTTP GET api where I would send a message e.g. logging.internal/?system=email&message=An email failed
However we'd like this to be non blocking so any application can throw information to this server and never have to wait (not slowing any production systems).
Does anyone know of any framework to implement this in Java, or an appropriate approach?

In java, for the server, you can use any implementation of JAX-RS for the Restful part, and when processing the message, just call an asynchronous EJB method ( http://docs.oracle.com/javaee/6/tutorial/doc/gkkqg.html ), which will do the longer processing.
This will allow the RESTful request to return as fast as possible.
In this case, the only blocking part will be the http request/response.
If you want to make it less blocking, issue the RESTful request from the client in an Async method as well (or a Message Driven Bean if using Java EE 5).

Which Client - Server Communication Approach?

Basically I need a bidirectional client-server communication (Java) where the client calls methods on the server, but also needs to get "callbacks" if certain events in the server occur.
The methods theirselves have quite complex input and output parameters and lateron it would be nice to include authentication to the system.
Which approach would fit my requirements?
I already build a prototype with RMI, but I read that there exists a number of problems especially for "callbacks" when the c/s are in different networks.
Additionally I would like to avoid JAX related technology, becuase of my complex data structures in the parameters.

Have you thought about using JMS. Within this architecture, server and client will register to a queue or topic and are able to send messages to each other. This enables sych and async application behaviour.
Please have a deeper look into JMS here:
http://java.sun.com/developer/technicalArticles/Ecommerce/jms/index.html
And a really nice implementation is ActiveMQ:
http://activemq.apache.org/

I've had lots of luck with using CometD for callbacks for webapps.

How to : Async Callbacks using SOAP/REST Web Services with Java

We have a Java API that needs to be supplemented/fronted with a SOAP/REST Web service Layer.
What does it take to implement Async Calls across process/server boundaries using
a) SOAP Webservices
b) RESTful webservices
Some of the methods might need multiple calls to respond to the request.
We will be using Java/J2ee to implement the SOAP/restful service using a library like CXF or Axis or Jax-RS/WS.
Any examples ? Gotchas ?
Thank you,

The Async Http Client is an open source library that was specifically designed for this type of problem. It utilizes futures and wraps up a lot of the detail and hassle out of making async calls.
The author has a very good getting started guide and there is an active discussion group. The author is a very talented developer and the project is under continuous development.
From the documentation:
The library uses Java non blocking I/O
for supporting asynchronous
operations. The default asynchronous
provider is build on top of Netty
(http://www.jboss.org/netty), the Java
NIO Client Server Socket Framework
from JBoss, but the library exposes a
configurable provider SPI which allows
to easily plug in other frameworks.

Your question is not clear. I am interpreting your question as you want your serverside code to call a remote REST web services in an Async manner. If so then your best bet is to use the Futures feature of java.util.concurrent it will do exactly what you want. If my interpretation of the question is wrong then please update your question with exactly where the async operations need to happen.

Akka http://akka.io/
Great framework, great performance - Here are their claims:
"""
Simpler Concurrency
Write simpler correct concurrent applications using Actors, STM & Transactors.
Event-driven Architecture
The perfect platform for asynchronous event-driven architectures. Never block.
True Scalability
Scale out on multi-core or multiple nodes using asynchronous message passing.
Fault-tolerance
Embrace failure. Write applications that self-heal using Erlang-style Actor supervisor hierarchies.
Transparent Remoting
Remote Actors gives you a high-performance transparent distributed programming model.
Scala & Java API
Scala and Java API as well as Spring and Guice integration. Deploy in your application server or run stand-alone.
"""

#Vivek
GET is async and other HTTP methods
are not.
This isn't true. Please go ahead and read about AJAX :-)

For REST web services (apart from GET) everything else (POST/PUT..) is Async, it returns you the HTTP status code of the opeeration.
If you want to make GET also Async then you will have to use Threads, We did it once in Spring framework using #Async annotation (which internally spawns a thread).
From get return the callback URL as the response and use threads to process the request asynchronously.
Apart from that, For both SOAP / REST once you get the request you can publish it on a JMS queue to make the service Async.

One of the best ways to implement asynch ops is to use callbacks. For REST APIs, design of APIs and Rest client should support this. For instance , client class should pass itself or it's inner class as listner. Rest API on server side should maintain request id and call back listener in map . Once processing is done , it can call method on listener based on request id from map.

Real question: why do you want to call it Async? Having looked at solutions for parallel processing on the Java EE side, it's not recommended that you spawn child threads within a container on your own.
In your case, it looks like the following:
1. you're looking to create a wrapper contract in WSDL (REST or SOAP or both) and if you clients are not just browsers (AJAX)(i mean you'd have adopters from the server-side), then, for JAX-WS -> you could create a #CallBack end-ponint (http://docs.oracle.com/cd/E15051_01/wls/docs103/webserv_adv/callback.html)
or
if it's REST end-point that requires being called from an adopter (server-side), use jAX_RS 2.0 feature
Note: Above assumes it's point to point but in an Async way
Here are a few options:
if you're looking to call REST Or SOAP or some other function asynchronously, you can use workManager API (JSR )
or
use JMS and use a request-reply model if you need it (short running) and calling multiple end-points in parallel
use WS-BPEL (only WSDL end-points) - this is a OASIS standard as well
use SCA (any component with any technology) that can contain assemblies of WS-BPEL component (stateless or stateful) running in BPEL engine like Apache ODE or IBM process server and other components and collaborates. This is a standard