DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Newsletter
Log In / Join
Refcards Trend Reports
Events Video Library
Refcards
Trend Reports

Events

View Events Video Library

Related

  • The Magic of Quarkus With Vert.x in Reactive Programming

Trending

  • Beyond @Transactional: Solving the Dual-Write Problem in Distributed Microservices
  • When 12 Hours of Offline Changes Collide: Designing Conflict-Safe Mobile Sync
  • Building a Real Pipeline With senro: Monorepos, Caching, and Triggers
  • Evaluating RAG in Production — What the Numbers Actually Revealed

Draft This article hasn't been published, so readers can't see it.

In moderation This article is waiting for review, so readers can't see it yet.

Deleted This article has been deleted, so readers can't see it.

  1. DZone
  2. Software Design and Architecture
  3. Microservices
  4. How to Call the Next Handler in Vert.x

How to Call the Next Handler in Vert.x

We quickly go over how to use Java and Vert.x to limit the amount of traffic handled by our application.

By 
Hüseyin Akdoğan
DZone Core CORE ·
Updated Jun. 05, 19 · Tutorial
Post on X (opens in a new tab) Share on LinkedIn (opens in a new tab)
7.5K Views

Join the DZone community Save articles, join the discussion, and download Refcards and Trend Reports with a free account.

Join for free Already a member? Log in

In Vert.x, when a Router takes an HTTP request, it finds a matching route (if any) and then it calls the handler of the route passing in an instance of RoutingContext. More than one handler can be bounded to a route. This means that you can tell the router to route this context to the next matching route without ending the response in your handler.

Let's assume we want to control and limit the amount of incoming and outgoing network traffic. For example, let’s say we provide a service that is configured to allow 10 requests/second. Similarly, let's assume we use a circuit breaker for fault detection related to the service that the incoming request wants to access. In this case, if the incoming requests exceed the defined limit, or the service is unavailable, it will be necessary to refuse the request.

Calling the next handler offers us a useful way to manage the kind of need that's requiring different controls for the same purpose.

Calling the Next Handler

@Override
public void start(Future<Void> future) {

   final ConfigStoreOptions rateOptions = new ConfigStoreOptions()
           .setType("file")
           .setOptional(true)
           .setConfig(new JsonObject().put("path", System.getProperty("user.dir") + "/src/main/resources/config.json"));

   final ConfigRetrieverOptions options = new ConfigRetrieverOptions().addStore(rateOptions);

   final Router router = RouterHelper.createRouter(vertx, "Hello from rate limiter example!");
   router.get("/limiting").handler(new CircuitBreakerHandler(options));
   router.get("/limiting").handler(new RateLimiterHandler(options));
   HttpServerHelper.createAnHttpServer(vertx, router, config(), future);
}

In the above code, we created two routes for the same path and bounded different handlers. When a GET /limiting request arrives the CircuitBreakerHandler  will work first.

@Override
public void handle(RoutingContext context) {

   final ConfigRetriever retriever = ConfigRetriever.create(context.vertx(), options);

   retriever.getConfig(ar -> {
       if (ar.failed()) {
           log.error("Failed to retrieve the configuration");
       } else {

           final JsonObject config = ar.result();
           final boolean circuitBreaker  =  config.getBoolean("circuitbreaker");

           if (!circuitBreaker) {
               context.next();
           } else {
               context.response()
                       .putHeader(CONTENT_TYPE, HTML_PRODUCE)
                       .setStatusCode(HTTP_SERVICE_UNAVAILABLE)
                       .end("Service unavailable!");
           }
       }
   });
}

In the handler, we are checking firstly to CircuitBreaker and if it's closed we call next method of the RoutingContext. The next method tell the router to route this context to the next matching route (if any). In our example, this will provide calling RateLimiterHandler. I created a repository for this example, you can examine.

Conclusion

Vert.x allows multiple handlers binding to a route. This provides routing the handled context to the next matching route and so encapsulates your handlers for different logic by linking together such as a chain. 

References

  • Vert.x-Web for Java

  • RoutingContext

Vert.x

Opinions expressed by DZone contributors are their own.

Related

  • The Magic of Quarkus With Vert.x in Reactive Programming

Partner Resources

×

Comments

Loading comments

The comments didn't load

Please try again in a moment.

Likes

Loading

The next likes didn't load. Please try again.

The likes didn't load

Please try again in a moment.

See who liked this

Log in or join DZone for free to see who liked this article.

Log in Join for free
  • RSS
  • X
  • Facebook

ABOUT US

  • About DZone
  • Support and feedback
  • Community research

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Core Program
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 3343 Perimeter Hill Drive
  • Suite 215
  • Nashville, TN 37211
  • [email protected]

Let's be friends:

  • RSS
  • X
  • Facebook