Ok Let me attach again.The attached zip file contains both broker.xml and ArtemisHTTPDebug.java
On Tue, 31 May 2022 at 16:53, Justin Bertram <jbert...@apache.org> wrote:
> Your second email in this thread is the only email with any attachments,
> and it has 3:
>
> - local-server-log-snippet.txt
> - cloud-server-log-snippet.txt
> - broker.xml
>
> I don't see any attachment named "ArtemisHTTPDebug.java" on any email in
> this thread.
>
>
> Justin
>
> On Tue, May 31, 2022 at 10:23 AM Sunil Varma <sunil.k.va...@gmail.com>
> wrote:
>
> > Hi Justin
> > The JMS client code "ArtemisHTTPDebug.java" & the server configuration
> > file "broker.xml" have already been attached in my previous mail along
> with
> > the logs. Let me know if you need anything else.
> >
> > Thanks.
> >
> > On Tue, 31 May 2022 at 16:11, Justin Bertram <jbert...@apache.org>
> wrote:
> >
> > > Can you also provide the JMS client code and configuration you're using
> > as
> > > requested previously?
> > >
> > >
> > > Justin
> > >
> > > On Fri, May 27, 2022 at 7:04 AM Sunil Varma <sunil.k.va...@gmail.com>
> > > wrote:
> > >
> > > > Hi Justin
> > > > Thanks for responding.
> > > > We are using Artemis (version 2.13.0) to send "notifications" to
> > > > interested consumers when data is updated/added in our databases. The
> > use
> > > > case is for a third party to get these "notifications" but as they
> are
> > > > external to our cloud deployment they need to consume via a public
> > > > interface. We are evaluating Artemis REST interface and JMS via http
> > > tunnel.
> > > > I don;t have a stack trace but tried modifying code to add some
> debug
> > > > statements (see log messages marked as SKV) . I have attached
> snippets
> > > from
> > > > two logs; one for local server that works while the other is from the
> > > cloud
> > > > server.
> > > > I observed a noticeable delay from when it gets the first request
> > before
> > > > sending a "bogusresponse" debug statement. I had tried with HTTP with
> > TLS
> > > > ("sslEnabled=true") as well and it fails in the same manner. To make
> > > things
> > > > simpler, I used plain HTTP transport.
> > > >
> > > > Thanks
> > > > Sunil
> > > >
> > > > On Thu, 26 May 2022 at 22:54, Justin Bertram <jbert...@apache.org>
> > > wrote:
> > > >
> > > >> > I tried running a sample JMS program using Netty Http tunnelling
> to
> > > >> connect to the Artemis service via the public interface but the
> > > connection
> > > >> fails...
> > > >>
> > > >> Can you provide the source code and configuration for this sample
> JMS
> > > >> program?
> > > >>
> > > >> > Server side I am seeing some error after some time (not
> > immediately):
> > > >> AMQ212037: Connection failure to /10.5.170.231:48460 has been
> > detected:
> > > >>
> > >
> >
> io.netty.handler.codec.http.HttpObjectAggregator$AggregatedFullHttpRequest
> > > >> cannot be cast to io.netty.buffer.ByteBuf
> [code=GENERIC_EXCEPTION]...
> > > >>
> > > >> Is there a stack-trace associated with this? If so, could you
> provide
> > > it?
> > > >>
> > > >> > Are there any issues using Netty http tunnelling via such proxies?
> > > >>
> > > >> As far as I can tell this is not a normal use-case. In fact, you're
> > the
> > > >> first person I've heard of trying something like this. Therefore,
> it's
> > > >> hard
> > > >> to say if there are "any issues." Given your experience I would say
> > that
> > > >> there are.
> > > >>
> > > >> Aside from the specific problems you're facing, can you elaborate on
> > why
> > > >> you're attempting to connect your JMS application(s) via HTTP
> through
> > an
> > > >> istio proxy? Messaging connections are stateful unlike HTTP
> > connections
> > > >> (which are stateless). It's technically possible to use HTTP, but
> it's
> > > >> certainly not optimal.
> > > >>
> > > >>
> > > >> Justin
> > > >>
> > > >> On Wed, May 25, 2022 at 2:37 AM Sunil Varma <
> sunil.k.va...@gmail.com>
> > > >> wrote:
> > > >>
> > > >> > Hello all!
> > > >> > I am trying to connect to our Artemis service running in the cloud
> > as
> > > a
> > > >> > kubernetes service.
> > > >> > We have istio ingress to expose HTTP and HTTPS routes from
> outside
> > > the
> > > >> > cluster to services within the cluster and some istio routing
> rules
> > to
> > > >> > forward traffic to the appropriate services.
> > > >> >
> > > >> > I tried running a sample JMS program using Netty Http tunnelling
> to
> > > >> connect
> > > >> > to the Artemis service via the public interface but the connection
> > > fails
> > > >> > (ActiveMQConnectionFactory.createConnection) . I have verified the
> > > Http
> > > >> > POST request reaches Artemis and it does send responses (200) but
> > the
> > > >> > connection always fails.
> > > >> > Server side I am seeing some error after some time (not
> > immediately):
> > > >> > AMQ212037: Connection failure to /10.5.170.231:48460 has been
> > > detected:
> > > >> >
> > > >>
> > >
> >
> io.netty.handler.codec.http.HttpObjectAggregator$AggregatedFullHttpRequest
> > > >> > cannot be cast to io.netty.buffer.ByteBuf [code=GENERIC_EXCEPTION]
> > > >> >
> > > >> > Using kubernetes port forwarding the same JMS program using http
> > > tunnel
> > > >> > works. The only difference I think is that the public interface
> goes
> > > via
> > > >> > the istio Envoy proxy.
> > > >> > Are there any issues using Netty http tunnelling via such proxies?
> > > >> > Any pointers on how to debug this issue?
> > > >> > Any help would be highly appreciated as I am kind of lost :).
> > > >> >
> > > >> > Thanks
> > > >> > Sunil
> > > >> >
> > > >>
> > > >
> > >
> >
>
<<attachment: broke-and-code.zip>>
