[undertow-dev] Undertow Http Server - Handling 2 Millions Requests Per Second Per Instance

SenthilKumar K senthilec566 at gmail.com
Mon Jul 10 00:43:38 EDT 2017


Hi Douglas ,   Here is the code for Undertow
https://github.com/senthilec566/undertow and Netty
https://github.com/senthilec566/microHttp . Both tested in default
settings..

Both Undertow and Netty respond SUCCESS or FAILURE.

I'd love to optimize undertow code and rerun the test case if required...

Another test result:

Undertow:
./wrk -c 10000 -d 10m -t 300 -s scripts/post_data.lua -R 500000
http://undertow:8009/
Running 10m test @ http://undertow:8009/
  300 threads and 10000 connections
Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     3.70m     2.07m    7.40m    57.73%
    Req/Sec   449.71      6.45   474.00     74.93%
  80640669 requests in 10.00m, 9.91GB read
  Socket errors: connect 0, read 353, write 0, timeout 448
Requests/sec: *134457*.31
Transfer/sec:     16.93MB

Netty:
./wrk -c 10000 -d 10m -t 300 -s scripts/post_data.lua -R 500000
http://netty:8009/
Running 10m test @ http://netty:8009/
  300 threads and 10000 connections
Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     2.76m     1.54m    5.70m    57.83%
    Req/Sec   763.90     73.21     1.12k    69.15%
  137216075 requests in 10.00m, 12.14GB read
  Socket errors: connect 0, read 0, write 0, timeout 42
Requests/sec: *228796*.63
Transfer/sec:     20.73MB


--Senthil

On Mon, Jul 10, 2017 at 3:12 AM, Stuart Douglas <sdouglas at redhat.com> wrote:

