Starting at the end and working back.  This code is very old (and stable).
I wouldn't touch it unless we proved there was a problem with it.

As for the "auto" transport - I've never used it.  I find that the simple
'failover' + 'tcp' works great.  I suspect, based on the name, the auto
transport is auto-detecting.  But why do I have a client connecting to
something for which it doesn't know ahead of time which protocol to use?
Fewer variables = easier to maintain and easier to diagnose problems ;-).

Other uses of the path portion of the url - not a concern; as you guessed,
the path-handling is specific to the transport (identified by scheme)
itself.  If something else is forming TCP url's that don't conform to the
TCP transport's implementation... well - that's just a bad idea.

Art


On Fri, Mar 16, 2018 at 3:07 PM, Max-Julian Pogner <[email protected]>
wrote:

> Ah, now i see!
>
>
> But i wonder: is there a conflict when using the URI like this, because
> there might be already another use of the path-part w.r.t to the active-mq
> configuration. However, it could be argued that this use is restricted to
> the "tcp" scheme and as long as there is no conflicting using _within_ the
> "tcp" scheme it'll work out.
>
> However, what if the "auto" schema was specified in the original config
> file, and maybe the "auto" scheme passes the uri-path along to the detected
> actual scheme, and then two possible actual schemes have surprisingly
> different interpretations of the uri-path.
>
>
> *) the URI location passed as parameter to the createTransport function:
> is the location.getScheme() always "tcp"? even if the original
> configuration is something like "auto://localhost:61616"?
>
> *) if the path part of location indeed has no conflicting purpose, i would
> propose - as a first idea - a patch similar to the diff attached. (Note: i
> didn't compile yet, let alone test)
>
>
> with regards,
>
> Max
>
>
>
> [ w.r.t TcpTransport ]
>
>
> OK, try a url like this:
>
> tcp://localhost:61616/localhost:56565
>
>
> You'll find it connects to localhost:61616 and binds to localhost:56565
>
> I don't see any documentation on the website for this feature though.
>
> Art
>
>
>
>

Reply via email to