Date   

Re: Market data subscriptions using qpid broker

Frank Quinn <fquinn.ni@...>
 

Hi Nestor,

Yes this is a strange one - you're right I could only recreate on a transient basis and only with the broker. I have put in a fix which seems to have prevented this behaviour in my environment by adding more forgiving timeouts particularly for the sending of subscription messages which I think may have been getting aborted in-flight.

Could you try the latest code off the OpenMAMA next branch and see if this helps in your environment?

Cheers,
Frank

On Tue, Apr 26, 2016 at 4:27 PM, Macrux <kmacrux@...> wrote:
Hi all,

I've been working with OpenMAMA 2.4.0 and the new Qpid Broker integration with the Java Qpid Broker implementation in Ubuntu 14.04. I've been experiencing some issues when I try to publish market data using capturereplayc. I use the next command

capturereplayc -S TEST -m qpid -tport broker -dictionary data/dictionaries/data.dict -f data/playbacks/openmama_utpcasheuro_capture.5000.10.qpid.mplay -r -v -v -v -v

Issues arise when I run mamalistenc or MamaListen.java example. For instance, with the next arguments they
can't get the dictionary:

mamalistenc -m qpid -tport broker -S TEST -s DE000CM95AU4.EUR.XPAR -v -v -v -v

I got this in mamalistenc console:

...
016-04-26 09:32:44: (15a53740) : deactivateAction(): (WOMBAT.DATA_DICT (DATA_DICT) (0x1152270)): mSubscBridge=(nil)
2016-04-26 09:32:44: (15a53740) : Subscription 0x1152270 is now at state MAMA_SUBSCRIPTION_DEACTIVATED.
2016-04-26 09:32:44: (15a53740) : imageRequest::timeoutCallback (): DATA_DICT: Timeout waiting for recap or initial value (subscription=0x1152270)
2016-04-26 09:32:44: (15a53740) : imageRequest::timeoutCallback (): source=WOMBAT; symbol=DATA_DICT
Timed out waiting for dictionary
Could not create dictionary.

And in the capturereplayc console, I got this:

...
2016-04-26 09:35:50: (f5dbf740) : Starting refresh message mini-cycle
2016-04-26 09:35:50: (f5dbf740) : No refreshes to send
2016-04-26 09:35:56: (f2552700) : qpidBridgeMamaTransportImpl_dispatchThread(): recv-ed
2016-04-26 09:35:56: (f5dbf740) : mamaSubscription_processMsg(): _MDDD.WOMBAT.DATA_DICT: msg = {{MdSubscSymbol,71,DATA_DICT},{MdSubscriptionType,60,4},{MdSubscMsgType,61,5},{MamaAppDataType,17,0},{MdSubscType,5,5},{MdSubscSourceHost,63,127.0.1.1}} subsc (0xacb940)


So I have to read the dictionary directly from file:

mamalistenc -m qpid -tport broker -S TEST -s DE000CM95AU4.EUR.XPAR -v -v -v -v -use_dict_file /home/nmarin/Apps/openmama-2.4.0/data/dictionaries/data.dict

Sometimes It just doesn't work and I got this message:

...
2016-04-26 09:46:53: (cd6a7740) : deactivateAction(): (TEST.DE000CM95AU4.EUR.XPAR (DE000CM95AU4.EUR.XPAR) (0x11113c0)): mSubscBridge=0x112b620
2016-04-26 09:46:53: (cd6a7740) : Subscription 0x11113c0 is now at state MAMA_SUBSCRIPTION_DEACTIVATED.
2016-04-26 09:46:53: (cd6a7740) : imageRequest::timeoutCallback (): DE000CM95AU4.EUR.XPAR: Timeout waiting for recap or initial value (subscription=0x11113c0)
2016-04-26 09:46:53: (cd6a7740) : imageRequest::timeoutCallback (): source=TEST; symbol=DE000CM95AU4.EUR.XPAR
An error occurred creating subscription for DE000CM95AU4.EUR.XPAR: STATUS_TIMEOUT


But sometimes if I restart capturereplayc and mamalistenc it works well. I'm actually a little confused with this behaviour, because sometimes it works, but sometimes doesn't work at all and I have to restart the broker, the capturereplayc or the mamalisten until this works. I've tested using regular transport (pub/sub) and it works perfect, so I think the issues show up only with the broker. I've also tested simple publish and subscribe with mamapublisherc, mamasubscriberc and it works fine.

Thanks for your help.

Nestor





_______________________________________________
Openmama-dev mailing list
Openmama-dev@...
https://lists.openmama.org/mailman/listinfo/openmama-dev



Re: Market data subscriptions using qpid broker

Macrux <kmacrux@...>
 

Hi Frank, everything is running on Ubuntu 14.04, on the same machine. Qpid proton 0.9 and Qpid broker 6.0.1. Thanks.

Regards,

Nestor


On 26 April 2016 at 11:28, Frank Quinn <fquinn.ni@...> wrote:

Hi Nestor,

What versions of the Qpid broker and proton libraries are you using? Everything running on Ubuntu?

Cheers,
Frank


On Tue, 26 Apr 2016 16:27 Macrux, <kmacrux@...> wrote:
Hi all,

I've been working with OpenMAMA 2.4.0 and the new Qpid Broker integration with the Java Qpid Broker implementation in Ubuntu 14.04. I've been experiencing some issues when I try to publish market data using capturereplayc. I use the next command

capturereplayc -S TEST -m qpid -tport broker -dictionary data/dictionaries/data.dict -f data/playbacks/openmama_utpcasheuro_capture.5000.10.qpid.mplay -r -v -v -v -v

Issues arise when I run mamalistenc or MamaListen.java example. For instance, with the next arguments they
can't get the dictionary:

mamalistenc -m qpid -tport broker -S TEST -s DE000CM95AU4.EUR.XPAR -v -v -v -v

I got this in mamalistenc console:

