You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by Sunil Varma <su...@gmail.com> on 2022/05/25 07:37:17 UTC
Artemis- Using Netty http tunnel for SAAS service
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
Re: Artemis- Using Netty http tunnel for SAAS service
Posted by Justin Bertram <jb...@apache.org>.
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 <su...@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 <jb...@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 <su...@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 <jb...@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 <su...@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 <jb...@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.varma@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
>> > > >> >
>> > > >>
>> > > >
>> > >
>> >
>>
>
Re: Artemis- Using Netty http tunnel for SAAS service
Posted by Sunil Varma <su...@gmail.com>.
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 <jb...@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 <su...@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 <jb...@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 <su...@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 <jb...@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.varma@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
> > > >> >
> > > >>
> > > >
> > >
> >
>
Re: Artemis- Using Netty http tunnel for SAAS service
Posted by Justin Bertram <jb...@apache.org>.
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 <su...@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 <jb...@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 <su...@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 <jb...@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 <su...@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
> > >> >
> > >>
> > >
> >
>
Re: Artemis- Using Netty http tunnel for SAAS service
Posted by Sunil Varma <su...@gmail.com>.
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 <jb...@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 <su...@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 <jb...@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 <su...@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
> >> >
> >>
> >
>
Re: Artemis- Using Netty http tunnel for SAAS service
Posted by Justin Bertram <jb...@apache.org>.
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 <su...@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 <jb...@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 <su...@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
>> >
>>
>
Re: Artemis- Using Netty http tunnel for SAAS service
Posted by Sunil Varma <su...@gmail.com>.
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 <jb...@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 <su...@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
> >
>
Re: Artemis- Using Netty http tunnel for SAAS service
Posted by Justin Bertram <jb...@apache.org>.
> 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 <su...@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
>