> Also it looks like you are sending more data in the undertow response.
> Mb/s is very similar, while req/sec is lower.
>
> Stuart
>
> On 10 Jul. 2017 9:39 am, "Stuart Douglas" <sdouglas at redhat.com> wrote:
>
>> Are they both using the same number of threads? Also what are you doing
>> in the handler? Are you calling dispatch? Dispatch is relativity slow in
>> these micro benchmarks, as it dispatches to a thread pool.
>>
>> Stuart
>>
>> On 9 Jul. 2017 4:34 am, "SenthilKumar K" <senthilec566 at gmail.com> wrote:
>>
>> Yet to try that .. My testcase  did not cover tuning no of threads .. but
>> even if we try to increase number of threads I believe both framework
>> performance would improve !! Different thoughts ??
>>
>> Anyway I like to add another test case by changing threads !!
>>
>> --Senthil
>>
>> On Jul 8, 2017 9:38 PM, "Kim Rasmussen" <kr at asseco.dk> wrote:
>>
>>> Have you tried playing around with the number of io and worker threads?
>>>
>>> lør. 8. jul. 2017 kl. 17.28 skrev SenthilKumar K <senthilec566 at gmail.com
>>> >:
>>>
>>>> Any comments on *Undertow Vs Netty* ? Am i doing wrong benchmark
>>>> testing  ?? Should i change benchmark strategy ?
>>>>
>>>> --Senthil
>>>>
>>>> On Fri, Jul 7, 2017 at 3:14 PM, SenthilKumar K <senthilec566 at gmail.com>
>>>> wrote:
>>>>
>>>>> Sorry for delay in responding to this thread!
>>>>>
>>>>> Thanks to everyone who helped me to Optimize Undertow Server.
>>>>>
>>>>> Here is the comparison after benchmarking my use case against Netty:
>>>>>
>>>>> *Undertow Vs Netty :*
>>>>>
>>>>> Test Case 1 :
>>>>> Simple Request Response ( No Kafka ):
>>>>>
>>>>> *Undertow:*
>>>>> Running 10m test @ http://198.18.134.13:8009/
>>>>>   500 threads and 5000 connections
>>>>>   Thread Stats   Avg      Stdev     Max   +/- Stdev
>>>>>     Latency     *3.52m *    2.64m    8.96m    54.63%
>>>>>     Req/Sec   376.58    103.18     0.99k    80.53%
>>>>>   111628942 requests in 10.00m, 13.72GB read
>>>>>   Socket errors: connect 0, read 28, write 0, timeout 2
>>>>> Requests/sec: *186122.56*
>>>>> Transfer/sec:     23.43MB
>>>>>
>>>>> *Netty:*
>>>>> Running 10m test @ http://198.18.134.13:8009/
>>>>> 500 threads and 5000 connections
>>>>> Thread Stats   Avg      Stdev     Max   +/- Stdev
>>>>>     Latency     *3.77m*     2.10m    7.51m    57.73%
>>>>>     Req/Sec   518.63     31.78   652.00     70.25%
>>>>>   155406992 requests in 10.00m, 13.82GB read
>>>>>   Socket errors: connect 0, read 49, write 0, timeout 0
>>>>> Requests/sec: *259107*.30
>>>>> Transfer/sec:     24.17MB
>>>>>
>>>>>
>>>>> *Test Case 2:*
>>>>> Request --> Read --> Send it Kafka :
>>>>>
>>>>> *Undertow:*
>>>>> Running 10m test @ http://198.18.134.13:8009/
>>>>> 500 threads and 5000 connections
>>>>> Thread Stats   Avg      Stdev     Max   +/- Stdev
>>>>>     Latency     *4.37m *    2.46m    8.72m    57.83%
>>>>>     Req/Sec   267.32      5.17   287.00     74.52%
>>>>>   80044045 requests in 10.00m, 9.84GB read
>>>>>   Socket errors: connect 0, read 121, write 0, timeout 0
>>>>> Requests/sec: *133459.79*
>>>>> Transfer/sec:     16.80MB
>>>>>
>>>>> *Netty:*
>>>>> Running 10m test @ http://198.18.134.13:8009/
>>>>> 500 threads and 5000 connections
>>>>> Thread Stats   Avg      Stdev     Max   +/- Stdev
>>>>>     Latency     *3.78m *    2.10m    7.55m    57.79%
>>>>>     Req/Sec   516.92     28.84   642.00     69.60%
>>>>>   154770536 requests in 10.00m, 13.69GB read
>>>>>   Socket errors: connect 0, read 11, write 0, timeout 101
>>>>> Requests/sec: *258049.39*
>>>>> Transfer/sec:     23.38MB
>>>>>
>>>>>
>>>>>
>>>>> CPU Usage:
>>>>> *Undertow:*
>>>>> [image: Inline image 1]
>>>>>
>>>>> *Netty:*
>>>>> [image: Inline image 2]
>>>>>
>>>>>
>>>>> --Senthil
>>>>>
>>>>> On Thu, Jun 29, 2017 at 7:34 AM, Bill O'Neil <bill at dartalley.com>
>>>>> wrote:
>>>>>
>>>>>> 1. Can you run the benchmark with the kafka line commented out at
>>>>>> first and then again with it not commented out?
>>>>>> 2. What rates were you getting with Jetty and Netty?
>>>>>> 3. Are you running the tests from the same machine or a different
>>>>>> one? If its the same machine and its using 20 threads they will be
>>>>>> contending with undertows IO threads.
>>>>>> 4. You can probably ignore the POST check if thats all your going to
>>>>>> accept and its not a public api.
>>>>>>
>>>>>> import io.undertow.server.HttpHandler;
>>>>>> import io.undertow.server.HttpServerExchange;
>>>>>> import io.undertow.util.Headers;
>>>>>> import io.undertow.util.Methods;
>>>>>>
>>>>>> public class DLRHandler implements HttpHandler {
>>>>>>
>>>>>>     final public static String _SUCCESS="SUCCESS";
>>>>>>     final public static String _FAILURE="FAILURE";
>>>>>>     final PostToKafka post2Kafka = new PostToKafka();
>>>>>>
>>>>>>     @Override
>>>>>>     public void handleRequest( final HttpServerExchange exchange)
>>>>>> throws Exception {
>>>>>>         if (exchange.getRequestMethod().equals(Methods.POST)) {
>>>>>>               exchange.getRequestReceiver().receiveFullString((
>>>>>> exchangeReq, data) -> {
>>>>>>                   //post2Kafka.write2Kafka(data); // write it to
>>>>>> Kafka
>>>>>>                   exchangeReq.getResponseHeaders().put(Headers.CONTENT_TYPE,
>>>>>> "text/plain");
>>>>>>                   exchangeReq.getResponseSender().send(_SUCCESS);
>>>>>>               },
>>>>>>              (exchangeReq, exception) -> {
>>>>>>                  exchangeReq.getResponseHeaders().put(Headers.CONTENT_TYPE,
>>>>>> "text/plain");
>>>>>>                  exchangeReq.getResponseSender().send(_FAILURE);
>>>>>>             });
>>>>>>          }else{
>>>>>>              throw new Exception("Method GET not supported by Server
>>>>>> ");
>>>>>>          }
>>>>>>     }
>>>>>> }
>>>>>>
>>>>>> On Wed, Jun 28, 2017 at 6:59 PM, Stuart Douglas <sdouglas at redhat.com>
>>>>>> wrote:
>>>>>>
>>>>>>> The multiple dispatches() are unnecessary (well the second one to the
>>>>>>> IO thread is definitely unnecessary, the first one is only required
>>>>>>> if
>>>>>>> post2Kafka.write2Kafka(data); is a blocking operation and needs to be
>>>>>>> executed in a worker thread).
>>>>>>>
>>>>>>> Stuart
>>>>>>>
>>>>>>> On Wed, Jun 28, 2017 at 5:42 PM, SenthilKumar K <
>>>>>>> senthilec566 at gmail.com> wrote:
>>>>>>> > After modifying the code below i  could see the improvement ( not
>>>>>>> much
>>>>>>> > slightly ) in server - 65k req/sec.
>>>>>>> >
>>>>>>> > import io.undertow.server.HttpHandler;
>>>>>>> > import io.undertow.server.HttpServerExchange;
>>>>>>> > import io.undertow.util.Headers;
>>>>>>> > import io.undertow.util.Methods;
>>>>>>> >
>>>>>>> > public class DLRHandler implements HttpHandler {
>>>>>>> >
>>>>>>> >     final public static String _SUCCESS="SUCCESS";
>>>>>>> >     final public static String _FAILURE="FAILURE";
>>>>>>> >     final PostToKafka post2Kafka = new PostToKafka();
>>>>>>> >
>>>>>>> >     @Override
>>>>>>> >     public void handleRequest( final HttpServerExchange exchange)
>>>>>>> throws
>>>>>>> > Exception {
>>>>>>> >         if (exchange.getRequestMethod().equals(Methods.POST)) {
>>>>>>> >                 exchange.getRequestReceiver().receiveFullString((
>>>>>>> > exchangeReq, data) -> {
>>>>>>> >                   exchangeReq.dispatch(() -> {
>>>>>>> >                       post2Kafka.write2Kafka(data); // write it to
>>>>>>> Kafka
>>>>>>> >                       exchangeReq.dispatch(exchangeReq.getIoThread(),
>>>>>>> () ->
>>>>>>> > {
>>>>>>> >
>>>>>>> > exchangeReq.getResponseHeaders().put(Headers.CONTENT_TYPE,
>>>>>>> "text/plain");
>>>>>>> >                           exchangeReq.getResponseSender
>>>>>>> ().send(_SUCCESS);
>>>>>>> >                       });
>>>>>>> >                   });
>>>>>>> >               },
>>>>>>> >              (exchangeReq, exception) -> {
>>>>>>> >                  exchangeReq.getResponseHeaders
>>>>>>> ().put(Headers.CONTENT_TYPE,
>>>>>>> > "text/plain");
>>>>>>> >                  exchangeReq.getResponseSender().send(_FAILURE);
>>>>>>> >             });
>>>>>>> >          }else{
>>>>>>> >              throw new Exception("Method GET not supported by
>>>>>>> Server ");
>>>>>>> >          }
>>>>>>> >     }
>>>>>>> > }
>>>>>>> >
>>>>>>> >
>>>>>>> > Pls review this and let me know if i'm doing anything wrong here
>>>>>>> ...
>>>>>>> > --Senthil
>>>>>>> >
>>>>>>> > On Fri, Jun 23, 2017 at 1:30 PM, Antoine Girard <
>>>>>>> antoine.girard at ymail.com>
>>>>>>> > wrote:
>>>>>>> >>
>>>>>>> >> Also, to come back on the JVM warmup, this will give you enough
>>>>>>> answers:
>>>>>>> >>
>>>>>>> >> https://stackoverflow.com/questions/36198278/why-does-the-jv
>>>>>>> m-require-warmup
>>>>>>> >>
>>>>>>> >> For your, it means that you have to run your tests for a few
>>>>>>> minutes
>>>>>>> >> before starting your actual measurements.
>>>>>>> >>
>>>>>>> >> I am also interested about how Netty / Jetty perform under the
>>>>>>> same
>>>>>>> >> conditions, please post!
>>>>>>> >>
>>>>>>> >> Cheers,
>>>>>>> >> Antoine
>>>>>>> >>
>>>>>>> >> On Fri, Jun 23, 2017 at 1:24 AM, Stuart Douglas <
>>>>>>> sdouglas at redhat.com>
>>>>>>> >> wrote:
>>>>>>> >>>
>>>>>>> >>> Are you actually testing with the 'System.out.println(" Received
>>>>>>> >>> String ==> "+message);'. System.out is incredibly slow.
>>>>>>> >>>
>>>>>>> >>> Stuart
>>>>>>> >>>
>>>>>>> >>> On Fri, Jun 23, 2017 at 7:01 AM, SenthilKumar K <
>>>>>>> senthilec566 at gmail.com>
>>>>>>> >>> wrote:
>>>>>>> >>> > Sorry , I'm not an expert in JVM .. How do we do Warm Up JVM ?
>>>>>>> >>> >
>>>>>>> >>> > Here is the JVM args to Server:
>>>>>>> >>> >
>>>>>>> >>> > nohup java -Xmx4g -Xms4g -XX:MetaspaceSize=96m -XX:+UseG1GC
>>>>>>> >>> > -XX:MaxGCPauseMillis=20 -XX:InitiatingHeapOccupancyPercent=35
>>>>>>> >>> > -XX:G1HeapRegionSize=16M -XX:MinMetaspaceFreeRatio=50
>>>>>>> >>> > -XX:MaxMetaspaceFreeRatio=80 -cp undertow-0.0.1.jar
>>>>>>> HelloWorldServer
>>>>>>> >>> >
>>>>>>> >>> >
>>>>>>> >>> > --Senthil
>>>>>>> >>> >
>>>>>>> >>> >
>>>>>>> >>> > On Fri, Jun 23, 2017 at 2:23 AM, Antoine Girard
>>>>>>> >>> > <antoine.girard at ymail.com>
>>>>>>> >>> > wrote:
>>>>>>> >>> >>
>>>>>>> >>> >> Do you warm up your jvm prior to the testing?
>>>>>>> >>> >>
>>>>>>> >>> >> Cheers,
>>>>>>> >>> >> Antoine
>>>>>>> >>> >>
>>>>>>> >>> >> On Thu, Jun 22, 2017 at 10:42 PM, SenthilKumar K
>>>>>>> >>> >> <senthilec566 at gmail.com>
>>>>>>> >>> >> wrote:
>>>>>>> >>> >>>
>>>>>>> >>> >>> Thanks Bill n Antoine ..
>>>>>>> >>> >>>
>>>>>>> >>> >>>
>>>>>>> >>> >>> Here is the updated one : ( tried without Kafka API ) .
>>>>>>> >>> >>>
>>>>>>> >>> >>> public class HelloWorldServer {
>>>>>>> >>> >>>
>>>>>>> >>> >>> public static void main(final String[] args) {
>>>>>>> >>> >>> Undertow server = Undertow.builder().addHttpListener(8009,
>>>>>>> >>> >>> "localhost").setHandler(new HttpHandler() {
>>>>>>> >>> >>> @Override
>>>>>>> >>> >>> public void handleRequest(final HttpServerExchange exchange)
>>>>>>> throws
>>>>>>> >>> >>> Exception {
>>>>>>> >>> >>> if (exchange.getRequestMethod().equals(Methods.POST)) {
>>>>>>> >>> >>> exchange.getRequestReceiver().receiveFullString(new
>>>>>>> >>> >>> Receiver.FullStringCallback() {
>>>>>>> >>> >>>                    @Override
>>>>>>> >>> >>>                    public void handle(HttpServerExchange
>>>>>>> exchange,
>>>>>>> >>> >>> String
>>>>>>> >>> >>> message) {
>>>>>>> >>> >>>                     System.out.println(" Received String ==>
>>>>>>> >>> >>> "+message);
>>>>>>> >>> >>>                        exchange.getResponseSender().s
>>>>>>> end(message);
>>>>>>> >>> >>>                    }
>>>>>>> >>> >>>                });
>>>>>>> >>> >>> } else {
>>>>>>> >>> >>> exchange.getResponseHeaders().put(Headers.CONTENT_TYPE,
>>>>>>> >>> >>> "text/plain");
>>>>>>> >>> >>> exchange.getResponseSender().send("FAILURE");
>>>>>>> >>> >>> }
>>>>>>> >>> >>> }
>>>>>>> >>> >>> }).build();
>>>>>>> >>> >>> server.start();
>>>>>>> >>> >>> }
>>>>>>> >>> >>> }
>>>>>>> >>> >>>
>>>>>>> >>> >>>
>>>>>>> >>> >>> Oops seems to no improvement :
>>>>>>> >>> >>>
>>>>>>> >>> >>> Running 1m test @ http://localhost:8009/
>>>>>>> >>> >>>   100 threads and 1000 connections
>>>>>>> >>> >>>   Thread Stats   Avg      Stdev     Max   +/- Stdev
>>>>>>> >>> >>>     Latency    25.79ms   22.18ms 289.48ms   67.66%
>>>>>>> >>> >>>     Req/Sec   437.76     61.71     2.30k    80.26%
>>>>>>> >>> >>>   Latency Distribution
>>>>>>> >>> >>>      50%   22.60ms
>>>>>>> >>> >>>      75%   37.83ms
>>>>>>> >>> >>>      90%   55.32ms
>>>>>>> >>> >>>      99%   90.47ms
>>>>>>> >>> >>>   2625607 requests in 1.00m, 2.76GB read
>>>>>>> >>> >>> Requests/sec:  43688.42
>>>>>>> >>> >>> Transfer/sec:     47.08MB
>>>>>>> >>> >>>
>>>>>>> >>> >>>
>>>>>>> >>> >>> :-( :-( ..
>>>>>>> >>> >>>
>>>>>>> >>> >>>
>>>>>>> >>> >>> --Senthil
>>>>>>> >>> >>>
>>>>>>> >>> >>>
>>>>>>> >>> >>> On Fri, Jun 23, 2017 at 1:47 AM, Antoine Girard
>>>>>>> >>> >>> <antoine.girard at ymail.com> wrote:
>>>>>>> >>> >>>>
>>>>>>> >>> >>>> You can use the Receiver API, specifically for that purpose.
>>>>>>> >>> >>>> On the exchange, call: getRequestReceiver();
>>>>>>> >>> >>>>
>>>>>>> >>> >>>> You will get a receiver object:
>>>>>>> >>> >>>>
>>>>>>> >>> >>>>
>>>>>>> >>> >>>> https://github.com/undertow-io
>>>>>>> /undertow/blob/master/core/src/main/java/io/undertow/io/Rece
>>>>>>> iver.java
>>>>>>> >>> >>>>
>>>>>>> >>> >>>> On the receiver you can call: receiveFullString, you have
>>>>>>> to pass it
>>>>>>> >>> >>>> a
>>>>>>> >>> >>>> callback that will be called when the whole body has been
>>>>>>> read.
>>>>>>> >>> >>>>
>>>>>>> >>> >>>> Please share your results when you test this further!
>>>>>>> >>> >>>>
>>>>>>> >>> >>>> Cheers,
>>>>>>> >>> >>>> Antoine
>>>>>>> >>> >>>>
>>>>>>> >>> >>>>
>>>>>>> >>> >>>> On Thu, Jun 22, 2017 at 8:27 PM, SenthilKumar K
>>>>>>> >>> >>>> <senthilec566 at gmail.com>
>>>>>>> >>> >>>> wrote:
>>>>>>> >>> >>>>>
>>>>>>> >>> >>>>> Seems to Reading Request body is wrong , So what is the
>>>>>>> efficient
>>>>>>> >>> >>>>> way
>>>>>>> >>> >>>>> of reading request body in undertow ?
>>>>>>> >>> >>>>>
>>>>>>> >>> >>>>> --Senthil
>>>>>>> >>> >>>>>
>>>>>>> >>> >>>>> On Thu, Jun 22, 2017 at 11:30 PM, SenthilKumar K
>>>>>>> >>> >>>>> <senthilec566 at gmail.com> wrote:
>>>>>>> >>> >>>>>>
>>>>>>> >>> >>>>>> Hello Undertow Dev Team ,
>>>>>>> >>> >>>>>>
>>>>>>> >>> >>>>>>       I have been working on the use case where i should
>>>>>>> create
>>>>>>> >>> >>>>>> simple
>>>>>>> >>> >>>>>> http server to serve 1.5 Million Requests per Second per
>>>>>>> Instance
>>>>>>> >>> >>>>>> ..
>>>>>>> >>> >>>>>>
>>>>>>> >>> >>>>>>
>>>>>>> >>> >>>>>> Here is the benchmark result of Undertow :
>>>>>>> >>> >>>>>>
>>>>>>> >>> >>>>>> Running 1m test @ http://127.0.0.1:8009/
>>>>>>> >>> >>>>>>   20 threads and 40 connections
>>>>>>> >>> >>>>>>   Thread Stats   Avg      Stdev     Max   +/- Stdev
>>>>>>> >>> >>>>>>     Latency     2.51ms   10.75ms 282.22ms   99.28%
>>>>>>> >>> >>>>>>     Req/Sec     1.12k   316.65     1.96k    54.50%
>>>>>>> >>> >>>>>>   Latency Distribution
>>>>>>> >>> >>>>>>      50%    1.43ms
>>>>>>> >>> >>>>>>      75%    2.38ms
>>>>>>> >>> >>>>>>      90%    2.90ms
>>>>>>> >>> >>>>>>      99%   10.45ms
>>>>>>> >>> >>>>>>   1328133 requests in 1.00m, 167.19MB read
>>>>>>> >>> >>>>>> Requests/sec:  22127.92
>>>>>>> >>> >>>>>> Transfer/sec:      2.79MB
>>>>>>> >>> >>>>>>
>>>>>>> >>> >>>>>> This is less compared to other frameworks like Jetty and
>>>>>>> Netty ..
>>>>>>> >>> >>>>>> But
>>>>>>> >>> >>>>>> originally Undertow is high performant http server ..
>>>>>>> >>> >>>>>>
>>>>>>> >>> >>>>>> Hardware details:
>>>>>>> >>> >>>>>> Xeon CPU E3-1270 v5 machine with 4 cores ( Clock 100 MHz,
>>>>>>> Capacity
>>>>>>> >>> >>>>>> 4
>>>>>>> >>> >>>>>> GHz) , Memory : 32 G , Available memory 31 G.
>>>>>>> >>> >>>>>>
>>>>>>> >>> >>>>>> I would need Undertow experts to review the server code
>>>>>>> below and
>>>>>>> >>> >>>>>> advice me on tuning to achieve my goal( ~1.5 Million
>>>>>>> requests/sec
>>>>>>> >>> >>>>>> ).
>>>>>>> >>> >>>>>>
>>>>>>> >>> >>>>>> Server :
>>>>>>> >>> >>>>>>
>>>>>>> >>> >>>>>> Undertow server = Undertow.builder()
>>>>>>> >>> >>>>>>                .addHttpListener(8009, "localhost")
>>>>>>> >>> >>>>>>                .setHandler(new Handler()).build();
>>>>>>> >>> >>>>>> server.start();
>>>>>>> >>> >>>>>>
>>>>>>> >>> >>>>>>
>>>>>>> >>> >>>>>> Handler.Java
>>>>>>> >>> >>>>>>
>>>>>>> >>> >>>>>>     final Pooled<ByteBuffer> pooledByteBuffer =
>>>>>>> >>> >>>>>>
>>>>>>> >>> >>>>>> exchange.getConnection().getBufferPool().allocate();
>>>>>>> >>> >>>>>> final ByteBuffer byteBuffer =
>>>>>>> pooledByteBuffer.getResource();
>>>>>>> >>> >>>>>>    byteBuffer.clear();
>>>>>>> >>> >>>>>>    exchange.getRequestChannel().read(byteBuffer);
>>>>>>> >>> >>>>>>    int pos = byteBuffer.position();
>>>>>>> >>> >>>>>>    byteBuffer.rewind();
>>>>>>> >>> >>>>>>    byte[] bytes = new byte[pos];
>>>>>>> >>> >>>>>>    byteBuffer.get(bytes);
>>>>>>> >>> >>>>>>    String requestBody = new String(bytes,
>>>>>>> Charset.forName("UTF-8")
>>>>>>> >>> >>>>>> );
>>>>>>> >>> >>>>>>    byteBuffer.clear();
>>>>>>> >>> >>>>>>    pooledByteBuffer.free();
>>>>>>> >>> >>>>>>    final PostToKafka post2Kafka = new PostToKafka();
>>>>>>> >>> >>>>>> try {
>>>>>>> >>> >>>>>> post2Kafka.write2Kafka(requestBody);  { This API can
>>>>>>> handle  ~2
>>>>>>> >>> >>>>>> Millions events per sec }
>>>>>>> >>> >>>>>> } catch (Exception e) {
>>>>>>> >>> >>>>>> e.printStackTrace();
>>>>>>> >>> >>>>>> }
>>>>>>> >>> >>>>>>     exchange.getResponseHeaders()
>>>>>>> .put(Headers.CONTENT_TYPE,
>>>>>>> >>> >>>>>> "text/plain");
>>>>>>> >>> >>>>>>     exchange.getResponseSender().send("SUCCESS");
>>>>>>> >>> >>>>>>
>>>>>>> >>> >>>>>>
>>>>>>> >>> >>>>>> --Senthil
>>>>>>> >>> >>>>>
>>>>>>> >>> >>>>>
>>>>>>> >>> >>>>>
>>>>>>> >>> >>>>> _______________________________________________
>>>>>>> >>> >>>>> undertow-dev mailing list
>>>>>>> >>> >>>>> undertow-dev at lists.jboss.org
>>>>>>> >>> >>>>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>>>>>>> >>> >>>>
>>>>>>> >>> >>>>
>>>>>>> >>> >>>
>>>>>>> >>> >>
>>>>>>> >>> >
>>>>>>> >>> >
>>>>>>> >>> > _______________________________________________
>>>>>>> >>> > undertow-dev mailing list
>>>>>>> >>> > undertow-dev at lists.jboss.org
>>>>>>> >>> > https://lists.jboss.org/mailman/listinfo/undertow-dev
>>>>>>> >>
>>>>>>> >>
>>>>>>> >
>>>>>>> _______________________________________________
>>>>>>> undertow-dev mailing list
>>>>>>> undertow-dev at lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>> _______________________________________________
>>>> undertow-dev mailing list
>>>> undertow-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>>>
>>> --
>>> Med venlig hilsen / Best regards
>>>
>>> *Kim Rasmussen*
>>> Partner, IT Architect
>>>
>>> *Asseco Denmark A/S*
>>> Kronprinsessegade 54
>>> DK-1306 Copenhagen K
>>> Mobile: +45 26 16 40 23 <+45%2026%2016%2040%2023>
>>> Ph.: +45 33 36 46 60 <+45%2033%2036%2046%2060>
>>> Fax: +45 33 36 46 61 <+45%2033%2036%2046%2061>
>>>
>>
>> _______________________________________________
>> undertow-dev mailing list
>> undertow-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20170710/fab565c3/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 25115 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/undertow-dev/attachments/20170710/fab565c3/attachment-0002.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 31196 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/undertow-dev/attachments/20170710/fab565c3/attachment-0003.png 


More information about the undertow-dev mailing list