...
016-04-26 09:32:44: (15a53740) : deactivateAction(): (WOMBAT.DATA_DICT (DATA_DICT) (0x1152270)): mSubscBridge=(nil)
2016-04-26 09:32:44: (15a53740) : Subscription 0x1152270 is now at state MAMA_SUBSCRIPTION_DEACTIVATED.
2016-04-26 09:32:44: (15a53740) : imageRequest::timeoutCallback (): DATA_DICT: Timeout waiting for recap or initial value (subscription=0x1152270)
2016-04-26 09:32:44: (15a53740) : imageRequest::timeoutCallback (): source=WOMBAT; symbol=DATA_DICT
Timed out waiting for dictionary
Could not create dictionary.

And in the capturereplayc console, I got this:

...
2016-04-26 09:35:50: (f5dbf740) : Starting refresh message mini-cycle
2016-04-26 09:35:50: (f5dbf740) : No refreshes to send
2016-04-26 09:35:56: (f2552700) : qpidBridgeMamaTransportImpl_dispatchThread(): recv-ed
2016-04-26 09:35:56: (f5dbf740) : mamaSubscription_processMsg(): _MDDD.WOMBAT.DATA_DICT: msg = {{MdSubscSymbol,71,DATA_DICT},{MdSubscriptionType,60,4},{MdSubscMsgType,61,5},{MamaAppDataType,17,0},{MdSubscType,5,5},{MdSubscSourceHost,63,127.0.1.1}} subsc (0xacb940)


So I have to read the dictionary directly from file:

mamalistenc -m qpid -tport broker -S TEST -s DE000CM95AU4.EUR.XPAR -v -v -v -v -use_dict_file /home/nmarin/Apps/openmama-2.4.0/data/dictionaries/data.dict

Sometimes It just doesn't work and I got this message:

...
2016-04-26 09:46:53: (cd6a7740) : deactivateAction(): (TEST.DE000CM95AU4.EUR.XPAR (DE000CM95AU4.EUR.XPAR) (0x11113c0)): mSubscBridge=0x112b620
2016-04-26 09:46:53: (cd6a7740) : Subscription 0x11113c0 is now at state MAMA_SUBSCRIPTION_DEACTIVATED.
2016-04-26 09:46:53: (cd6a7740) : imageRequest::timeoutCallback (): DE000CM95AU4.EUR.XPAR: Timeout waiting for recap or initial value (subscription=0x11113c0)
2016-04-26 09:46:53: (cd6a7740) : imageRequest::timeoutCallback (): source=TEST; symbol=DE000CM95AU4.EUR.XPAR
An error occurred creating subscription for DE000CM95AU4.EUR.XPAR: STATUS_TIMEOUT


But sometimes if I restart capturereplayc and mamalistenc it works well. I'm actually a little confused with this behaviour, because sometimes it works, but sometimes doesn't work at all and I have to restart the broker, the capturereplayc or the mamalisten until this works. I've tested using regular transport (pub/sub) and it works perfect, so I think the issues show up only with the broker. I've also tested simple publish and subscribe with mamapublisherc, mamasubscriberc and it works fine.

Thanks for your help.

Nestor




_______________________________________________
Openmama-dev mailing list
Openmama-dev@...
https://lists.openmama.org/mailman/listinfo/openmama-dev


Re: Market data subscriptions using qpid broker

Frank Quinn <fquinn.ni@...>
 

Hi Nestor,

What versions of the Qpid broker and proton libraries are you using? Everything running on Ubuntu?

Cheers,
Frank


On Tue, 26 Apr 2016 16:27 Macrux, <kmacrux@...> wrote:
Hi all,

I've been working with OpenMAMA 2.4.0 and the new Qpid Broker integration with the Java Qpid Broker implementation in Ubuntu 14.04. I've been experiencing some issues when I try to publish market data using capturereplayc. I use the next command

capturereplayc -S TEST -m qpid -tport broker -dictionary data/dictionaries/data.dict -f data/playbacks/openmama_utpcasheuro_capture.5000.10.qpid.mplay -r -v -v -v -v

Issues arise when I run mamalistenc or MamaListen.java example. For instance, with the next arguments they
can't get the dictionary:

mamalistenc -m qpid -tport broker -S TEST -s DE000CM95AU4.EUR.XPAR -v -v -v -v

I got this in mamalistenc console:

...
016-04-26 09:32:44: (15a53740) : deactivateAction(): (WOMBAT.DATA_DICT (DATA_DICT) (0x1152270)): mSubscBridge=(nil)
2016-04-26 09:32:44: (15a53740) : Subscription 0x1152270 is now at state MAMA_SUBSCRIPTION_DEACTIVATED.
2016-04-26 09:32:44: (15a53740) : imageRequest::timeoutCallback (): DATA_DICT: Timeout waiting for recap or initial value (subscription=0x1152270)
2016-04-26 09:32:44: (15a53740) : imageRequest::timeoutCallback (): source=WOMBAT; symbol=DATA_DICT
Timed out waiting for dictionary
Could not create dictionary.

And in the capturereplayc console, I got this:

...
2016-04-26 09:35:50: (f5dbf740) : Starting refresh message mini-cycle
2016-04-26 09:35:50: (f5dbf740) : No refreshes to send
2016-04-26 09:35:56: (f2552700) : qpidBridgeMamaTransportImpl_dispatchThread(): recv-ed
2016-04-26 09:35:56: (f5dbf740) : mamaSubscription_processMsg(): _MDDD.WOMBAT.DATA_DICT: msg = {{MdSubscSymbol,71,DATA_DICT},{MdSubscriptionType,60,4},{MdSubscMsgType,61,5},{MamaAppDataType,17,0},{MdSubscType,5,5},{MdSubscSourceHost,63,127.0.1.1}} subsc (0xacb940)


So I have to read the dictionary directly from file:

