Hi Mathias,

The best documentation for this was probably on the original commit note:

http://git.openmama.org/?p=OpenMAMA.git;a=commit;h=e0bba19aae533fb85dfd8a8afe1bce70aa0fc00d

It contains an example transport - all you need to to is change your IPs to the IP address of qpidd (running as described) and then just run your MAMA example applications using -m qpid -tport qpidbroker.

Note it contains a new mama.qpid.transport.<transportname>.type parameter to let the bridge know that this is a broker transport.

Cheers,

Frank

On Fri, Jun 5, 2015 at 1:20 PM, Mathias Kim <Mathias.Kim@...> wrote:

Hi Frank,

 

thanks for looking into this.

We’re now having a look into the qpid bridge with broker. We compiled the bridge but then got stuck using it.

Can you provide documentation on how to use the broker feature with the examples, e.g. capturereplayc?

 

Regards

 

Mathias

 

From: Frank Quinn [mailto:fquinn.ni@...]
Sent: Freitag, 5. Juni 2015 00:39
To: Mathias Kim
Cc: openmama-dev@...
Subject: Re: [Openmama-dev] C# DQPublisher Manager

 

Hi Mathias,

 

Tracking this via http://bugs.openmama.org/show_bug.cgi?id=41 – looks like the proton folks added something in 0.8 to allow you to pull out link information from a messenger which we may be able to take advantage of. It looks like it’ll involve a little expansion of the endpoint code to store more information about an endpoint than just its URI but it should be doable.

 

Cheers,

Frank

 

On Mon, Jun 1, 2015 at 7:03 PM, Frank Quinn <fquinn.ni@...> wrote:

Hi Mathias,

I just tried a scenario similar to what you described with mamapublisherc and mamasubscriberc and I can confirm that I can see the same issue. I'll have a look at what Qpid Proton have to offer in their latest releases to handle this scenario but I remember looking at this before and the problem revolves around the fact that most of the time, our calls to pn_messenger_put and pn_messenger_send don't actually return any error codes in the event of failure. If you look in the code, you'll see that we actually do error checking on those function calls but they don't return any failure.

In fact I just checked and we raised this with the proton guys 2 years ago and they never responded so maybe we should chase that up :) http://qpid.2158936.n2.nabble.com/Detecting-and-capturing-underlying-problems-and-event-with-pn-messenger-td7595635.html

To answer your more specific questions:

 - This is 100% qpid proton / MAMA - not your application's fault

 - The bridge doesn't even know, so we can't tell the application until we get a good answer from the qpid proton folks or find some new mechanism that has been added to handle this

 - This is certainly the case with MAMA but the underlying middleware implementation may not be so flippant as is the case here - all connections in AMQP implementations are connection oriented so they will always be a little more interactive by nature

On a side note, have you tried our test Qpid Proton Broker implementation http://git.openmama.org/?p=OpenMAMA.git;a=shortlog;h=refs/heads/feature-qpid-broker ? I expect it will make a lot of these sorts of problems go away and it will be a lot easier to configure (you don't need to specify a different port for each client, for example). Note that to use that branch, both clients and publishers will need to be compiled against it as the bridge's protocol messages have changed in that version.

 

Cheers,

Frank

 

On Mon, Jun 1, 2015 at 4:00 PM, Mathias Kim <Mathias.Kim@...> wrote:

Hi guys,

we managed to implement the dqpublishermanager and the dqpublisher in C# and most things seem to work well.
Setting up a server app with the qpid bridge works, as well as sending dummy market data to a client. Also, multiple clients can subscribe to the server and all get the messages reasonably fast.
Nevertheless, one huge issue remains:
Whenever one client disconnects, the server continues to send that symbol to that client. So far, this behavior was expected. Unfortunately, as soon as the client destroys its transport, sending takes a lot longer than before. Also, we get an error which depends on the qpid version (SASL header mismatch with v0.8, connection aborted with v0.7). This slows down the whole server until the client connects again. Then the server sends all the messages which it tried so send during the client's off time. As soon this is done, the server is reacting normal and works as before.
We now ask ourselves:
-       Is this problem caused by our implementation of the dqpublisher/manager or is this rather a qpid issue?
-       Is there any way for the server to get notified when a client disconnects/doesn't respond anymore?
-       We initially thought that openmama/qpid just sends out (broadcasts) messages  and doesn't care whether they arrive or not. Is this the case?

Regards

Mathias

-----Original Message-----
From: Ian Bell [mailto:ian.bell@...]
Sent: Dienstag, 14. April 2015 13:49
To: Mathias Kim
Cc: openmama-dev@...
Subject: RE: [Openmama-dev] C# DQPublisher Manager

Hi

Just wondering if you go this sorted?
The first request should route through to the OnNewRequst callback.  As a guess I suspect that the topic is 100% correct, or possibly the callback delegates are not hooked up completely.
Can you supply the code and some logs and I may be able to spot the issue.

Thanks,
Ian Bell

Hapsoft Consulting Ltd
138 Belmont Road, Belfast, BT4 2AQ
Office: +447481866051
Web: www.hapsoftconsulting.co.uk


-----Original Message-----
From: Mathias Kim [mailto:Mathias.Kim@...]
Sent: 25 March 2015 16:40
Subject: [Openmama-dev] C# DQPublisher Manager

Hi guys,

we continued wrapping the dqpublishermanager class in C# but got stuck again. We can create a dqpublishermanager and I also get the onCreate callback. Now, we try to notify the dqpm that there is interest in a certain symbol.
We try to connect to the dqpm via a qpid bridge. Unfortunately, the request never arrives at the dqpm so the OnNewRequest callback never gets called. However, the transport class recognizes the request and notifies us on the console. It even remembers that we previously shows interest in the same symbol. Therefore we like to know whether our implementation is faulty or whether we need to route the request from the transport to the dqpm ourselves.
How does this generally work?

Hope you can help us.
Best regards

Mathias Kim

ETF Analyst

Phone +49 89 442327-191
Mobile +49 171 4152665
mathias.kim at crossflow.de<mailto:mathias.kim at crossflow.de> www.crossflow.de<https://exchange.assenagon.com/owa/redir.aspx?C=tVJgRBMA7UG6CkQ3TBnr2S2utVWiDdIIBlqZxpqCNcW6tUTfy7PQJ8R4pX_VH_LEFJ8GJHinPD8.&URL=http%3a%2f%2fwww.crossflow.de>

Crossflow Financial Advisors GmbH
Sonnenstra?e 19
D-80331 M?nchen
Local Court of Munich HRB 186408
Managing Directors: Markus Deffner, Juergen Fritzen, Erol Steiner



The information contained in this e-mail is confidential and solely for the intended addressee(s). Unauthorised reproduction, disclosure, modification, and/or distribution of this e-mail may be unlawful. If you have received this e-mail in error, please notify the sender immediately and delete it from your system. E-mail transmission cannot be guaranteed to be secure or error free, as messages can be intercepted, corrupted, contain viruses, arrive late or incomplete.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openmama.org/pipermail/openmama-dev/attachments/20150325/6a1d3525/attachment.html>

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