Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Thomas Segismont
    @tsegismont
    @Stwissel the listener creates a temporary consumer, sends a message with temporary consumer address in payload or headers. the worker verticle then sends messages to temporary address.
    You will have to deal with some "technical" messages between "business" messages in the stream
    like, messages for keeping the temp consumer alive and signaling end of stream
    Arnaud Esteve
    @aesteve
    @Stwissel are you sure you need the eventbus in your use-case ? It's only needed if
    1/ you want to scale the listener verticle differently than the worker verticle (is it a real worker ? if you're using PosgreSQL you can use the async non-blocking driver and make it a standard verticle)
    2/ Verticles (request listener, and postgres "worker") are in different nodes of a cluster
    Sometimes people go straight with "Verticles communicating through event-bus" and thus have to deal with all the "plumbing" (passing messages, etc.) when all they need is simply dependency injection :)
    Arnaud Esteve
    @aesteve
    @tsegismont i migrated a small GraphQL (+Redis) service I wrote months ago (with my own DataFetchers, static graphiql resources, my own GraphQLRouter handling posts) yesterday to 3.8.0 and the built-in vertx-web-graphql.
    1/ It's working like a charm, really great job. Thank you
    2/ it felt really satisfying to remove lots of code :D
    3/ I only kept one thing: MaybeFetcher

    it's a simple utility to use with reactivex Maybe. Kotlin code goes like:

    private fun <T> maybeFetcher(fetcher: (DataFetchingEnvironment) -> Maybe<T>): DataFetcher<CompletionStage<T>> =
            VertxDataFetcher<T> { environment, fut ->
                fetcher(environment).subscribeOnTo(vertx, fut)
            }

    where subscribeOnTo is a very simple extension method:

    fun <T> Maybe<T>.subscribeOnTo(vertx: Vertx, fut: Promise<T>) =
            this.subscribeOn(RxHelper.scheduler(vertx))
                    .subscribe({fut.complete(it)}, {fut.fail(it)})!!
    maybe I missed some built-in bindings between vertx-web-graphql and vertx-rxjava2 though ? :)
    Thomas Segismont
    @tsegismont

    Sometimes people go straight with "Verticles communicating through event-bus" and thus have to deal with all the "plumbing" (passing messages, etc.) when all they need is simply dependency injection :)

    @aesteve true. as with monolith/microservice, very often it's just fine to create a single verticle

    Thanks for the nice comments about Vert.x Web Graphql :bow:
    Here's what's recommended for Rxified API integration https://vertx.io/docs/vertx-web-graphql/java/#_working_with_vert_x_rxified_apis
    Ulf Lilleengen
    @lulf
    Hi, I'm debugging a potential issue in vertx in some environments where the httpServerRequest.bodyHandler handler is not invoked until after a long time after the client is connected. This happens in certain environments and versions but not all. Curl reports the same delay in its time_starttransfer metric, so i'm wondering if there is something people have seen and if its fixed in newer versions or something, or if its simply a matter of bad config on my part. Any suggestions on what I can look at to understand whats happening would also be helpful!
    Arnaud Esteve
    @aesteve
    Thanks!
    Julien Viet
    @vietj
    @lulf can you investigate if the actual connection is not closed ? In Vert.x 4 we have improved it by adding a body() method that returns a Future<Buffer> that will be failed when the connection is closed before the body is fully receivec
    @tsegismont the GraphQL master
    Ulf Lilleengen
    @lulf
    @vietj it is not closed. The request is successful.
    Julien Viet
    @vietj
    @/all there is a current discussion in forum about vertx-grpc model in 4.0 about a contributed where you can give your opinion vert-x3/vertx-grpc#46
    @lulf is the request end handler called ?
    perhaps you overwrote the end handler in your code ? setting a body handler will set a request end handler
    Ulf Lilleengen
    @lulf
    @vietj yes, this is actually using vertx-resteasy integration that you may be familiar with :)
    Julien Viet
    @vietj
    ok, I think it should still work though
    @lulf yes I wrote that a long time ago
    Ulf Lilleengen
    @lulf
    @vietj so what i've done just now is to instrument the VertxRequestHandler and take nanotime when handle(HttpRequest) is called, and when handle(Buffer) of the bodyhandler is called
    Julien Viet
    @vietj
    ok, pay attention to the end handler too
    Ulf Lilleengen
    @lulf
    @vietj i believe the HttpServerRequest.bodyHandler() sets the endHandler to be invoked once the whole body has been read
    @vietj but i find the curl time_starttransfer interesting: "time_starttransfer The time, in seconds, it took from the start until the first byte was just about to be transferred. This includes time_pretransfer and also the time the server needed to calculate the result. "
    @vietj hmm, not clear to me if it means response transfer or request transfer
    @vietj anyway, for reference I tried switching the resteasy server to us sun.Http and it was not introducing this delay.
    Ulf Lilleengen
    @lulf
    @vietj I think I know whats going on now. I used curl -T file.json, which sets "Expect: 100-continue"
    @vietj vertx seems to wait a bit when that is set
    Erol
    @FrEaKmAn
    hi all.. using vertx-js TestSuite, should I somehow explicitly define that test suite failed? because even though it fails, the build in my CI is still successful (unless I need to specify something when I call vertx run?)
    Julien Viet
    @vietj
    @lulf you can handle the 100-Continue
    normally yes indeed it waits a bit
    you can configure it to handle manually too
    see the documentation
    https://vertx.io/docs/vertx-core/java/ look for 100 continue handling
    Stephan H. Wissel
    @Stwissel
    @aesteve @tsegismont Thank you for your input. I really appreciate it. A little more on the use-case. My target is a Domino application server which has NoSQL capabilities and also hosts executable routines (in an ancient language). The interface to it is synchronous but with some polling capabilities.
    The listener part are a configurable set of verticles that listen to different things. I have verticles that provide a http rest api, connect to a Redis and listen for events there, a grpc interface and an MQTT version. All these are individual verticles to keep them isolated. So EventBus seems a natural choice in this setting. All the data flowing back and forth is JSON anyway.
    I'm contemplating to take up the idea with the temporary listener and wrap the whole thing into an Observable which would have the mechanism for data, end and exception nicely defined.
    Ulf Lilleengen
    @lulf
    @vietj ok - thanks for the info! Sorry for sounding the alarm for no reason :-D
    Erol
    @FrEaKmAn

    hi all.. if I run my test suite with vertx run test-verticle.js which contains

    var TestSuite = require("vertx-unit-js/test_suite");
    var suite = TestSuite.create("the_test_suite");
    suite.test("my_test_case", function (context) {
        var s = "value2";
        context.assertEquals("value", s);
    });
    
    var reporters = {
        "reporters": [
            {
                "to": "console"
            }
        ]
    };
    
    var completion = suite.run(reporters);
    completion.handler(function (ar, ar_err) {
        vertx.close();
    });

    is get error that tests failed, but process exit code is still 0

    how could I make it work that exit code is different when it fails?
    should I can something else when tests fail than .close()?
    Erol
    @FrEaKmAn
    ah, I should run it as vertx test.. all works :)
    Julien Viet
    @vietj
    hi @/all Vert.x 3.8.1 has been released https://vertx.io/blog/eclipse-vert-x-3-8-1
    Stephan H. Wissel
    @Stwissel
    @vietj Awsome work. Congratulations to the 3.8.1 release
    Arnaud Esteve
    @aesteve
    Yay! (I upgraded several services 2 weeks ago, time to re-upgrade :D )
    Lazar Bulić
    @pendula95
    Quick question. Why do you declare interface function to have return Type of it Self and mark it with fluent instead of declaring it as void
    @ProxyGen
    @VertxGen
    public interface EventService {
        @Fluent
        EventService send(Handler<AsyncResult<Void>> resultHandler);
    }
    Is there any difference if I do it like this:
    @ProxyGen
    @VertxGen
    public interface EventService {
    
        void send(Handler<AsyncResult<Void>> resultHandler);
    }
    cpdyj
    @cpdyj
    Hello. I'm trying to create an extension. I have a question that why we put context duplicate as internal API? Is it dangerous? I want to sperate context between two request.
    Thank you. :)
    Ruslan Sennov
    @ruslansennov
    @vietj what about io.vertx:protoc-gen-grpc-java ?