mamalistenc -m qpid -tport broker -S TEST -s DE000CM95AU4.EUR.XPAR -v -v -v -v -use_dict_file /home/nmarin/Apps/openmama-2.4.0/data/dictionaries/data.dict

Sometimes It just doesn't work and I got this message:

...
2016-04-26 09:46:53: (cd6a7740) : deactivateAction(): (TEST.DE000CM95AU4.EUR.XPAR (DE000CM95AU4.EUR.XPAR) (0x11113c0)): mSubscBridge=0x112b620
2016-04-26 09:46:53: (cd6a7740) : Subscription 0x11113c0 is now at state MAMA_SUBSCRIPTION_DEACTIVATED.
2016-04-26 09:46:53: (cd6a7740) : imageRequest::timeoutCallback (): DE000CM95AU4.EUR.XPAR: Timeout waiting for recap or initial value (subscription=0x11113c0)
2016-04-26 09:46:53: (cd6a7740) : imageRequest::timeoutCallback (): source=TEST; symbol=DE000CM95AU4.EUR.XPAR
An error occurred creating subscription for DE000CM95AU4.EUR.XPAR: STATUS_TIMEOUT


But sometimes if I restart capturereplayc and mamalistenc it works well. I'm actually a little confused with this behaviour, because sometimes it works, but sometimes doesn't work at all and I have to restart the broker, the capturereplayc or the mamalisten until this works. I've tested using regular transport (pub/sub) and it works perfect, so I think the issues show up only with the broker. I've also tested simple publish and subscribe with mamapublisherc, mamasubscriberc and it works fine.

Thanks for your help.

Nestor




_______________________________________________
Openmama-dev mailing list
Openmama-dev@...
https://lists.openmama.org/mailman/listinfo/openmama-dev


Market data subscriptions using qpid broker

Macrux <kmacrux@...>
 

Hi all,

I've been working with OpenMAMA 2.4.0 and the new Qpid Broker integration with the Java Qpid Broker implementation in Ubuntu 14.04. I've been experiencing some issues when I try to publish market data using capturereplayc. I use the next command

capturereplayc -S TEST -m qpid -tport broker -dictionary data/dictionaries/data.dict -f data/playbacks/openmama_utpcasheuro_capture.5000.10.qpid.mplay -r -v -v -v -v

Issues arise when I run mamalistenc or MamaListen.java example. For instance, with the next arguments they
can't get the dictionary:

mamalistenc -m qpid -tport broker -S TEST -s DE000CM95AU4.EUR.XPAR -v -v -v -v

I got this in mamalistenc console:

...
016-04-26 09:32:44: (15a53740) : deactivateAction(): (WOMBAT.DATA_DICT (DATA_DICT) (0x1152270)): mSubscBridge=(nil)
2016-04-26 09:32:44: (15a53740) : Subscription 0x1152270 is now at state MAMA_SUBSCRIPTION_DEACTIVATED.
2016-04-26 09:32:44: (15a53740) : imageRequest::timeoutCallback (): DATA_DICT: Timeout waiting for recap or initial value (subscription=0x1152270)
2016-04-26 09:32:44: (15a53740) : imageRequest::timeoutCallback (): source=WOMBAT; symbol=DATA_DICT
Timed out waiting for dictionary
Could not create dictionary.

And in the capturereplayc console, I got this:

...
2016-04-26 09:35:50: (f5dbf740) : Starting refresh message mini-cycle
2016-04-26 09:35:50: (f5dbf740) : No refreshes to send
2016-04-26 09:35:56: (f2552700) : qpidBridgeMamaTransportImpl_dispatchThread(): recv-ed
2016-04-26 09:35:56: (f5dbf740) : mamaSubscription_processMsg(): _MDDD.WOMBAT.DATA_DICT: msg = {{MdSubscSymbol,71,DATA_DICT},{MdSubscriptionType,60,4},{MdSubscMsgType,61,5},{MamaAppDataType,17,0},{MdSubscType,5,5},{MdSubscSourceHost,63,127.0.1.1}} subsc (0xacb940)


So I have to read the dictionary directly from file:

mamalistenc -m qpid -tport broker -S TEST -s DE000CM95AU4.EUR.XPAR -v -v -v -v -use_dict_file /home/nmarin/Apps/openmama-2.4.0/data/dictionaries/data.dict

Sometimes It just doesn't work and I got this message:

...
2016-04-26 09:46:53: (cd6a7740) : deactivateAction(): (TEST.DE000CM95AU4.EUR.XPAR (DE000CM95AU4.EUR.XPAR) (0x11113c0)): mSubscBridge=0x112b620
2016-04-26 09:46:53: (cd6a7740) : Subscription 0x11113c0 is now at state MAMA_SUBSCRIPTION_DEACTIVATED.
2016-04-26 09:46:53: (cd6a7740) : imageRequest::timeoutCallback (): DE000CM95AU4.EUR.XPAR: Timeout waiting for recap or initial value (subscription=0x11113c0)
2016-04-26 09:46:53: (cd6a7740) : imageRequest::timeoutCallback (): source=TEST; symbol=DE000CM95AU4.EUR.XPAR
An error occurred creating subscription for DE000CM95AU4.EUR.XPAR: STATUS_TIMEOUT


But sometimes if I restart capturereplayc and mamalistenc it works well. I'm actually a little confused with this behaviour, because sometimes it works, but sometimes doesn't work at all and I have to restart the broker, the capturereplayc or the mamalisten until this works. I've tested using regular transport (pub/sub) and it works perfect, so I think the issues show up only with the broker. I've also tested simple publish and subscribe with mamapublisherc, mamasubscriberc and it works fine.

Thanks for your help.

Nestor





Re: reserved fields documentation?

Dmitri Fedorov <dfedorov.solace@...>
 

Thanks Frank, no, I don't want a new field, I simply wanted to learn what these fields are.
Yes I could try to figure out from the code, but a little bit of explanation would be very helpful.

