You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by Martin Lichtin <li...@yahoo.com.INVALID> on 2020/12/02 17:21:11 UTC
Connecting to ActiveMQ (classic) server with a browser
There's something seemingly weird going on when connecting with a browser to the ssl-secured Openwire port of an ActiveMQ (classic) server.
Using this Url: https://AMQ-HOST:OPENWIRE-PORT
The browser sends off a GET request and after 30 seconds actually receives a response from ActiveMQ.
The payload shows (some non-printable chars removed):
ActiveMQ TcpNoDelayEnabled SizePrefixDisabled CacheSize ProviderName ActiveMQ StackTraceEnabled
PlatformDetails Java CacheEnabled TightEncodingEnabled MaxFrameSize MaxInactivityDuration
MaxInactivityDurationInitalDelay ProviderVersion 5.15.13
Does this behaviour make sense? I would not expect ActiveMQ to reveal this information.
On ther server side, the log entry shows:
2020-12-02T18:08:58,684 | WARN | InactivityMonitor Worker | Transport | ivemq.broker.TransportConnection 243 | 79 - org.apache.activemq.activemq-osgi - 5.15.13 | Transport Connection to: tcp://172.22.33.45:4793 failed: org.apache.activemq.transport.InactivityIOException: Channel was inactive (no connection attempt made) for too (>30000) long: tcp://172.22.33.45:4793
Re: Connecting to ActiveMQ (classic) server with a browser
Posted by Justin Bertram <jb...@apache.org>.
For what it's worth, you can find some documentation on OpenWire here [1].
That doc is a bit out-dated but most of it is still relevant. It looks like
the best documentation on this subject. The data that your browser received
is part of the WIREFORMAT_INFO which is part of the connection negotiation.
Justin
[1] https://activemq.apache.org/openwire-version-2-specification
On Wed, Dec 2, 2020 at 11:53 AM Justin Bertram <jb...@apache.org> wrote:
> All those details are part of OpenWire's wire format. I'm not 100% sure
> why your browser is getting that response, but any OpenWire client would
> get the same information. My guess is that is part of the OpenWire
> connection negotiation.
>
> After the broker sees that no connection negotiation happens for 30
> seconds it closes the connection.
>
>
> Justin
>
> On Wed, Dec 2, 2020 at 11:21 AM Martin Lichtin <li...@yahoo.com.invalid>
> wrote:
>
>> There's something seemingly weird going on when connecting with a browser
>> to the ssl-secured Openwire port of an ActiveMQ (classic) server.
>>
>> Using this Url: https://AMQ-HOST:OPENWIRE-PORT
>>
>> The browser sends off a GET request and after 30 seconds actually
>> receives a response from ActiveMQ.
>> The payload shows (some non-printable chars removed):
>>
>> ActiveMQ TcpNoDelayEnabled SizePrefixDisabled CacheSize ProviderName
>> ActiveMQ StackTraceEnabled
>> PlatformDetails Java CacheEnabled TightEncodingEnabled MaxFrameSize
>> MaxInactivityDuration
>> MaxInactivityDurationInitalDelay ProviderVersion 5.15.13
>>
>> Does this behaviour make sense? I would not expect ActiveMQ to reveal
>> this information.
>> On ther server side, the log entry shows:
>>
>> 2020-12-02T18:08:58,684 | WARN | InactivityMonitor Worker |
>> Transport | ivemq.broker.TransportConnection 243 |
>> 79 - org.apache.activemq.activemq-osgi - 5.15.13 | Transport Connection to:
>> tcp://172.22.33.45:4793 failed:
>> org.apache.activemq.transport.InactivityIOException: Channel was inactive
>> (no connection attempt made) for too (>30000) long: tcp://
>> 172.22.33.45:4793
>>
>>
Re: Connecting to ActiveMQ (classic) server with a browser
Posted by Justin Bertram <jb...@apache.org>.
All those details are part of OpenWire's wire format. I'm not 100% sure why
your browser is getting that response, but any OpenWire client would get
the same information. My guess is that is part of the OpenWire connection
negotiation.
After the broker sees that no connection negotiation happens for 30 seconds
it closes the connection.
Justin
On Wed, Dec 2, 2020 at 11:21 AM Martin Lichtin <li...@yahoo.com.invalid>
wrote:
> There's something seemingly weird going on when connecting with a browser
> to the ssl-secured Openwire port of an ActiveMQ (classic) server.
>
> Using this Url: https://AMQ-HOST:OPENWIRE-PORT
>
> The browser sends off a GET request and after 30 seconds actually receives
> a response from ActiveMQ.
> The payload shows (some non-printable chars removed):
>
> ActiveMQ TcpNoDelayEnabled SizePrefixDisabled CacheSize ProviderName
> ActiveMQ StackTraceEnabled
> PlatformDetails Java CacheEnabled TightEncodingEnabled MaxFrameSize
> MaxInactivityDuration
> MaxInactivityDurationInitalDelay ProviderVersion 5.15.13
>
> Does this behaviour make sense? I would not expect ActiveMQ to reveal this
> information.
> On ther server side, the log entry shows:
>
> 2020-12-02T18:08:58,684 | WARN | InactivityMonitor Worker |
> Transport | ivemq.broker.TransportConnection 243 |
> 79 - org.apache.activemq.activemq-osgi - 5.15.13 | Transport Connection to:
> tcp://172.22.33.45:4793 failed:
> org.apache.activemq.transport.InactivityIOException: Channel was inactive
> (no connection attempt made) for too (>30000) long: tcp://
> 172.22.33.45:4793
>
>