Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Deven Phillips
    @InfoSec812
    @Niko70210834_twitter I think that it makes OK sense to some extent, but I'm struggling to see how we could generalize it enough to make it usable by a large community.
    But let me restate what I think you are asking to see if I understand what you're going for... You would like a sort of "eventbus router" which allows you to connect compatible versions of Vert.x services to each other inside of Kubernetes?
    And the "routing" rules would be declarative as Kubernetes Custom Resources associated with the proposed Operator?
    In my mind, this sounds like exactly what Service Mesh (Istio) can already accomplish, but it's not Vert.x specific.
    Deven Phillips
    @InfoSec812
    If we were to create a "Mesh" for each set of compatible services and use the mesh to control which versions can connect to which other versions, I think that should solve your need in the way you are leaning. I'm not sure I believe that is the BEST approach, but it might work.
    Deven Phillips
    @InfoSec812

    Additionally, if you are using the Infinispan cluster manager, you can configure jgroups-kubernetes to use label selectors:

    https://github.com/jgroups-extras/jgroups-kubernetes

      <org.jgroups.protocols.kubernetes.KUBE_PING
         port_range="1"
         namespace="${KUBERNETES_NAMESPACE:production}"
         labels="${KUBERNETES_LABELS:cluster=version1_0_0}"
      />
    Nguyễn Tiến Quân
    @tienquanutc
    image.png
    Hi all, I am trying to use HTTPS proxy with vertx-webclient. In ok-http, it work as expected. But vertx-webclient, it throw exception An existing connection was forcibly closed by the remote host.
    Here is a reproducer repo.
    Can someone help me find the problem?
    Niko
    @Niko70210834_twitter
    @InfoSec812 that sounds really plausible.. gotta check Istio, I only know what it is in theory and watched some videos about it. About Infinispan: I saw in your videos that you heavily lean towards Infinispan Cluster Manager and not the default Hazelcast or Zookeeper, which are supported by Vert.x also. We had problems with Hazelcast in the 3.9 Vertx version to make it work consistently: when a client/cluster node shuts down/restarts, the vert.x instances connect to the HZ Cluster again, but event bus connection between them is gone and we can't find out why.. we have then to restart the whole HZ cluster - meaning all verx microservices, which is a pain. Is that maybe the reason you preffer Infinispan? Is infinispan better in conjunction with k8s environment?
    Mritunjay Dubey
    @mddubey

    Hello Everyone,
    We are using the vertx-pg-client(3.9.2) along with webflux which is using project reactor. As the version only provides void execute method, we were using it like below:

    Mono.create(monoSink ->
                    readWriteClient.preparedQuery(INSERT INTO request " +
                "(request_id, cust_id, status, details) VALUES ($1, $2, $3, $4))
                            .execute(Tuple.of(requestId.toString(),
                                    requestedDetail.getId(),
                                    REQUESTED.name(),
                                    new JsonObject(from(requestedDetail))),
                                    handler -> {
                                        if (handler.failed()) {
                                            logger.error(handler.cause().getMessage(), handler.cause());
                                            monoSink.error(new Exception(FAILED_TO_SAVE));
                                            return;
                                        }
                                        monoSink.success();
                                    }))

    We are facing some performance bottlenecks here. Could it be because of void execute method and should we upgrade to latest Future<T> execute will there be any perforamance improvement.

    Also we could not try it because we do not know how to safely convert from a Future to A reactor mono. Any guidance on this will be helpful.

    boulderwebdev
    @boulderwebdev
    When using es4x, if I have my main verticle in src/index.js and I call a method in src/a.js which uses the injected vertx instance (e.g. initializing a session store), is this the same instance as in src/index.js?
    Paulo Lopes
    @pmlopes
    I believe so, the vertx instance is unique however the contexts should be different. One way to confirm this is to call vertx.hashCode() which should print the jvm object hashcode. If they are the same thern they are almost certain the same.
    boulderwebdev
    @boulderwebdev
    :thumbsup:
    boulderwebdev
    @boulderwebdev
    In a graaljs project, how do I install maven packages? For example, suppose I want to use the stripe-java project.
    Also, I found some random edge cases for unexpected/confusing behavior and some edge cases for handling module.exports I found in the wild. Should I post each item as a separate issue on the es4x github repo?
    2 replies
    Johannes Schüth
    @Jotschi
    Does anyone have some resources on how to setup a vert.x GraphQL service which uses the new hibernate RX variant? I want to write a graphql server using these components and it would be helpful to checkout some resources first.
    Mritunjay Dubey
    @mddubey
    Hello one small question. We are using the vertx-pg-client 3.9.2 version. This provides one execute method void execute. We checked the latest versions are providing another execute method which is returning Future<T> execute. Are there any performance benefits if we use this over the old one. Please let us know or any doc regarding this will be much helpful.
    frank-dspeed
    @frank-dspeed:matrix.org
    [m]
    Nope the future<t> Type is only for better compat it does not directly lead to better performance
    a cpu/th can always only run instructions in Serial the async type does not change that general behavior.
    Mritunjay Dubey
    @mddubey
    Thanks for the clarifications @frank-dspeed:matrix.org
    Radim Vansa
    @rvansa
    Hi folks, it seems that Vert.x 4 removed the Buffer.factory method - I don't see that in the migration guide.
    It is not marked as Deprecated in 3.9.1
    Paulo Lopes
    @pmlopes
    @mddubey adding to what has been said, the idea with Future<> is to provide a simpler, easier to read programming model. Instead of having to chain handler you can compose futures, for example:
    apiA.operation(res0 -> {
      apiB.operation(res1 -> {
        apiC.operation(res2 -> {
          apiD.operation(res3 -> {
            ...
         });
      });
    });
    
    // you can do:
    
    apiA.operation()
      .compose(ApiB.operation())
      .compose(ApiC.operation())
      .compose(ApiD.operation())
      .onSuccess(value -> { ... })
      .onFailure(err -> { ... });
    1 reply
    Julien Viet
    @vietj
    This chat is replaced by our Discord server : https://discord.gg/KzEMwP2
    Johannes Schüth
    @Jotschi
    @vietj I think this would be a good info for the MOTD / gitter chat description
    Mritunjay Dubey
    @mddubey
    Hello everyone, We are using vertx-pg-client along with spring-webflux, which is using reacotr-netty from project-reactor under the hood. We integrated with blockhound to check few performance issues and we are getting a blocking call in our stacktrace. Below is the stacktrace:
    2021-04-15 17:09:53,748 ERROR [vert.x-eventloop-thread-0] com.example.demo.requestt.RequestRepository []: Blocking call! java.io.FileInputStream#readBytes
    reactor.blockhound.BlockingOperationError: Blocking call! java.io.FileInputStream#readBytes
        at java.base/java.io.FileInputStream.readBytes(FileInputStream.java)
        at java.base/java.io.FileInputStream.read(FileInputStream.java:279)
        at java.base/sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:284)
        at java.base/sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:326)
        at java.base/sun.nio.cs.StreamDecoder.read(StreamDecoder.java:178)
        at java.base/java.io.InputStreamReader.read(InputStreamReader.java:185)
        at java.base/java.io.BufferedReader.fill(BufferedReader.java:161)
        at java.base/java.io.BufferedReader.readLine(BufferedReader.java:326)
        at java.base/java.io.BufferedReader.readLine(BufferedReader.java:392)
        at io.netty.resolver.dns.UnixResolverDnsServerAddressStreamProvider.parseEtcResolverSearchDomains(UnixResolverDnsServerAddressStreamProvider.java:372)
        at io.netty.resolver.dns.UnixResolverDnsServerAddressStreamProvider.parseEtcResolverSearchDomains(UnixResolverDnsServerAddressStreamProvider.java:353)
        at io.netty.resolver.dns.DnsNameResolver.<clinit>(DnsNameResolver.java:137)
        at io.netty.resolver.dns.DnsNameResolverBuilder.<init>(DnsNameResolverBuilder.java:49)
        at io.netty.resolver.dns.DnsAddressResolverGroup.<init>(DnsAddressResolverGroup.java:61)
        at io.vertx.core.impl.resolver.DnsResolverProvider$1$1.<init>(DnsResolverProvider.java:137)
        at io.vertx.core.impl.resolver.DnsResolverProvider$1.newResolver(DnsResolverProvider.java:137)
        at io.netty.resolver.AddressResolverGroup.getResolver(AddressResolverGroup.java:70)
        at io.netty.bootstrap.Bootstrap.doResolveAndConnect0(Bootstrap.java:194)
        at io.netty.bootstrap.Bootstrap.doResolveAndConnect(Bootstrap.java:162)
        at io.netty.bootstrap.Bootstrap.connect(Bootstrap.java:139)
        at io.vertx.core.net.impl.ChannelProvider.handleConnect(ChannelProvider.java:140)
        at io.vertx.core.net.impl.ChannelProvider.connect(ChannelProvider.java:93)
        at io.vertx.core.net.impl.NetClientImpl.doConnect(NetClientImpl.java:211)
        at io.vertx.core.net.impl.NetClientImpl.doConnect(NetClientImpl.java:168)
        at io.vertx.core.net.impl.NetClientImpl.connect(NetClientImpl.java:157)
        at io.vertx.pgclient.impl.PgConnectionFactory.doConnect(PgConnectionFactory.java:192)
        at io.vertx.pgclient.impl.PgConnectionFactory.connect(PgConnectionFactory.java:119)
        at io.vertx.pgclient.impl.PgConnectionFactory.connectAndInit(PgConnectionFactory.java:105)
        at io.vertx.pgclient.impl.PgPoolImpl.connect(PgPoolImpl.java:47)
        at io.vertx.sqlclient.impl.ConnectionPool.check(ConnectionPool.java:207)
        at io.vertx.sqlclient.impl.ConnectionPool.acquire(ConnectionPool.java:76)
        at io.vertx.sqlclient.impl.PoolBase.schedule(PoolBase.java:88)
        at io.vertx.sqlclient.impl.PoolBase.lambda$schedule$2(PoolBase.java:102)
        at io.vertx.core.impl.ContextImpl.executeTask(ContextImpl.java:366)
        at io.vertx.core.impl.EventLoopContext.lambda$executeAsync$0(EventLoopContext.java:38)
        at io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:164)
        at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:472)
        at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:500)
        at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989)
        at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
        at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
        at java.base/java.lang.Thread.run(Thread.java:834)

    This is how we are using the library, version 3.9.2:

    {
            return Mono.create(monoSink ->
                    pgpool.preparedQuery(INSERT_REQUEST_QUERY)
                            .execute(Tuple.of(requestId.toString(),
                                    requestedDetail.getSubject().getId(),
                                    Status.REQUESTED.name(),
                                    new JsonObject(from(requestedDetail))),
                                    handler -> {
                                        if (handler.failed()) {
                                            logger.error(handler.cause().getMessage(), handler.cause());
                                            return;
                                        }
                                        monoSink.success();
                                    }));
        }

    The blocking calls are supposed to be not there as it severely degrade the performance. Please let us know if we are doing something wrong here.

    Paulo Lopes
    @pml0pes:matrix.org
    [m]
    This is the initialization of the dns resolver. It is during the static class initialization, so it should only happen once per application lifecycle. Usually this isn't critical, just the the agent being pedantic in terms of blocking api usages.
    Kiran Bollepalli
    @kiranbollepalli9
    Hi I am trying to implement gateway using graphql. I am referring to https://tsegismont.github.io/graphql-api-gateway-workshop/ and it worked for me but i need guidence in two things, 1. auth using jwt 2. If i mutation need to save data in two micro services as transaction. How to implement, should we do at gateway level if yes how to do roleback etc. or It should be handled at service level? please suggest
    Kiran Bollepalli
    @kiranbollepalli9

    @jsoneaday @tsegismont any suggestion on it

    Hi I am trying to implement gateway using graphql. I am referring to https://tsegismont.github.io/graphql-api-gateway-workshop/ and it worked for me but i need guidence in two things, 1. auth using jwt 2. If i mutation need to save data in two micro services as transaction. How to implement, should we do at gateway level if yes how to do roleback etc. or It should be handled at service level? please suggest

    Paulo Lopes
    @pmlopes
    @kiranbollepalli9 most of the discussions have moved to discord: https://discord.gg/KzEMwP2 you will probably get more active responses there
    Soheil Pourbafrani
    @ahoora08

    Hi, Using VertX RabbitMQ library, I can see in RabbitMQ console, each connection has only one single channel. I can't find a way to increase the number of channels for a connection. Is it possible in the current implementation?

    Thanks

    Kiran Bollepalli
    @kiranbollepalli9
    Vang
    @return_tweet_twitter
    Hi,
    Is it possible to use flatbuffers for vertx TCP/NetSocket communication?
    Paulo Lopes
    @pmlopes
    @return_tweet_twitter I believe so, a Vert.x Buffer is just a raw memory segment, you can convert to and from whatever you like. So if you can use flatbuffers to read/write to say, for example, a byte[] it should be trivial to achieve that.
    lecogiteur
    @lecogiteur
    Hi, there is some best practice / experience with docker on pool size. We can configure for each container some cpu load. So how to define pool size for event loop / worker / ineternal worker...
    With vert.x 4
    sunqb
    @sunqb
    Hi,guys,do you have encountered this bug:eclipse-vertx/vert.x#3905
    Vang
    @return_tweet_twitter
    Hi,. Is there a way to handle back pressure when we are writting to a netsocket using EventBus?
    What I am looking is to write to a socket from multiple verticals which do some processing and send the data to otherside of the socket.
    Vang
    @return_tweet_twitter
    New JDBCPool doesn't offer SQL options unless we get thr connection out of it and use it.
    aianta
    @aianta
    Has anyone ever had issues with uploading files via MultipartForm using the WebClient? I keep getting a forbidden response from the server I'm uploading to when making the request through vertx, but am able to make the request no problem in Postman...
    Currently trying to compare the request sent from vertx to the postman one. I'm noticing the vertx request seems to lack the 'Content-Length' header.
    Adding it manually didn't work as it seems the file no longer gets attached if I do a putHeader('Content-Length', <size>) before sending the multipart form
    vertx version 3.9.7 for reference
    MaratPL
    @MaratPL

    hello every one
    I have strange problem
    We uses quarkus + grpc + smallrye.
    Also we uses io.vertx.core.impl.ContextInternal.contextData() to propagate headers from grpc server to grpc client
    And everything works fine for simple calls (grpcSercer called -> my business logic -> grpcClent -> some other my business logic with client response -> grpcServer response)
    But now i need to make 2 different calls in parallel (!!!)
    At first I wright code like this

     return Uni.combine().all()
              .unis(grpcClient1.methodName1(parameter1),
                      grpcClient2.methodName2(parameter2))
              .collectFailures()
              .asTuple()
              .onItemOrFailure().transform(this::mergeBothResponses);

    But there are some problems:
    1) Not every grpc client call uses same VertX thread (so no header propagation)
    2) They are not real parallel
    So my question is so:
    How to make several grpc calles parallel and propagate VertX context correctly
    I tried to modify my code to something like:

    Context context = Vertx.vertx().getOrCreateContext();
    CompletableFuture<Long> onMessageCompletion = new CompletableFuture<>();
    context.runOnContext(new Handler<Void>() {
            @Override
            public void handle(Void unused) {
               modifyVertXContext();
               onMessageCompletion.thenCompose(noOp -> grpcClient1.methodName1(parameter1).subscribeAsCompletionStage());
           }
      });
    return Uni.createFrom().completionStage(onMessageCompletion);

    But it does not work as i expected at all T_T

    Soheil Pourbafrani
    @ahoora08

    Hi,
    I'm using Vertx RXJava API and I have an issue when using the worker thread. In normal vertx API we can use vertx.executeBlocking to ask vertx to use worker thread, but I didn't find any equivalent way for rxjava API to assign all operations to the worker threads. In more details let say I have the following example

    pgClient.preparedQuery(query)
                    .rxExecute(Tuple.of(id, name)))
                    .doOnSuccess(i -> System.out.println("1: " + Thread.currentThread().getName()))
                    .observeOn(WORKER_SCHEDULERS)
                    .doOnSuccess(i -> System.out.println("2: " + Thread.currentThread().getName()))

    In the above example, I need to use the worker thread when invoking rxExecute. I think in Rxjava we should use subscribeOn to change the thread of the whole stream but in this case, subscribeOn doesn't switch the thread!!! Using observerOn, it switches thread to worker thread but it affects only the downstream and the database operation still is done by event-loop thread. Can anyone help me with this? Thanks