Regards,
Dmitri Fedorov
Software Architect
Solace Systems, Inc.
Ottawa, ON Canada

Solace Systems accepts no liability for the content of this email, or for the consequences of any actions taken on the basis of the information provided, unless that information is subsequently confirmed in writing. Any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Solace Systems.

On 22 April 2016 at 08:40, Frank Quinn <f.quinn@...> wrote:

Hi Dmitri,

 

I don’t believe such a thing exists, though I can confirm the reserved fid range ends at 100. Did you have a suggestion for a new field in mind?

 

Cheers,

Frank

 

From: openmama-dev-bounces@... [mailto:openmama-dev-bounces@...] On Behalf Of Dmitri Fedorov
Sent: 19 April 2016 14:39
To: openmama-dev <openmama-dev@...>
Subject: [Openmama-dev] reserved fields documentation?

 

Hi all,

 

Where do I find description of reserved fields listed in reservedfieldsimpl.h and reservedfields.c, please?

 

Thank you.

 

Regards,

Dmitri Fedorov

Software Architect

Solace Systems, Inc.

Ottawa, ON Canada

 

Solace Systems accepts no liability for the content of this email, or for the consequences of any actions taken on the basis of the information provided, unless that information is subsequently confirmed in writing. Any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Solace Systems.


The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to this message and deleting it from your computer. Thank you. SR Labs LLC


Re: reserved fields documentation?

Frank Quinn <f.quinn@...>
 

Hi Dmitri,

 

I don’t believe such a thing exists, though I can confirm the reserved fid range ends at 100. Did you have a suggestion for a new field in mind?

 

Cheers,

Frank

 

From: openmama-dev-bounces@... [mailto:openmama-dev-bounces@...] On Behalf Of Dmitri Fedorov
Sent: 19 April 2016 14:39
To: openmama-dev <openmama-dev@...>
Subject: [Openmama-dev] reserved fields documentation?

 

Hi all,

 

Where do I find description of reserved fields listed in reservedfieldsimpl.h and reservedfields.c, please?

 

Thank you.

 

Regards,

Dmitri Fedorov

Software Architect

Solace Systems, Inc.

Ottawa, ON Canada

 

Solace Systems accepts no liability for the content of this email, or for the consequences of any actions taken on the basis of the information provided, unless that information is subsequently confirmed in writing. Any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Solace Systems.


The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to this message and deleting it from your computer. Thank you. SR Labs LLC


Re: Using Qpid Broker

Frank Quinn <fquinn.ni@...>
 

Thanks for the update, Nestor, glad to see you got to the bottom of it!

Cheers,
Frank

On Thu, Apr 21, 2016 at 5:45 PM, Macrux <kmacrux@...> wrote:
Hi, its me again, I have resolved this just creating a new topic exchange called "MAMA". That's all. Thanks anyway.

Kind regards,

Nestor.


On 21 April 2016 at 11:21, Macrux <kmacrux@...> wrote:
Hi there,

I'm trying to use the Java Qpid Broker implementation with OpenMAMA 2.4.0. On the web management console of the broker I have created a queue called "test" and I've bound it to the "amqp.topic" exchange (that is there by default). As a binding key I'm using "MAMA.*". When I run the mamapublisherc with:

mamapublisherc -m qpid -tport broker

I got this message:

qpidBridgeMamaTransportImpl_start(): Subscribing to topic://127.0.0.1/MAMA/8c60fd18-07db-11e6-b2bd-d8fc939b9a65 : (null)

And it seems to connect correctly, but when I subscribe a client with:

mamasubscriberc -m qpid -tport broker

I got this message:

qpidBridgeMamaTransportImpl_start(): Subscribing to topic://127.0.0.1/MAMA/b45ca894-07db-11e6-8de4-d8fc939b9a65 : (null)

And although it seems to connect correctly to the broker, it doesn't receive anything.

I haven't modified anything in the mama.properties file, so I have an error in the configuration of the broker, I suppose.

Could anyone please give me a hand with this? Thanks in advance.

Nestor.



_______________________________________________
Openmama-dev mailing list
Openmama-dev@...
https://lists.openmama.org/mailman/listinfo/openmama-dev



Re: Using Qpid Broker

Macrux <kmacrux@...>
 

Hi, its me again, I have resolved this just creating a new topic exchange called "MAMA". That's all. Thanks anyway.

Kind regards,

Nestor.

On 21 April 2016 at 11:21, Macrux <kmacrux@...> wrote:
Hi there,

I'm trying to use the Java Qpid Broker implementation with OpenMAMA 2.4.0. On the web management console of the broker I have created a queue called "test" and I've bound it to the "amqp.topic" exchange (that is there by default). As a binding key I'm using "MAMA.*". When I run the mamapublisherc with:

mamapublisherc -m qpid -tport broker

I got this message:

qpidBridgeMamaTransportImpl_start(): Subscribing to topic://127.0.0.1/MAMA/8c60fd18-07db-11e6-b2bd-d8fc939b9a65 : (null)

And it seems to connect correctly, but when I subscribe a client with:

mamasubscriberc -m qpid -tport broker

I got this message:

qpidBridgeMamaTransportImpl_start(): Subscribing to topic://127.0.0.1/MAMA/b45ca894-07db-11e6-8de4-d8fc939b9a65 : (null)

And although it seems to connect correctly to the broker, it doesn't receive anything.

I haven't modified anything in the mama.properties file, so I have an error in the configuration of the broker, I suppose.

Could anyone please give me a hand with this? Thanks in advance.

Nestor.



Using Qpid Broker

Macrux <kmacrux@...>
 

Hi there,

I'm trying to use the Java Qpid Broker implementation with OpenMAMA 2.4.0. On the web management console of the broker I have created a queue called "test" and I've bound it to the "amqp.topic" exchange (that is there by default). As a binding key I'm using "MAMA.*". When I run the mamapublisherc with:

