Both the client code and broker configuration look fine to me. It seems
pretty clear that the problem is environmental.
Justin
On Wed, Jun 1, 2022 at 3:47 AM Sunil Varma <sunil.k.va...@gmail.com> wrote:
> 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
>> > > >> >
>> > > >>
>> > > >
>> > >
>> >
>>
>
