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
>> >
>>
>