mamapublisherc -m qpid -tport broker

I got this message:

qpidBridgeMamaTransportImpl_start(): Subscribing to topic://127.0.0.1/MAMA/8c60fd18-07db-11e6-b2bd-d8fc939b9a65 : (null)

And it seems to connect correctly, but when I subscribe a client with:

mamasubscriberc -m qpid -tport broker

I got this message:

qpidBridgeMamaTransportImpl_start(): Subscribing to topic://127.0.0.1/MAMA/b45ca894-07db-11e6-8de4-d8fc939b9a65 : (null)

And although it seems to connect correctly to the broker, it doesn't receive anything.

I haven't modified anything in the mama.properties file, so I have an error in the configuration of the broker, I suppose.

Could anyone please give me a hand with this? Thanks in advance.

Nestor.


reserved fields documentation?

Dmitri Fedorov <dfedorov.solace@...>
 

Hi all,

Where do I find description of reserved fields listed in reservedfieldsimpl.h and reservedfields.c, please?

Thank you.

Regards,
Dmitri Fedorov
Software Architect
Solace Systems, Inc.
Ottawa, ON Canada

Solace Systems accepts no liability for the content of this email, or for the consequences of any actions taken on the basis of the information provided, unless that information is subsequently confirmed in writing. Any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Solace Systems.


Re: Deferred Entitlements issue with OpenMAMA 2.4.0

Frank Quinn <fquinn.ni@...>
 

Hi Chris,

If you're going to use the noop bridge as a dev workaround, you'd need to remove the setting up of deferred entitlements from your bridge as well or had you done that already?

Yeah you're hitting code paths that none of our bridges exercise, but we'll work with you in whatever way we can to help resolve - no sinking feeling required :).

I'll await the pull request, then have a proper dive into this.

Cheers,
Frank


On Wed, 6 Apr 2016 22:10 Christopher Morgan, <Christopher.Morgan@...> wrote:

Hi Frank,

 

I have a patch to put into a pull request. I (or a colleague of mine Dmitri) will hopefully it up on git later today or early tomorrow.

 

Thanks for the workaround. Unfortunately, when I use the noop entitlements bridge I get a segmentation fault on another unit test.

The fault occurs in mamaSubscription_processWildCardMsg on a basic wild card subscription created as a part of our bridge’s inbox create. It occurs when self->mSubjectContext.mEntitlementBridge->isAllowed is accessed since mEntitlementBridge is NULL. I looked into the self->mSubjectContext  member and found that it is only set in mamaSubscription_setupBasic and mamaSubscription_getSubjectContext (and mamaSubscription_getSubjectContext is only used in mamaSubscription_processMsg). The code path for basic subscription create do not seem to call the entitlement Bridge subscription create function which I believe sets up the mSubjectContext member. Also mamaSubscription_processMsg appears to handle the entitlement bridge differently this might be useful in mamaSubscription_processWildMsg.

 

I have sinking feeling this is another issue and as it stands though I do not believe this will work as a workaround.

 

Chris Morgan

 

From: Frank Quinn [mailto:fquinn.ni@...]
Sent: April-05-16 5:57 PM
To: Christopher Morgan <Christopher.Morgan@...>
Cc: openmama-dev@...
Subject: Re: [Openmama-dev] Deferred Entitlements issue with OpenMAMA 2.4.0

 

Hi Christopher,

Good spot - yes this is definitely an issue - would appreciate any forthcoming pull requests.

Alternatively as a workaround for now, you can always disable deferred entitlements and just use the noop entitlement bridge now to unblock your testing.

For the record, longer term, I would actually like to move away from the current implementation of deferred entitlements and towards a deferred entitlement bridge which will validate bridge capabilities before permitting the entitlement bridge's enforcement mechanism to be bypassed.

 

Cheers,

Frank

 

On Tue, Apr 5, 2016 at 9:08 PM, Christopher Morgan <Christopher.Morgan@...> wrote:

Hi,

 

I’m developing a bridge with deferred entitlements using OM 2.4.0 but I keep getting an error status MAMA_STATUS_NO_BRIDGE_IMPL when using mamaSubscription_setupBasic. This occurs on any call to mamaSubscription_setupBasic, causing unit test failures and example program to error.

I used mamalistenc and got these logs before the error message:

 

2016-04-05 09:54:23:502: Entitlements checking at subscription creation deferred to myBridge bridge [0x13c6910]

2016-04-05 09:54:23:502: mamaSubscription_setupBasic(): Could not find entitlement bridge!

 

Looking at subscription.c: mamaSubscription_setupBasic it seems that if entitlements are deferred, mamaEntBridge is never set to anything other than NULL making mamaSubscription_setupBasic always return MAMA_STATUS_NO_BRIDGE_IMPL. Is this how deferred entitlements are meant to work?

 

I’m looking for confirmation that this is indeed an issue and if so, I’ll raise an issue/pull request on git hub.

 

Chris Morgan


_______________________________________________
Openmama-dev mailing list
Openmama-dev@...
https://lists.openmama.org/mailman/listinfo/openmama-dev

 


Re: Deferred Entitlements issue with OpenMAMA 2.4.0

cmorgan
 

Hi Frank,

 

I have a patch to put into a pull request. I (or a colleague of mine Dmitri) will hopefully it up on git later today or early tomorrow.

 

Thanks for the workaround. Unfortunately, when I use the noop entitlements bridge I get a segmentation fault on another unit test.

The fault occurs in mamaSubscription_processWildCardMsg on a basic wild card subscription created as a part of our bridge’s inbox create. It occurs when self->mSubjectContext.mEntitlementBridge->isAllowed is accessed since mEntitlementBridge is NULL. I looked into the self->mSubjectContext  member and found that it is only set in mamaSubscription_setupBasic and mamaSubscription_getSubjectContext (and mamaSubscription_getSubjectContext is only used in mamaSubscription_processMsg). The code path for basic subscription create do not seem to call the entitlement Bridge subscription create function which I believe sets up the mSubjectContext member. Also mamaSubscription_processMsg appears to handle the entitlement bridge differently this might be useful in mamaSubscription_processWildMsg.

 

