On Tue, 2017-04-25 at 03:48 +0000, Ryan Sizemore wrote: > I looked at it briefly, but it seemed more complicated than what I > needed. I only need to send messages to the queue; I don't need to > read it or deal with sessions. The send.c example worked with > ServiceBus in 0.6, so I am not sure if this is an intentional or > unintentional change in behavior.
You should bear in mind that the messenger C API does not have a long term future, and there is no one currently maintaining it. This is largely due to a number of intrinsic problems with its implementation (and to a smaller extent to its design). That isd why I suggest you look at the C++ API. If the example is complicated you may well be able to simplify it. > > > Trying the same same thing with 0.7 causes send to hang indefinitely. > It seems related to parsing of the address. The secret (aka password) > for the queue often contains a forward slash, which appears to have > an effect. Using a secret that doesnt contain a slash works, but > without a slash does not. Looking at the history, commit c95c986 > changed with url parsing function, and looks like it might be > related. > > > Thoughts? > There are a number of characters that need to be quoted if you use them non-syntactically in bits of any URL these are '/', ':', '@', '#', '?', '[', ']' (For more details see RFC 3986) and effectively '%' as that is used to quote. So if you want a password with a literal '/' then you need to quote that by using "%2f". So if you are constructing the URL programmatically you will need to URL quote stuff to make a correct URL. If you are using the C++ API you can just set the password connection option directly. I guess that the change you indicate corrected the parsing of the URL string somehow so that it split it apart "more correctly" (although it's still not all that good really). TBH this doesn't really explain indefinite hanging though. Andrew --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
