Hello, we would like to request an official OpenMAMA enumeration for HMS (Hardware based Messaging System) developed by BCC Group. The suggested enum values (based on the recent version 2.3.3) are: 1.

The byte buffer functions in the Qpid Proton payload implementation only recognized the handles provided by the qpid proton middleware bridge rather than real raw byte arrays. This made the payload in

Hi, When building OM 2.3.3 with entitlements enabled there are some needed changes to SConscripts. I have prepared a patch (mostly adding in the oeac library), and can send that in, but wanted to chec

Hi guys, I'd like to know if there was or there will be some change to the Qpid Proton Bridge such that I can have a publish/subscribe connection in which only one advanced publisher can have multiple

Hi everyone, Could you help me with some questions, please? 1.- If one client or broker house made the connection when the market had been working for a short while, I mean, the client made the connec

Hi Folks, I am planning on dropping support for Qpid Proton 0.5 and 0.6 in the next OpenMAMA release and instead sticking to versions 0.7+. Those guys move quickly and make small changes to interfaces

Hello everybody, I'm trying to figure this: I want to built an OpenMAMA proxy application, similar to MamaProxy, which listen to a source for data and then publish that data in an topic again, but the

There was a realloc bug in AVIS when serializing / deserializing that should be fixed with this patch. Also added a getByteBuffer implementation. Signed-off-by: Frank Quinn <fquinn.ni@...> --- mama/c_

I don't think it's reasonable to expect a unit test around OpenMAMA to support this function call as the nature of transport connectivity will vary across all middlewares. In the instance of Avis, it

This test doesn't really make sense without the use of an inbox so it serves no useful function at the moment, therefore I'm taking it out. Signed-off-by: Frank Quinn <fquinn.ni@...> --- .../src/gunit

MAMA expects iterators to rewind when begin is called, and remain pointing to the first entry after the *first* time that next is called. This change aligns with that requirement. Signed-off-by: Frank

The unit tests assumed that the order of entry into a message field will be identical to the order of extraction while iterating. This proved not to be the case with avis and possibly other payload im

This unit test was testing for the wrong thing. Really all it should have been testing was that the methods work OK when a NULL name is provided, but a fid is non-NULL. Signed-off-by: Frank Quinn <fqu

There was already support for opaque data types but they could not be serialized or deserialized. This patch should remedy this. Signed-off-by: Frank Quinn <fquinn.ni@...> --- mama/c_cpp/src/c/payload

The previous tests pretty much assumed it wasn't implemented in the bridge. This fix adds some basic testing around this functionality for self-describing messages. Signed-off-by: Frank Quinn <fquinn.

This was done with a simple assignment. Will need revised if MAMA ever decide to change their datetime format. Signed-off-by: Frank Quinn <fquinn.ni@...> --- mama/c_cpp/src/c/payload/avismsg/avismsgim

Like qpid, this is simply a call to the internal bridge function to mute the subscription's topic. Signed-off-by: Frank Quinn <fquinn.ni@...> --- mama/c_cpp/src/c/bridge/avis/sub.c | 2 +- 1 file chang

Several unit tests expect MAMA bridges to return standard error codes in various scenarios. This set of updates should bring avis into line with these expectations. Signed-off-by: Frank Quinn <fquinn.

In future, we may want to make this code central. In the meantime, at least making the code identical with qpid should make it easier to maintain. Signed-off-by: Frank Quinn <fquinn.ni@...> --- mama/c

In future, we may want to make this code central. In the meantime, at least making the code identical with qpid should make it easier to maintain. Signed-off-by: Frank Quinn <fquinn.ni@...> --- mama/c