I have sinking feeling this is another issue and as it stands though I do not believe this will work as a workaround.

 

Chris Morgan

 

From: Frank Quinn [mailto:fquinn.ni@...]
Sent: April-05-16 5:57 PM
To: Christopher Morgan <Christopher.Morgan@...>
Cc: openmama-dev@...
Subject: Re: [Openmama-dev] Deferred Entitlements issue with OpenMAMA 2.4.0

 

Hi Christopher,

Good spot - yes this is definitely an issue - would appreciate any forthcoming pull requests.

Alternatively as a workaround for now, you can always disable deferred entitlements and just use the noop entitlement bridge now to unblock your testing.

For the record, longer term, I would actually like to move away from the current implementation of deferred entitlements and towards a deferred entitlement bridge which will validate bridge capabilities before permitting the entitlement bridge's enforcement mechanism to be bypassed.

 

Cheers,

Frank

 

On Tue, Apr 5, 2016 at 9:08 PM, Christopher Morgan <Christopher.Morgan@...> wrote:

Hi,

 

I’m developing a bridge with deferred entitlements using OM 2.4.0 but I keep getting an error status MAMA_STATUS_NO_BRIDGE_IMPL when using mamaSubscription_setupBasic. This occurs on any call to mamaSubscription_setupBasic, causing unit test failures and example program to error.

I used mamalistenc and got these logs before the error message:

 

2016-04-05 09:54:23:502: Entitlements checking at subscription creation deferred to myBridge bridge [0x13c6910]

2016-04-05 09:54:23:502: mamaSubscription_setupBasic(): Could not find entitlement bridge!

 

Looking at subscription.c: mamaSubscription_setupBasic it seems that if entitlements are deferred, mamaEntBridge is never set to anything other than NULL making mamaSubscription_setupBasic always return MAMA_STATUS_NO_BRIDGE_IMPL. Is this how deferred entitlements are meant to work?

 

I’m looking for confirmation that this is indeed an issue and if so, I’ll raise an issue/pull request on git hub.

 

Chris Morgan


_______________________________________________
Openmama-dev mailing list
Openmama-dev@...
https://lists.openmama.org/mailman/listinfo/openmama-dev

 


Re: Deferred Entitlements issue with OpenMAMA 2.4.0

Frank Quinn <fquinn.ni@...>
 

Hi Christopher,

Good spot - yes this is definitely an issue - would appreciate any forthcoming pull requests.

Alternatively as a workaround for now, you can always disable deferred entitlements and just use the noop entitlement bridge now to unblock your testing.

For the record, longer term, I would actually like to move away from the current implementation of deferred entitlements and towards a deferred entitlement bridge which will validate bridge capabilities before permitting the entitlement bridge's enforcement mechanism to be bypassed.

Cheers,
Frank

On Tue, Apr 5, 2016 at 9:08 PM, Christopher Morgan <Christopher.Morgan@...> wrote:

Hi,

 

I’m developing a bridge with deferred entitlements using OM 2.4.0 but I keep getting an error status MAMA_STATUS_NO_BRIDGE_IMPL when using mamaSubscription_setupBasic. This occurs on any call to mamaSubscription_setupBasic, causing unit test failures and example program to error.

I used mamalistenc and got these logs before the error message:

 

2016-04-05 09:54:23:502: Entitlements checking at subscription creation deferred to myBridge bridge [0x13c6910]

2016-04-05 09:54:23:502: mamaSubscription_setupBasic(): Could not find entitlement bridge!

 

Looking at subscription.c: mamaSubscription_setupBasic it seems that if entitlements are deferred, mamaEntBridge is never set to anything other than NULL making mamaSubscription_setupBasic always return MAMA_STATUS_NO_BRIDGE_IMPL. Is this how deferred entitlements are meant to work?

 

I’m looking for confirmation that this is indeed an issue and if so, I’ll raise an issue/pull request on git hub.

 

Chris Morgan


_______________________________________________
Openmama-dev mailing list
Openmama-dev@...
https://lists.openmama.org/mailman/listinfo/openmama-dev



Deferred Entitlements issue with OpenMAMA 2.4.0

cmorgan
 

Hi,

 

I’m developing a bridge with deferred entitlements using OM 2.4.0 but I keep getting an error status MAMA_STATUS_NO_BRIDGE_IMPL when using mamaSubscription_setupBasic. This occurs on any call to mamaSubscription_setupBasic, causing unit test failures and example program to error.

I used mamalistenc and got these logs before the error message:

 

2016-04-05 09:54:23:502: Entitlements checking at subscription creation deferred to myBridge bridge [0x13c6910]

2016-04-05 09:54:23:502: mamaSubscription_setupBasic(): Could not find entitlement bridge!

 

Looking at subscription.c: mamaSubscription_setupBasic it seems that if entitlements are deferred, mamaEntBridge is never set to anything other than NULL making mamaSubscription_setupBasic always return MAMA_STATUS_NO_BRIDGE_IMPL. Is this how deferred entitlements are meant to work?

 

I’m looking for confirmation that this is indeed an issue and if so, I’ll raise an issue/pull request on git hub.

 

Chris Morgan


Re: [Openmama-users] Deal with multiple clients and only one transport in tick42blp bridge

Tom Doust
 

Hi Nestor

 

I think there is nothing inherent in OpenMAMA that prevents you from creating and running multiple instances of the same transport. I have demonstrated this with the Tick42 TREP bridge.

 

Your second solution is not ideal because the single static transport is only going to maintain a single connection (and thread) to Bloomberg.

 

Using your first solution (which I believe is the correct way to go) , where did it fail ?

 

Best regards

 

Tom

 

