On Mi, 2016-09-07 at 15:53 +0100, Robbie Gemmell wrote: > Hi Kai, > > While im inbetween coughs and sneezes here... > > I'm not sure I understand the question. If you could expand a bit it > may help, and perhaps elaborate on what code or behaviour is giving > the impression. > Ok, I'll try to be more specific:
In Hono we have implemented an AMQP 1.0 server as a Verticle that uses vertx-proton. When I deploy this verticle once to a vert.x instance and connect to it from another vertx-proton based AMQP 1.0 client (again, deployed to another vert.x instance) then this works fine, i.e. the client can connect to the server and establish an AMQP connection. However, when I deploy the client verticle twice (in order to scale it up), then only one of the two verticles is able to connect to the server while the other "hangs", i.e. the ProtonClient.connect() call never completes nor fails the handler provided as an argument to it. > It might not once I better understand, but for now this seems more > suited for the Vert.x community: http://vertx.io/community/ > This is actually part of my question :-) Is this intended behavior of vertx-proton or proton-j or is this a limitation of vert.x handling of multiple verticles using TcpServer and TcpClient simultaneously. > Robbie > > On 6 September 2016 at 16:32, Hudalla Kai (INST/ESY1) > <[email protected]> wrote: > > > > Hi, > > > > I have implemented an AMQP 1.0 server on top of vertx-proton (using > > proton-j under the hood). When I connect to the server, I get the > > impression that the server will only accept and establish a single > > connection per client (identified by IP address/port). > > > > Is that right, and is this configurable? > > > > -- > > Mit freundlichen Grüßen / Best regards > > > > Kai Hudalla > > Chief Software Architect > > > > Bosch Software Innovations GmbH > > Schöneberger Ufer 89-91 > > 10785 Berlin > > GERMANY > > www.bosch-si.com > > > > Registered office: Berlin, Register court: Amtsgericht > > Charlottenburg, > > HRB 148411 B; > > Executives: Dr.-Ing. Rainer Kallenbach, Michael Hahn > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] >