From: openmama-users-bounces@... [mailto:openmama-users-bounces@...] On Behalf Of Macrux
Sent: 29 March 2016 15:52
To: openmama-dev@...; openmama-users@...
Subject: [Openmama-users] Deal with multiple clients and only one transport in tick42blp bridge

 

Hi there,

I'm working with Bloomberg and the tick42blp bridge, and I have an application which starts multiple clients, each one in a different thread, and each one can be subscribed to different subjects. I had a problem, when the second client started, it failed because the transport with that name (blp_tport) had been already created when the first client started. Then I decided to make the transport static so all clients can use the same instance, but I am not able to destroy the transport until the last client is closed, otherwise, clients that are using the transport will fail.

My question is if this is the correct approach to deal with this situation, or there is a better one?

 

Thanks in advance for any help you could give me.

Kind regards,

Nestor.


Re: Help creating generic plugin

Frank Quinn <fquinn.ni@...>
 

Hi Keith,

Matt has managed to unearth the example code I had in mind - see https://github.com/OpenMAMA/OpenMAMA/pull/159.

Cheers,
Frank

On Mon, Mar 21, 2016 at 11:44 AM, Frank Quinn <fquinn.ni@...> wrote:
Hi Keith,

Sure - please find attached. Went ahead and hit reply all here in case others are also interested.

Cheers,
Frank

On Mon, Mar 21, 2016 at 11:40 AM Keith Rudd <keith.rudd@...> wrote:

Classification: Public

Thanks for getting back on this and following up Frank.

 

The google doc doesn’t work for me – Is it possible to cut and paste the info into an e-mail?

 

Thanks,

Keith

 

From: Frank Quinn [mailto:fquinn.ni@...]
Sent: 15 March 2016 20:30
To: Keith Rudd
Cc: openmama-dev@...
Subject: Re: [Openmama-dev] Help creating generic plugin

 

Hi Keith,

Good question - I actually thought we already had this somewhere but it turns out we don't.

I think it's a sensible thing to build though, so I have raised https://github.com/OpenMAMA/OpenMAMA/issues/157 to make sure we don't forget to do so.

With respect to supporting documentation, the best thing we have at the moment is probably still the google doc referred to in Gary's 2015 post: http://lists.openmama.org/pipermail/openmama-dev/2015-May/001499.html

I'm aware that this, along with Reed's publisher events RFC doc (and others I'm sure) will need to be defragmented at some point in future, though the priority at the moment is getting 2.4.0 out the door.

 

Cheers,

Frank

 

On Mon, Mar 14, 2016 at 10:56 AM, Keith Rudd <keith.rudd@...> wrote:

Classification: Public

Is there any documentation or example code I can refer to for creating a plugin that will get called during initialization?

 

I’m referring to this call in mama.c, mama_openWithPropertiesCount()

 

                mama_initPlugins();

 

Might be useful to have an example plugin included with the source code in the same way example bridges are included.

 

Kind regards,
Keith Rudd

____________________________________________________

image001.gif

Keith Rudd
Vice President | Lead Solution Architect - Market Data Engineering

Deutsche Bank AG, Filiale London
Global Technology
6/8 Bishopsgate, EC2N 4DA London, United Kingdom
Tel. +44 20 754-53366
Mobile +44 7950687412
Email keith.rudd@...


image002.gif

 



---
This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

Please refer to http://www.db.com/en/content/eu_disclosures.htm for additional EU corporate and regulatory disclosures and to http://www.db.com/unitedkingdom/content/privacy.htm for information about privacy.


_______________________________________________
Openmama-dev mailing list
Openmama-dev@...
https://lists.openmama.org/mailman/listinfo/openmama-dev

 



---
This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

Please refer to http://www.db.com/en/content/eu_disclosures.htm for additional EU corporate and regulatory disclosures and to http://www.db.com/unitedkingdom/content/privacy.htm for information about privacy.


Deal with multiple clients and only one transport in tick42blp bridge

Macrux <kmacrux@...>
 

Hi there,

I'm working with Bloomberg and the tick42blp bridge, and I have an application which starts multiple clients, each one in a different thread, and each one can be subscribed to different subjects. I had a problem, when the second client started, it failed because the transport with that name (blp_tport) had been already created when the first client started. Then I decided to make the transport static so all clients can use the same instance, but I am not able to destroy the transport until the last client is closed, otherwise, clients that are using the transport will fail.

My question is if this is the correct approach to deal with this situation, or there is a better one?

Thanks in advance for any help you could give me.

Kind regards,

Nestor.


OpenMAMA 2.4.0 Released

Frank Quinn <fquinn.ni@...>
 

Hi Folks,

We are pleased to announce the final release of OpenMAMA 2.4.0 is now available:

https://github.com/OpenMAMA/OpenMAMA/releases/tag/OpenMAMA-2.4.0-release

As many of you will be aware, we have been working on this OpenMAMA release for months now and it is one of the biggest we have ever assembled - both in terms of features assembled and sheer quantity of new and modified lines of code.

At a high level, the main new functionality is in the following areas:
  • Qpid proton broker support
  • It is now possible to use the qpid payload on non-qpid transports and vice versa
  • Support for Microsoft Visual Studio 2015
  • CentOS / RHEL 7 support
  • Fedora 23 support
  • A default payload type may now be enabled via configuration
  • Several changes made to work with recent OSX
  • Publisher Events now in place to allow asyncronous publish time failures to be handled
  • Dynamic entitlements now defines an entitlement interface which doesn't depend on OEA
  • Dynamic Bridge loading now allows middleware and payload bridges to work without needing to register an enum with OpenMAMA
NB
for bridge developers, see updated wiki page detailing the changes required in the bridge which have changed slightly since our last notification: https://github.com/OpenMAMA/OpenMAMA/wiki/Dynamic-Bridge-Loading. If you have not made these changes since the first release candidate was cut in February, we recommend you do so ASAP to remain current with the project.


As well as new functionality, we have also been undergoing several major operational changes since the last OpenMAMA Release:
  • Migrated Wiki, Issue tracking and code review all in Github out in the open (see http://github.com/OpenMAMA/OpenMAMA)
  • Continuous integration now includes Microsoft Windows builds (see http://ci.openmama.org)
  • All compiler warnings have been removed from our CentOS 6.x builds
  • All supported unit tests should now pass on Avis
Another focal point of this release is a general bug scrub of all outstanding issues, leading to over 100 issues of various sizes being resolved since we moved to Github less than 6 months ago.

A special thanks to all developers, contributors and testers who helped is getting this out door.

Cheers,
Frank


Re: Help creating generic plugin

Frank Quinn <fquinn.ni@...>
 

Hi Keith,

Sure - please find attached. Went ahead and hit reply all here in case others are also interested.

Cheers,
Frank

On Mon, Mar 21, 2016 at 11:40 AM Keith Rudd <keith.rudd@...> wrote:

Classification: Public

Thanks for getting back on this and following up Frank.

 

The google doc doesn’t work for me – Is it possible to cut and paste the info into an e-mail?

 

Thanks,

Keith

 

From: Frank Quinn [mailto:fquinn.ni@...]
Sent: 15 March 2016 20:30
To: Keith Rudd
Cc: openmama-dev@...
Subject: Re: [Openmama-dev] Help creating generic plugin

 

Hi Keith,

Good question - I actually thought we already had this somewhere but it turns out we don't.

I think it's a sensible thing to build though, so I have raised https://github.com/OpenMAMA/OpenMAMA/issues/157 to make sure we don't forget to do so.

With respect to supporting documentation, the best thing we have at the moment is probably still the google doc referred to in Gary's 2015 post: http://lists.openmama.org/pipermail/openmama-dev/2015-May/001499.html

I'm aware that this, along with Reed's publisher events RFC doc (and others I'm sure) will need to be defragmented at some point in future, though the priority at the moment is getting 2.4.0 out the door.

 

Cheers,

Frank

 

On Mon, Mar 14, 2016 at 10:56 AM, Keith Rudd <keith.rudd@...> wrote:

Classification: Public

Is there any documentation or example code I can refer to for creating a plugin that will get called during initialization?

 

I’m referring to this call in mama.c, mama_openWithPropertiesCount()

 

                mama_initPlugins();

 

Might be useful to have an example plugin included with the source code in the same way example bridges are included.

 

Kind regards,
Keith Rudd

____________________________________________________

image001.gif

Keith Rudd
Vice President | Lead Solution Architect - Market Data Engineering

Deutsche Bank AG, Filiale London
Global Technology
6/8 Bishopsgate, EC2N 4DA London, United Kingdom
Tel. +44 20 754-53366
Mobile +44 7950687412
Email keith.rudd@...


image002.gif

 



---
This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

Please refer to http://www.db.com/en/content/eu_disclosures.htm for additional EU corporate and regulatory disclosures and to http://www.db.com/unitedkingdom/content/privacy.htm for information about privacy.


_______________________________________________
Openmama-dev mailing list
Openmama-dev@...
https://lists.openmama.org/mailman/listinfo/openmama-dev

 



---
This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

Please refer to http://www.db.com/en/content/eu_disclosures.htm for additional EU corporate and regulatory disclosures and to http://www.db.com/unitedkingdom/content/privacy.htm for information about privacy.


Re: Help creating generic plugin

Keith Rudd
 

Classification: Public

Thanks for getting back on this and following up Frank.

 

The google doc doesn’t work for me – Is it possible to cut and paste the info into an e-mail?

 

Thanks,

Keith

 

From: Frank Quinn [mailto:fquinn.ni@...]
Sent: 15 March 2016 20:30
To: Keith Rudd
Cc: openmama-dev@...
Subject: Re: [Openmama-dev] Help creating generic plugin

 

Hi Keith,

Good question - I actually thought we already had this somewhere but it turns out we don't.

I think it's a sensible thing to build though, so I have raised https://github.com/OpenMAMA/OpenMAMA/issues/157 to make sure we don't forget to do so.

With respect to supporting documentation, the best thing we have at the moment is probably still the google doc referred to in Gary's 2015 post: http://lists.openmama.org/pipermail/openmama-dev/2015-May/001499.html

I'm aware that this, along with Reed's publisher events RFC doc (and others I'm sure) will need to be defragmented at some point in future, though the priority at the moment is getting 2.4.0 out the door.

 

Cheers,

Frank

 

On Mon, Mar 14, 2016 at 10:56 AM, Keith Rudd <keith.rudd@...> wrote:

Classification: Public

Is there any documentation or example code I can refer to for creating a plugin that will get called during initialization?

 

I’m referring to this call in mama.c, mama_openWithPropertiesCount()

 

                mama_initPlugins();

 

Might be useful to have an example plugin included with the source code in the same way example bridges are included.

 

Kind regards,
Keith Rudd

____________________________________________________



Keith Rudd
Vice President | Lead Solution Architect - Market Data Engineering

Deutsche Bank AG, Filiale London
Global Technology
6/8 Bishopsgate, EC2N 4DA London, United Kingdom
Tel. +44 20 754-53366
Mobile +44 7950687412
Email keith.rudd@...


 



---
This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

Please refer to http://www.db.com/en/content/eu_disclosures.htm for additional EU corporate and regulatory disclosures and to http://www.db.com/unitedkingdom/content/privacy.htm for information about privacy.


_______________________________________________
Openmama-dev mailing list
Openmama-dev@...
https://lists.openmama.org/mailman/listinfo/openmama-dev

 



---
This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

Please refer to http://www.db.com/en/content/eu_disclosures.htm for additional EU corporate and regulatory disclosures and to http://www.db.com/unitedkingdom/content/privacy.htm for information about privacy.

621 - 640 of 2314