Date   

Re: Asynchronous publisher events

Sam Wilson <Sam.Wilson@...>
 

Hey Glenn, Tom,

I have to agree with Glenn here. I don't think these kind of events
belong alongside regular messages, for a couple of reasons.

For one, simply enough, they aren't messages. They don't originate from
a publisher, they wouldn't travel along the wire, and they probably
would have to be synthesized in the middleware bridge.

Secondly, Tom's solution only works for sendFromInbox. The callback
mechanism is much more general, and would work for non-inbox messages as
well, which is important for our use case.

Assuming we do go ahead with implementing callbacks for asynchronous
publisher events, what needs to be thought about/discussed before moving
on to writing/accepting a patch?

I have two ideas on how to implement this, but keep in mind that I'm
rather new to OpenMAMA and market data in general.

We could use a mamaTransportTopic event, and report the errors with a
callback on the transport.

The other option that I see, which Glenn hinted at, is that we create a
structure similar to mamaMsgCallbacks, called mamaPublisherCallbacks;
and a pair of new methods mamaPublisher_createWithCB and/or
mamaPublisher_setCallbacks. That way we report the error on the specific
publisher.

What are your thoughts?

Regards,
Sam

On 14-11-07 10:57 AM, Glenn McClements wrote:
Hi Tom, Sam,
Before you responded I was considering the use of an inbox as a solution
to Sam’s query but I wasn’t overly keen on it. The reason being that being
rejected by the broker felt very much like a middleware level event, not
an application or market data event so it feels better to me that the
error comes from the middleware as a callback.

Also, responding with a MamaMsg to the sender means assuming the
connection is up and alive, whereas a middleware ACL policy might actually
prevent this from happening. It could be that you form the message on the
client side in the bridge, but this itself feels incorrect as it’s
translating from a middleware level even into a data message. (Also a
minor point is that the MAMA_MSG_TYPE_SEC_STATUS relates to security
status events on a exchange). This is not to say that a message response
is incorrect for RMDS posts however, it’s just a different type of event.


For Sam’s point I do prefer the idea of currently returning a
MAMA_TRANSPORT_PUBLISHER_DISCONNECT, and the transport is currently the
best/only place to do this.

Going forward we could add callbacks to the MamaPublisher object to inform
the client asynchronously of events like this, and
MAMA_TRANSPORT_TOPIC_PUBLISH_DENIED seems reasonable though we would need
to consider how this would be used/interact with the higher level concept
of market data entitlements.

Another related concept is guaranteed or acknowledged messaging, which
would generate other asynchronous event on a publishers. Like the original
issue, this *could* be done at a high level with MamaMsgs being passed
back to acknowledge delivery, but generally this is implemented at the
middleware level so again a publisher callback would be better (with a
handle to the original message as well for context).

Glenn



On 07/11/2014 14:20, "Tom Doust" <tom.doust@tick42.com> wrote:

Hi

In the Tick42 RMDS bridge we address this problem by allowing
applications to use the sendFromInbox methods on a publisher and where
applicable converting the an asynchronous response from the RMDS into a
mama message which is delivered to the inbox.

Although this is intended to support the RMDS message "post" publishing
model that will ACK (or NAK) every message I think it will work for any
middleware that has an asynchronous response mechanism; other publishing
models on RMDS do not have a message reponse.

The message sent to the inbox is arbitrary but it would make sense if
other bridges that used this technique used the same message structure.

The message we use is formed as follows

mamaMsg_addI32(msg, "MdMsgType", 1, MAMA_MSG_TYPE_SEC_STATUS);

mamaMsgStatus status = MAMA_MSG_STATUS_OK;
if(nakCode != RSSL_NAKC_NONE)
{
status = RsslNakCode2MamaMsgStatus(nakCode);
}

mamaMsg_addI32(msg, "MdMsgStatus", 2, status);
mamaMsg_addString(msg, "wSymbol",470, symbol_.c_str());

As you can see we just convert an rssl NAK code to an equivalent mama
code, or use an OK status in the case of an ACK. These include states
like MAMA_MSG_STATUS_NOT_ENTITLED and MAMA_MSG_STATUS_BAD_SYMBOL amongst
a number of others. Obviously the set of code and the mappings are
platform specific

The one thing I think is missing here is a field containing a text string
which could carry more information relevant to the client application.

We would propose that everyone addressing the issue of processing
asynchronous publishing responses takes this approach and that as a
community we agree on a convention for the message content.


Best Regards

Tom Doust




-----Original Message-----
From: openmama-dev-bounces@lists.openmama.org
[mailto:openmama-dev-bounces@lists.openmama.org] On Behalf Of Sam Wilson
Sent: 06 November 2014 7:45 PM
To: openmama-dev@lists.openmama.org
Subject: [Openmama-dev] Asynchronous publisher events

Hey all,

We're looking for a way to notify a mama application asynchronously of
errors while publishing, specifically when the published message was
rejected by the message broker's ACL.

Our API assumes the messages were accepted, and returns immediately.
After some time you might get a connection-level event callback informing
the application that its messages were rejected.

I have two questions.

First off, what is the best way to represent this situation in 2.3.1?
We've been tossing around the idea of just tearing down the connection,
giving the application a MAMA_TRANSPORT_DISCONNECT or a
MAMA_TRANSPORT_PUBLISHER_DISCONNECT, and logging the error. Since the
application or the environment is incorrectly configured, there's not
much that can be done by the application anyways.

Secondly, if openmama were to be extended in the future to support these
kind of events, what would such extensions look like? Perhaps adding a
MAMA_TRANSPORT_TOPIC_PUBLISH_DENIED to the mamaTransportTopicEvent
enumeration?

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


Re: Asynchronous publisher events

Tom Doust
 

Hi Glenn

In many cases publishing a message is transactional and can succeed or fail. Failure does not mean that the connection (for the transport or the item is at fault) in which case connection level call-backs are not the appropriate way to signal a transaction failure.

Even with the ACL failure condition described by Sam could recover without a reconnect from the client if the Solace server supports dynamic changes to the ACL.

On RMDS/TREP a common cause for receiving a NAK is that the user is not permissioned to publish this particular symbol on this source. The may be entitled on other symbols

I'm inclined to agree with you about the use of callbacks over messages but in practical terms the "send-from-inbox / reply-to-inbox" mechanism is in place and is consistently available in the c/cpp, java and .net apis; that’s not true of call-backs. It's also true that messages are generally easier to manage in an asynchronous, multi-threaded environment.

Best regards

Tom

-----Original Message-----
From: Glenn McClements [mailto:g.mcclements@srtechlabs.com]
Sent: 07 November 2014 3:57 PM
To: Tom Doust; Sam Wilson; openmama-dev@lists.openmama.org
Subject: Re: [Openmama-dev] Asynchronous publisher events

Hi Tom, Sam,
Before you responded I was considering the use of an inbox as a solution to Sam’s query but I wasn’t overly keen on it. The reason being that being rejected by the broker felt very much like a middleware level event, not an application or market data event so it feels better to me that the error comes from the middleware as a callback.

Also, responding with a MamaMsg to the sender means assuming the connection is up and alive, whereas a middleware ACL policy might actually prevent this from happening. It could be that you form the message on the client side in the bridge, but this itself feels incorrect as it’s translating from a middleware level even into a data message. (Also a minor point is that the MAMA_MSG_TYPE_SEC_STATUS relates to security status events on a exchange). This is not to say that a message response is incorrect for RMDS posts however, it’s just a different type of event.


For Sam’s point I do prefer the idea of currently returning a MAMA_TRANSPORT_PUBLISHER_DISCONNECT, and the transport is currently the best/only place to do this.

Going forward we could add callbacks to the MamaPublisher object to inform the client asynchronously of events like this, and MAMA_TRANSPORT_TOPIC_PUBLISH_DENIED seems reasonable though we would need to consider how this would be used/interact with the higher level concept of market data entitlements.

Another related concept is guaranteed or acknowledged messaging, which would generate other asynchronous event on a publishers. Like the original issue, this *could* be done at a high level with MamaMsgs being passed back to acknowledge delivery, but generally this is implemented at the middleware level so again a publisher callback would be better (with a handle to the original message as well for context).

Glenn



On 07/11/2014 14:20, "Tom Doust" <tom.doust@tick42.com> wrote:

Hi

In the Tick42 RMDS bridge we address this problem by allowing
applications to use the sendFromInbox methods on a publisher and where
applicable converting the an asynchronous response from the RMDS into a
mama message which is delivered to the inbox.

Although this is intended to support the RMDS message "post" publishing
model that will ACK (or NAK) every message I think it will work for any
middleware that has an asynchronous response mechanism; other
publishing models on RMDS do not have a message reponse.

The message sent to the inbox is arbitrary but it would make sense if
other bridges that used this technique used the same message structure.

The message we use is formed as follows

mamaMsg_addI32(msg, "MdMsgType", 1, MAMA_MSG_TYPE_SEC_STATUS);

mamaMsgStatus status = MAMA_MSG_STATUS_OK;
if(nakCode != RSSL_NAKC_NONE)
{
status = RsslNakCode2MamaMsgStatus(nakCode);
}

mamaMsg_addI32(msg, "MdMsgStatus", 2, status);
mamaMsg_addString(msg, "wSymbol",470, symbol_.c_str());

As you can see we just convert an rssl NAK code to an equivalent mama
code, or use an OK status in the case of an ACK. These include states
like MAMA_MSG_STATUS_NOT_ENTITLED and MAMA_MSG_STATUS_BAD_SYMBOL
amongst a number of others. Obviously the set of code and the mappings
are platform specific

The one thing I think is missing here is a field containing a text
string which could carry more information relevant to the client application.

We would propose that everyone addressing the issue of processing
asynchronous publishing responses takes this approach and that as a
community we agree on a convention for the message content.


Best Regards

Tom Doust




-----Original Message-----
From: openmama-dev-bounces@lists.openmama.org
[mailto:openmama-dev-bounces@lists.openmama.org] On Behalf Of Sam
Wilson
Sent: 06 November 2014 7:45 PM
To: openmama-dev@lists.openmama.org
Subject: [Openmama-dev] Asynchronous publisher events

Hey all,

We're looking for a way to notify a mama application asynchronously of
errors while publishing, specifically when the published message was
rejected by the message broker's ACL.

Our API assumes the messages were accepted, and returns immediately.
After some time you might get a connection-level event callback
informing the application that its messages were rejected.

I have two questions.

First off, what is the best way to represent this situation in 2.3.1?
We've been tossing around the idea of just tearing down the connection,
giving the application a MAMA_TRANSPORT_DISCONNECT or a
MAMA_TRANSPORT_PUBLISHER_DISCONNECT, and logging the error. Since the
application or the environment is incorrectly configured, there's not
much that can be done by the application anyways.

Secondly, if openmama were to be extended in the future to support
these kind of events, what would such extensions look like? Perhaps
adding a MAMA_TRANSPORT_TOPIC_PUBLISH_DENIED to the
mamaTransportTopicEvent enumeration?

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


Re: mamaMsg_toString & mamaMsg_freeString

Damian Maguire <d.maguire@...>
 

Hey Reed,

This was actually discussed a while ago on the mailing lists, after a question from Guy. At the time Frank responded and indicated that the mamaMsg_freeString function was deprecated and that the expectation (and current Qpid Proton bridge implementation) is that bridges will reuse a string buffer for performance reasons. You can see Frank's response to the original question in the chain here: http://lists.openmama.org/pipermail/openmama-dev/2013-November/000740.html

We also raised a Bugzilla ticket to mark freeString as completely deprecated. This is actually a bit more complex than it sounds, but is set to be resolved as part of the enum removal/vtable work, so we'd expect to get it cleaned up in the reasonably near future. You can actually see how this is to be implemented, and some of the complexity associated with it here:  https://github.com/OpenMAMA/OpenMAMA-dynamic/commit/77ae57177c42dbf00f1ba9cf5f858230bb555b83

Let me know if you have any other questions on this.

Thanks,

Damian

On 10/11/14 16:23, Alpert, Reed wrote:

Hi,

 

Question on mamaMsg_toString & mamaMsg_freeString.

 

toString() calls into bridge impl, but freeString() just returns (is not available in the bridge impl mamaPayloadBridgeImpl).

Currently for Tick42 malloc is called in the toString(), and the user is expected to call free() when done with the buffer.

 

Is this the design intended for all bridges?

 

Thanks,

 

Reed.

 


Reed Alpert | Corporate & Investment Bank | Market Data Services | J.P. Morgan | 4 Metrotech Center, 23rd Floor, Brooklyn, NY 11245 | T: 718.242.5198  | M: 917.414.4613 | reed.alpert@...

 

Alternate Contact:  CIB PIM Trading Technology Solutions NA | CIB_PIM_Trading_Technology_Solutions_NA@...

 

This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of JPMorgan Chase & Co., its subsidiaries and affiliates. This transmission may contain information that is proprietary, privileged, confidential and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by JPMorgan Chase & Co., its subsidiaries and affiliates, as applicable, for any loss or damage arising in any way from its use. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. Please refer to http://www.jpmorgan.com/pages/disclosures for disclosures relating to European legal entities.



mamaMsg_toString & mamaMsg_freeString

Alpert, Reed <reed.alpert@...>
 

Hi,

 

Question on mamaMsg_toString & mamaMsg_freeString.

 

toString() calls into bridge impl, but freeString() just returns (is not available in the bridge impl mamaPayloadBridgeImpl).

Currently for Tick42 malloc is called in the toString(), and the user is expected to call free() when done with the buffer.

 

Is this the design intended for all bridges?

 

Thanks,

 

Reed.

 


Reed Alpert | Corporate & Investment Bank | Market Data Services | J.P. Morgan | 4 Metrotech Center, 23rd Floor, Brooklyn, NY 11245 | T: 718.242.5198  | M: 917.414.4613 | reed.alpert@...

 

Alternate Contact:  CIB PIM Trading Technology Solutions NA | CIB_PIM_Trading_Technology_Solutions_NA@...

 

This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of JPMorgan Chase & Co., its subsidiaries and affiliates. This transmission may contain information that is proprietary, privileged, confidential and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by JPMorgan Chase & Co., its subsidiaries and affiliates, as applicable, for any loss or damage arising in any way from its use. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. Please refer to http://www.jpmorgan.com/pages/disclosures for disclosures relating to European legal entities.


Re: Asynchronous publisher events

Glenn McClements <g.mcclements@...>
 

Hi Tom, Sam,
Before you responded I was considering the use of an inbox as a solution
to Sam’s query but I wasn’t overly keen on it. The reason being that being
rejected by the broker felt very much like a middleware level event, not
an application or market data event so it feels better to me that the
error comes from the middleware as a callback.

Also, responding with a MamaMsg to the sender means assuming the
connection is up and alive, whereas a middleware ACL policy might actually
prevent this from happening. It could be that you form the message on the
client side in the bridge, but this itself feels incorrect as it’s
translating from a middleware level even into a data message. (Also a
minor point is that the MAMA_MSG_TYPE_SEC_STATUS relates to security
status events on a exchange). This is not to say that a message response
is incorrect for RMDS posts however, it’s just a different type of event.


For Sam’s point I do prefer the idea of currently returning a
MAMA_TRANSPORT_PUBLISHER_DISCONNECT, and the transport is currently the
best/only place to do this.

Going forward we could add callbacks to the MamaPublisher object to inform
the client asynchronously of events like this, and
MAMA_TRANSPORT_TOPIC_PUBLISH_DENIED seems reasonable though we would need
to consider how this would be used/interact with the higher level concept
of market data entitlements.

Another related concept is guaranteed or acknowledged messaging, which
would generate other asynchronous event on a publishers. Like the original
issue, this *could* be done at a high level with MamaMsgs being passed
back to acknowledge delivery, but generally this is implemented at the
middleware level so again a publisher callback would be better (with a
handle to the original message as well for context).

Glenn

On 07/11/2014 14:20, "Tom Doust" <tom.doust@tick42.com> wrote:

Hi

In the Tick42 RMDS bridge we address this problem by allowing
applications to use the sendFromInbox methods on a publisher and where
applicable converting the an asynchronous response from the RMDS into a
mama message which is delivered to the inbox.

Although this is intended to support the RMDS message "post" publishing
model that will ACK (or NAK) every message I think it will work for any
middleware that has an asynchronous response mechanism; other publishing
models on RMDS do not have a message reponse.

The message sent to the inbox is arbitrary but it would make sense if
other bridges that used this technique used the same message structure.

The message we use is formed as follows

mamaMsg_addI32(msg, "MdMsgType", 1, MAMA_MSG_TYPE_SEC_STATUS);

mamaMsgStatus status = MAMA_MSG_STATUS_OK;
if(nakCode != RSSL_NAKC_NONE)
{
status = RsslNakCode2MamaMsgStatus(nakCode);
}

mamaMsg_addI32(msg, "MdMsgStatus", 2, status);
mamaMsg_addString(msg, "wSymbol",470, symbol_.c_str());

As you can see we just convert an rssl NAK code to an equivalent mama
code, or use an OK status in the case of an ACK. These include states
like MAMA_MSG_STATUS_NOT_ENTITLED and MAMA_MSG_STATUS_BAD_SYMBOL amongst
a number of others. Obviously the set of code and the mappings are
platform specific

The one thing I think is missing here is a field containing a text string
which could carry more information relevant to the client application.

We would propose that everyone addressing the issue of processing
asynchronous publishing responses takes this approach and that as a
community we agree on a convention for the message content.


Best Regards

Tom Doust




-----Original Message-----
From: openmama-dev-bounces@lists.openmama.org
[mailto:openmama-dev-bounces@lists.openmama.org] On Behalf Of Sam Wilson
Sent: 06 November 2014 7:45 PM
To: openmama-dev@lists.openmama.org
Subject: [Openmama-dev] Asynchronous publisher events

Hey all,

We're looking for a way to notify a mama application asynchronously of
errors while publishing, specifically when the published message was
rejected by the message broker's ACL.

Our API assumes the messages were accepted, and returns immediately.
After some time you might get a connection-level event callback informing
the application that its messages were rejected.

I have two questions.

First off, what is the best way to represent this situation in 2.3.1?
We've been tossing around the idea of just tearing down the connection,
giving the application a MAMA_TRANSPORT_DISCONNECT or a
MAMA_TRANSPORT_PUBLISHER_DISCONNECT, and logging the error. Since the
application or the environment is incorrectly configured, there's not
much that can be done by the application anyways.

Secondly, if openmama were to be extended in the future to support these
kind of events, what would such extensions look like? Perhaps adding a
MAMA_TRANSPORT_TOPIC_PUBLISH_DENIED to the mamaTransportTopicEvent
enumeration?

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


Re: Asynchronous publisher events

Tom Doust
 

Hi

In the Tick42 RMDS bridge we address this problem by allowing applications to use the sendFromInbox methods on a publisher and where applicable converting the an asynchronous response from the RMDS into a mama message which is delivered to the inbox.

Although this is intended to support the RMDS message "post" publishing model that will ACK (or NAK) every message I think it will work for any middleware that has an asynchronous response mechanism; other publishing models on RMDS do not have a message reponse.

The message sent to the inbox is arbitrary but it would make sense if other bridges that used this technique used the same message structure.

The message we use is formed as follows

mamaMsg_addI32(msg, "MdMsgType", 1, MAMA_MSG_TYPE_SEC_STATUS);

mamaMsgStatus status = MAMA_MSG_STATUS_OK;
if(nakCode != RSSL_NAKC_NONE)
{
status = RsslNakCode2MamaMsgStatus(nakCode);
}

mamaMsg_addI32(msg, "MdMsgStatus", 2, status);
mamaMsg_addString(msg, "wSymbol",470, symbol_.c_str());

As you can see we just convert an rssl NAK code to an equivalent mama code, or use an OK status in the case of an ACK. These include states like MAMA_MSG_STATUS_NOT_ENTITLED and MAMA_MSG_STATUS_BAD_SYMBOL amongst a number of others. Obviously the set of code and the mappings are platform specific

The one thing I think is missing here is a field containing a text string which could carry more information relevant to the client application.

We would propose that everyone addressing the issue of processing asynchronous publishing responses takes this approach and that as a community we agree on a convention for the message content.


Best Regards

Tom Doust

-----Original Message-----
From: openmama-dev-bounces@lists.openmama.org [mailto:openmama-dev-bounces@lists.openmama.org] On Behalf Of Sam Wilson
Sent: 06 November 2014 7:45 PM
To: openmama-dev@lists.openmama.org
Subject: [Openmama-dev] Asynchronous publisher events

Hey all,

We're looking for a way to notify a mama application asynchronously of errors while publishing, specifically when the published message was rejected by the message broker's ACL.

Our API assumes the messages were accepted, and returns immediately.
After some time you might get a connection-level event callback informing the application that its messages were rejected.

I have two questions.

First off, what is the best way to represent this situation in 2.3.1?
We've been tossing around the idea of just tearing down the connection, giving the application a MAMA_TRANSPORT_DISCONNECT or a MAMA_TRANSPORT_PUBLISHER_DISCONNECT, and logging the error. Since the application or the environment is incorrectly configured, there's not much that can be done by the application anyways.

Secondly, if openmama were to be extended in the future to support these kind of events, what would such extensions look like? Perhaps adding a MAMA_TRANSPORT_TOPIC_PUBLISH_DENIED to the mamaTransportTopicEvent enumeration?

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


Asynchronous publisher events

Sam Wilson <Sam.Wilson@...>
 

Hey all,

We're looking for a way to notify a mama application asynchronously of
errors while publishing, specifically when the published message was
rejected by the message broker's ACL.

Our API assumes the messages were accepted, and returns immediately.
After some time you might get a connection-level event callback
informing the application that its messages were rejected.

I have two questions.

First off, what is the best way to represent this situation in 2.3.1?
We've been tossing around the idea of just tearing down the connection,
giving the application a MAMA_TRANSPORT_DISCONNECT or a
MAMA_TRANSPORT_PUBLISHER_DISCONNECT, and logging the error. Since the
application or the environment is incorrectly configured, there's not
much that can be done by the application anyways.

Secondly, if openmama were to be extended in the future to support these
kind of events, what would such extensions look like? Perhaps adding a
MAMA_TRANSPORT_TOPIC_PUBLISH_DENIED to the mamaTransportTopicEvent
enumeration?

Thanks,
Sam


Re: Possible bug with MamaSubscription.java

Gary Molloy <g.molloy@...>
 

Hi Chad,

 

Thanks for your email.  We’ve taken a look at MamaSubscription.java and it does indeed look like there is an issue with the management of the closure when using setupSubscription.

 

The fix seems straight forward enough, but will require some testing to ensure it works as expected.  Could I ask you to raise this issue in Bugzilla so that we can track it?  If you could also provide a patch (along with your testing) we can try to get it pushed through a little quicker.

 

Thanks,

Gary

 

 

 

Gary Molloy

SR.LABS Proven High Speed Electronic Trading Solutions

g.molloy@...

 

From: openmama-dev-bounces@... [mailto:openmama-dev-bounces@...] On Behalf Of Meyer, Chad J
Sent: 23 October 2014 20:29
To: openmama-dev@...
Subject: [Openmama-dev] Possible bug with MamaSubscription.java

 

Hi,

 

I’ve been testing the setupSubscription and createSubscription methods found in MamaSubscription.java. Key difference between the two is that setupSubscription is used when a subscription is created but not activated yet where createSubscription creates and activates the subscription.

 

In the setupSubscription, the closure is passed into the JNI layer instead of saving it in the java layer like createSubscription. Without saving this closure in the java layer, the value doesn’t seem to be passed back properly from the JNI layer causing issues.

 

Is this a typo in MamaSubscription.java or is the JNI layer supposed to pass the closure back to the JAVA layer once the subscription is activated?

 

Regards,

 

Chad Meyer | Corporate & Investment Bank | PIM Market Data Services | J.P. Morgan | 4 Metrotech Center 23rd Floor Brooklyn, NY 11201 | Tel: (718) 242-5165 | M: (215) 801-2606 | chad.j.meyer@...

 

This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of JPMorgan Chase & Co., its subsidiaries and affiliates. This transmission may contain information that is proprietary, privileged, confidential and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by JPMorgan Chase & Co., its subsidiaries and affiliates, as applicable, for any loss or damage arising in any way from its use. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. Please refer to http://www.jpmorgan.com/pages/disclosures for disclosures relating to European legal entities.


Re: VectorChar and VectorBool field type enumerator

Alireza Assadzadeh <Alireza.Assadzadeh@...>
 

On Wednesday, October 29, 2014 at 12:45 PM, Damian Maguire <damian@openmama.org> wrote:

Awesome, looks really great Alireza. I'll take a look through the patches attached to the Bugzilla
and provide any feedback there. 
Great. Thanks.


Obviously you've put a lot of effort into the testing here, really nice work on that. What platform's
have you been looking at? Just Linux, or any Windows testing as well?
For this I was using primarily 64-bit Linux (Fedora 20, x86_64) and that's where I did most of the testing, including the unit testing.

On Windows, I did a build for mamda with qpid for 64-bit and tested it with capturereplayc, mamalistenc, and bookticker to ensure there is no regressions.

--Alireza


Re: [PATCH 2.3.1] Wombat: Add wombatQueue_deallocate

Damian Maguire <d.maguire@...>
 

Cheers for this Sam.

At a quick look the code all looks reasonable. Have you performed any
testing around the changes? It seems like a good candidate for some unit
tests - most likely within the queuetest.c code under
common/src/c_cpp/gunittest/c - just to ensure we have expected behaviour
under typical conditions.

Thanks,

D

On 29/10/14 19:33, Sam Wilson wrote:
Hey,

Here is a patch that adds wombatQueue_deallocate, which makes it
possible to reclaim resources if wombatQueue_create fails.

Cheers,
Sam

diff --git a/common/c_cpp/src/c/queue.c b/common/c_cpp/src/c/queue.c
index d955b2b..c2ef48f 100644
--- a/common/c_cpp/src/c/queue.c
+++ b/common/c_cpp/src/c/queue.c
@@ -164,14 +164,27 @@ wombatQueue_destroy (wombatQueue queue)
result = WOMBAT_QUEUE_SEM_ERR;
}

- wInterlocked_destroy (&impl->mUnblocking);
-
wthread_mutex_destroy( &impl->mLock);
+
+ if (WOMBAT_QUEUE_OK == result)
+ {
+ return wombatQueue_deallocate(queue);
+ }
+ else
+ {
+ return result;
+ }
+}
+
+wombatQueueStatus
+wombatQueue_deallocate (wombatQueue queue)
+{
+ wombatQueueImpl *impl = (wombatQueueImpl*)queue;
+ wInterlocked_destroy (&impl->mUnblocking);
free (impl);
return WOMBAT_QUEUE_OK;
}

-
wombatQueueStatus
wombatQueue_setMaxSize (wombatQueue queue, unsigned int value)
{
diff --git a/common/c_cpp/src/c/wombat/queue.h
b/common/c_cpp/src/c/wombat/queue.h
index 79b75e9..caafddb 100644
--- a/common/c_cpp/src/c/wombat/queue.h
+++ b/common/c_cpp/src/c/wombat/queue.h
@@ -73,11 +73,24 @@ wombatQueue_create (wombatQueue queue, uint32_t
maxSize, uint32_t initialSize,
uint32_t growBySize);

/**
- * Destroy the Queue.
+ * Destroy the Queue, and free any memory associated
+ * with the Queue.
+ *
+ * wombatQueue_create() must have been successfully called
+ * before calling this method.
*/
COMMONExpDLL wombatQueueStatus
wombatQueue_destroy (wombatQueue queue);

+/**
+ * Free any memory associated with the Queue.
+ *
+ * Unless wombatQueue_create() failed, prefer calling
+ * wombatQueue_destroy().
+ */
+COMMONExpDLL wombatQueueStatus
+wombatQueue_deallocate(wombatQueue queue);
+
/**
* Set the maximum size of the queue. WOMBAT_QUEUE_MAX_SIZE is the maximum
* queue size permitted and the default value. This value should be a
multiple
diff --git a/mama/c_cpp/src/c/bridge/qpid/queue.c
b/mama/c_cpp/src/c/bridge/qpid/queue.c
index 5618b27..f12b0cf 100644
--- a/mama/c_cpp/src/c/bridge/qpid/queue.c
+++ b/mama/c_cpp/src/c/bridge/qpid/queue.c
@@ -137,7 +137,7 @@ qpidBridgeMamaQueue_create (queueBridge* queue,
mama_log (MAMA_LOG_LEVEL_ERROR,
"qpidBridgeMamaQueue_create (): "
"Failed to create underlying queue.");
- wombatQueue_destroy (impl->mQueue);
+ wombatQueue_deallocate (impl->mQueue);
free (impl);
return MAMA_STATUS_PLATFORM;
}
diff --git a/mama/c_cpp/src/c/conflation/manager.c
b/mama/c_cpp/src/c/conflation/manager.c
index db6b409..476db09 100644
--- a/mama/c_cpp/src/c/conflation/manager.c
+++ b/mama/c_cpp/src/c/conflation/manager.c
@@ -78,7 +78,12 @@ mamaConflationManager_create (mamaConflationManager mgr)
return MAMA_STATUS_NOMEM;

if (wombatQueue_create (impl->mMsgQueue, 0, 0, 0) != WOMBAT_QUEUE_OK)
+ {
+ wombatQueue_deallocate(impl->mMsgQueue);
+ impl->mMsgQueue = NULL;
+
return MAMA_STATUS_CONFLATE_ERROR;
+ }

status = mamaMsg_create (&impl->mMsg);


[PATCH 2.3.1] Wombat: Add wombatQueue_deallocate

Sam Wilson <Sam.Wilson@...>
 

Hey,

Here is a patch that adds wombatQueue_deallocate, which makes it
possible to reclaim resources if wombatQueue_create fails.

Cheers,
Sam

diff --git a/common/c_cpp/src/c/queue.c b/common/c_cpp/src/c/queue.c
index d955b2b..c2ef48f 100644
--- a/common/c_cpp/src/c/queue.c
+++ b/common/c_cpp/src/c/queue.c
@@ -164,14 +164,27 @@ wombatQueue_destroy (wombatQueue queue)
result = WOMBAT_QUEUE_SEM_ERR;
}

- wInterlocked_destroy (&impl->mUnblocking);
-
wthread_mutex_destroy( &impl->mLock);
+
+ if (WOMBAT_QUEUE_OK == result)
+ {
+ return wombatQueue_deallocate(queue);
+ }
+ else
+ {
+ return result;
+ }
+}
+
+wombatQueueStatus
+wombatQueue_deallocate (wombatQueue queue)
+{
+ wombatQueueImpl *impl = (wombatQueueImpl*)queue;
+ wInterlocked_destroy (&impl->mUnblocking);
free (impl);
return WOMBAT_QUEUE_OK;
}

-
wombatQueueStatus
wombatQueue_setMaxSize (wombatQueue queue, unsigned int value)
{
diff --git a/common/c_cpp/src/c/wombat/queue.h
b/common/c_cpp/src/c/wombat/queue.h
index 79b75e9..caafddb 100644
--- a/common/c_cpp/src/c/wombat/queue.h
+++ b/common/c_cpp/src/c/wombat/queue.h
@@ -73,11 +73,24 @@ wombatQueue_create (wombatQueue queue, uint32_t
maxSize, uint32_t initialSize,
uint32_t growBySize);

/**
- * Destroy the Queue.
+ * Destroy the Queue, and free any memory associated
+ * with the Queue.
+ *
+ * wombatQueue_create() must have been successfully called
+ * before calling this method.
*/
COMMONExpDLL wombatQueueStatus
wombatQueue_destroy (wombatQueue queue);

+/**
+ * Free any memory associated with the Queue.
+ *
+ * Unless wombatQueue_create() failed, prefer calling
+ * wombatQueue_destroy().
+ */
+COMMONExpDLL wombatQueueStatus
+wombatQueue_deallocate(wombatQueue queue);
+
/**
* Set the maximum size of the queue. WOMBAT_QUEUE_MAX_SIZE is the maximum
* queue size permitted and the default value. This value should be a
multiple
diff --git a/mama/c_cpp/src/c/bridge/qpid/queue.c
b/mama/c_cpp/src/c/bridge/qpid/queue.c
index 5618b27..f12b0cf 100644
--- a/mama/c_cpp/src/c/bridge/qpid/queue.c
+++ b/mama/c_cpp/src/c/bridge/qpid/queue.c
@@ -137,7 +137,7 @@ qpidBridgeMamaQueue_create (queueBridge* queue,
mama_log (MAMA_LOG_LEVEL_ERROR,
"qpidBridgeMamaQueue_create (): "
"Failed to create underlying queue.");
- wombatQueue_destroy (impl->mQueue);
+ wombatQueue_deallocate (impl->mQueue);
free (impl);
return MAMA_STATUS_PLATFORM;
}
diff --git a/mama/c_cpp/src/c/conflation/manager.c
b/mama/c_cpp/src/c/conflation/manager.c
index db6b409..476db09 100644
--- a/mama/c_cpp/src/c/conflation/manager.c
+++ b/mama/c_cpp/src/c/conflation/manager.c
@@ -78,7 +78,12 @@ mamaConflationManager_create (mamaConflationManager mgr)
return MAMA_STATUS_NOMEM;

if (wombatQueue_create (impl->mMsgQueue, 0, 0, 0) != WOMBAT_QUEUE_OK)
+ {
+ wombatQueue_deallocate(impl->mMsgQueue);
+ impl->mMsgQueue = NULL;
+
return MAMA_STATUS_CONFLATE_ERROR;
+ }

status = mamaMsg_create (&impl->mMsg);


Re: VectorChar and VectorBool field type enumerator

Damian Maguire
 

Awesome, looks really great Alireza. I'll take a look through the patches attached to the Bugzilla and provide any feedback there. 

Obviously you've put a lot of effort into the testing here, really nice work on that. What platform's have you been looking at? Just Linux, or any Windows testing as well?

Thanks, 

Damian 

On Mon, Oct 27, 2014 at 3:15 PM, Alireza Assadzadeh <Alireza.Assadzadeh@...> wrote:

Hi Damian,

 

I have raised Bugzilla ticket 168 (http://bugs.openmama.org/show_bug.cgi?id=168) and provided a patch to address this for C/C++ for the first stage.

 

Thanks.

 

--Alireza

 

From: Damian Maguire [mailto:damian@...]
Sent: Friday, September 19, 2014 11:32 AM
To: Alireza Assadzadeh
Cc: openmama-dev@...
Subject: Re: [Openmama-dev] VectorChar and VectorBool field type enumerator

 

Hey Alireza,

 

Thanks for sending this through, and sorry about the delayed response. In this case, I agree that these values should be added to the mamaFieldType enum, and their implementations should be completed across all the languages. 

 

At this stage you've really got two options - either raise a Bugzilla ticket and we'll see about getting it added when we have a chance, or submit a patch yourself which addresses the problems. For the patching option, that can be approached in stages easily enough - beginning with the enum updates (and associated mamaFieldTypeToString and stringToMamaFieldType changes, along with anything else which may misbehave given the new values), then filling in each of the language gaps in further commits.

 

Obviously we're happy to assist if you go down the route of patching yourself, just drop us a mail and we'll lend a hand.

 

Cheers, 

 

Damian

 

On Fri, Sep 5, 2014 at 8:35 PM, Alireza Assadzadeh <Alireza.Assadzadeh@...> wrote:

Hi folks,

 

I noticed that VectorChar and VectorBool do not have  a field type enumerator  in Mama (i.e. mamaFieldType enum in mama/fielddesc.h). Also, the related code for VectorChar and VectorBool in C/ C++, C#, JNI does not have the type related implementations for these vector types as compared to other vector types, such as VectorU32 (enumerator: MAMA_FIELD_TYPE_VECTOR_U32).

 

I imagine these types may not be widely and there are alternatives field types for them(e.g. Opaque, String and unsinged integer).

 

Should VectorChar and VectorBool  types be included in the mamaFieldType enum? For example with the numbers shown below:

 

<code>

diff --git a/mama/c_cpp/src/c/mama/fielddesc.h b/mama/c_cpp/src/c/mama/fielddesc.h

index e3af6e1..a374489 100644

--- a/mama/c_cpp/src/c/mama/fielddesc.h

+++ b/mama/c_cpp/src/c/mama/fielddesc.h

@@ -90,6 +90,8 @@ typedef enum mamaFieldType_

     MAMA_FIELD_TYPE_PRICE         =   27,

 

     /** Array type support */

+    MAMA_FIELD_TYPE_VECTOR_BOOL   =   29,

+    MAMA_FIELD_TYPE_VECTOR_CHAR   =   30,

     MAMA_FIELD_TYPE_VECTOR_I8     =   34,

     MAMA_FIELD_TYPE_VECTOR_U8     =   35,

     MAMA_FIELD_TYPE_VECTOR_I16    =   36,

</code>

 

And then also have the corresponding type related changes in the rest of Mama codebase?

 

Regards,.

 

--Alireza


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

 



Re: Wombat Queue Destroy

Damian Maguire
 

Hey Sam,

Personally I would be inclined towards the addition of wombatQueue_deallocate, and then having this called within the context of the existing wombatQueue_destroy. This would result in no change to behaviour for current client applications (destroy would free the memory as it currently does, so a separate call to deallocate would not be needed), but would allow applications to clean up memory where the allocate has succeeded but create has failed (as in your example).

Thanks, 

Damian  



On Tue, Oct 28, 2014 at 2:36 PM, Sam Wilson <Sam.Wilson@...> wrote:
Hey Damian,

I'm just getting around to looking at this now. Would you prefer a patch that adds wombatQueue_deallocate, or one that merges both wombatQueue_allocate and wombatQueue_create into wombatQueue_allocate and makes wombatQueue_create a dummy function?

The advantage of the first option is that the API works more like it was intended, but it will break any current users of wombat queues.

The second option retains backward compatibility, but you end up losing the benefits of having separate allocate/create functions.

Thanks,
Sam


On 14-09-03 05:34 AM, Damian Maguire wrote:
Hey Sam,

Unfortunately this is a weakness in the API for the Wombat Queue implementation - it really should have a wombatQueue_deallocate, but it isn't presently available. If you'd like to raise an issue in bugzilla (bugs.openmama.org) we can look at getting it added. Better yet, we'd be happy to accept a patch which addresses the issue in the queue.

Thanks, 

Damian


On Tue, Sep 2, 2014 at 7:20 PM, Sam Wilson <Sam.Wilson@...> wrote:
Hello!

I'm trying to use Wombat Queue, but I can't figure out how to safely
free a queue when the creation fails. Here's my example:

     wombatQueue queue;
     wombatQueueStatus status = wombatQueue_allocate(&queue);
     if (WOMBAT_QUEUE_OK != status) {
         return; // log the error state or what have you
     }

     status = wombatQueue_create(queue, MAX_SIZE, INITIAL_SIZE,
                                 CHUNK_SIZE);
     if (WOMBAT_QUEUE_OK != status) {
         wombatQueue_destroy(queue); // Doesn't work because the
                                     // queue hasn't been created.

         // So how do I free the memory allocated by
         // wombatQueue_allocate?
     }

Thanks for your help,
Sam
_______________________________________________
Openmama-dev mailing list
Openmama-dev@...
https://lists.openmama.org/mailman/listinfo/openmama-dev




Re: [PATCH 2.3.1] MamaPublisher: Overloaded MamaPublisher create method

Damian Maguire <d.maguire@...>
 

Thanks Chad, we'll take a look.

D

On 28/10/14 19:43, Meyer, Chad J wrote:

Hi Damian,

 

I have attached a patch in the bugzilla ticket containing a new JUnit test case for testing the new create method.

 

Regards,

 

Chad Meyer| Corporate & Investment Bank | PIM Market Data Services | J.P. Morgan| 4 Metrotech Center 23rd Floor Brooklyn, NY 11201 | Tel: (718) 242-5165 | M: (215) 801-2606 | chad.j.meyer@...

 

 

 

From: Damian Maguire [mailto:d.maguire@...]
Sent: Thursday, October 23, 2014 10:34 AM
To: Meyer, Chad J; Damian Maguire
Cc: openmama-dev@...; Glenn McClements
Subject: Re: [Openmama-dev] [PATCH 2.3.1] MamaPublisher: Overloaded MamaPublisher create method

 

Thanks for the ping Chad, I'll get looking at this as soon as I can and let you know if we have any questions.

Cheers,

Damian

On 23/10/14 15:10, Meyer, Chad J wrote:

Hi Damian,

 

Added comments about a week ago to the Bugzilla ticket referenced below regarding what I did for testing. Please let me know if you need more evidence of testing.

 

Regards,

 

Chad Meyer| Corporate & Investment Bank | PIM Market Data Services | J.P. Morgan| 4 Metrotech Center 23rd Floor Brooklyn, NY 11201 | Tel: (718) 242-5165 | M: (215) 801-2606 | chad.j.meyer@...

 

 

From: Damian Maguire [mailto:damian@...]
Sent: Thursday, September 25, 2014 10:09 AM
To: Meyer, Chad J
Cc: Glenn McClements; openmama-dev@...
Subject: Re: [Openmama-dev] [PATCH 2.3.1] MamaPublisher: Overloaded MamaPublisher create method

 

Hey Chad, 

 

I was just taking a look over this again, and decided that I'd stick it into Bugzilla to keep track of it there. If you'd like to sign up for an account you can add yourself as a CC to BZ164. We can follow up with any other required information there (though the main thing outstanding remains some evidence of testing, as mentioned in my previous mail).

 

Cheers, 

 

Damian

 

On Thu, Sep 18, 2014 at 11:56 AM, Damian Maguire <damian@...> wrote:

Cheers for the new patch Chad, looks good. 

 

At this stage we really need two things to progress getting this into OpenMAMA - firstly, can you raise a Bugzilla ticket, just to make it a bit easier to track the progress of the patch. Secondly, can you provide some evidence of testing? Generally we'd ask for unit tests, but the Java framework needs a bit of work, so in this case can you show a simple example application which demonstrates the usage of the new API? 

 

Thanks again for the contribution.

 

Damian

 

On Mon, Sep 15, 2014 at 3:31 PM, Meyer, Chad J <chad.j.meyer@...> wrote:

Hi Glenn,

 

I have applied the changes you recommended and created a new patch. Please see attached.

 

diff --git a/mama/jni/src/c/mamapublisherjni.c b/mama/jni/src/c/mamapublisherjni.c

index 518bacf..aa1c4c6 100644

--- a/mama/jni/src/c/mamapublisherjni.c

+++ b/mama/jni/src/c/mamapublisherjni.c

@@ -76,40 +76,47 @@ static void MAMACALLTYPE sendCompleteCB (mamaPublisher publisher,

/*

  * Class:     com_wombat_mama_MamaPublisher

  * Method:    _create

- * Signature: (Lcom/wombat/mama/Transport;Ljava/lang/String;)V

+ * Signature: (Lcom/wombat/mama/MamaTransport;Ljava/lang/String;Ljava/lang/String;)V

  */

JNIEXPORT void JNICALL Java_com_wombat_mama_MamaPublisher__1create

-  (JNIEnv* env, jobject this, jobject transport, jstring topic)

+  (JNIEnv* env, jobject this, jobject transport, jstring topic, jstring source)

{

-    mamaPublisher   cPublisher          =   NULL;

+             mamaPublisher   cPublisher          =   NULL;

     mamaTransport   cTransport          =   NULL;

-    const char*     cTopic              =   NULL;

+    const char*     cSource             =   NULL;

+             const char*     cTopic                                                       =   NULL;

     jlong           transportPointer    =   0;

     mama_status     status              =   MAMA_STATUS_OK;

     char errorString[UTILS_MAX_ERROR_STRING_LENGTH];

     /*Get the transport pointer*/

     assert(transport!=NULL);

     transportPointer = (*env)->GetLongField(env, transport,

             transportPointerFieldId_g);

+

     cTransport = CAST_JLONG_TO_POINTER(mamaTransport, transportPointer);

-    assert(transportPointer!=0);

 

+    assert(transportPointer!=0);

     /*Get the char* from the jstring*/

     if(NULL!=topic)

     {

          cTopic = (*env)->GetStringUTFChars(env,topic,0);

          if(!cTopic)return;

     }

-   

+             if(NULL!=source)

+    {

+         cSource = (*env)->GetStringUTFChars(env,source,0);

+         if(!cSource)return;

+    }

+

     if(MAMA_STATUS_OK!=(mamaPublisher_create(

                     &cPublisher,

                     cTransport,

                     cTopic,

-                    NULL,

+                    cSource,

                     NULL)))

     {

-        if(cTopic)(*env)->ReleaseStringUTFChars(env,topic, cTopic);

+                             if(cTopic)(*env)->ReleaseStringUTFChars(env,topic, cTopic);

+        if(cSource)(*env)->ReleaseStringUTFChars(env,source, cSource);

         utils_buildErrorStringForStatus(

                 errorString, UTILS_MAX_ERROR_STRING_LENGTH,

                 "Failed to create publisher.", status);

@@ -121,6 +128,7 @@ JNIEXPORT void JNICALL Java_com_wombat_mama_MamaPublisher__1create

                          CAST_POINTER_TO_JLONG(cPublisher));

        

     if(cTopic)(*env)->ReleaseStringUTFChars(env,topic, cTopic);

+             if(cSource)(*env)->ReleaseStringUTFChars(env,source, cSource);

    

     return;

}

diff --git a/mama/jni/src/com/wombat/mama/MamaPublisher.java b/mama/jni/src/com/wombat/mama/MamaPublisher.java

index 0146945..31bb1f5 100644

--- a/mama/jni/src/com/wombat/mama/MamaPublisher.java

+++ b/mama/jni/src/com/wombat/mama/MamaPublisher.java

@@ -34,10 +34,15 @@ public class MamaPublisher

 

     /*A long value containing a pointer to the underlying C publisher structure*/

     private long    publisherPointer_i   =   0;

+            

+             public void create (MamaTransport transport, String topic)

+    {

+        _create(transport,topic,null);

+    }

 

-    public void create (MamaTransport transport, String topic)

+             public void create (MamaTransport transport, String topic, String source)

     {

-        _create(transport,topic);

+        _create(transport,topic,source);

     }

 

     public void send (MamaMsg msg)

@@ -76,7 +81,7 @@ public class MamaPublisher

         _sendFromInbox(inbox,msg);

     }

 

-    private native void _create (MamaTransport transport, String topic);

+    private native void _create (MamaTransport transport, String topic, String source);

 

     private native void _send (MamaMsg msg);

 

--

1.8.4.msysgit.0

 

Regards,

 

Chad Meyer | Corporate & Investment Bank | PIM Market Data Services | J.P. Morgan | 4 Metrotech Center 23rd Floor Brooklyn, NY 11201 | Tel: (718) 242-5165 | M: (215) 801-2606 | chad.j.meyer@...

 

 

 

From: Glenn McClements [mailto:gmcclements@...]
Sent: Monday, September 08, 2014 7:14 AM
To: Meyer, Chad J; openmama-dev@...
Subject: Re: [Openmama-dev] [PATCH 2.3.1] MamaPublisher: Overloaded MamaPublisher create method

 

Thanks Chad.

 

For consistency though with the C++ interface, it should be (publisher, topic, source), not (publisher, source, topic).  

 

Also consider replacing/extending the existing JNI _create()

function rather than having two. This reduces code duplication and you already check for a NULL source being passed down so it should handle both Java methods. 

 

Glenn 

 

From: <Meyer>, Chad J <chad.j.meyer@...>
Date: Friday, 5 September 2014 22:42
To: "openmama-dev@..." <openmama-dev@...>
Subject: [Openmama-dev] [PATCH 2.3.1] MamaPublisher: Overloaded MamaPublisher create method

 

Hi,

 

Attached is a patch for OpenMAMA JNI that overloads the MamaPublisher create method. For consistency purposes, the new method requires two String parameters, source and symbol, as opposed to a single string currently found in the MamaPublisher class.  


diff --git a/mama/jni/src/c/mamapublisherjni.c b/mama/jni/src/c/mamapublisherjni.c

index 518bacf..629a51b 100644

--- a/mama/jni/src/c/mamapublisherjni.c

+++ b/mama/jni/src/c/mamapublisherjni.c

@@ -78,7 +78,7 @@ static void MAMACALLTYPE sendCompleteCB (mamaPublisher publisher,

  * Method:    _create

  * Signature: (Lcom/wombat/mama/Transport;Ljava/lang/String;)V

  */

-JNIEXPORT void JNICALL Java_com_wombat_mama_MamaPublisher__1create

+JNIEXPORT void JNICALL Java_com_wombat_mama_MamaPublisher__1create__Lcom_wombat_mama_MamaTransport_2Ljava_lang_String_2

   (JNIEnv* env, jobject this, jobject transport, jstring topic)

{

     mamaPublisher   cPublisher          =   NULL;

@@ -125,6 +125,66 @@ JNIEXPORT void JNICALL Java_com_wombat_mama_MamaPublisher__1create

     return;

}

 

+ /*

+ * Class:     com_wombat_mama_MamaPublisher

+ * Method:    _create

+ * Signature: (Lcom/wombat/mama/MamaTransport;Ljava/lang/String;Ljava/lang/String;)V

+ */

+JNIEXPORT void JNICALL Java_com_wombat_mama_MamaPublisher__1create__Lcom_wombat_mama_MamaTransport_2Ljava_lang_String_2Ljava_lang_String_2

+  (JNIEnv* env, jobject this, jobject transport, jstring source, jstring symbol)

+{

+             mamaPublisher   cPublisher          =   NULL;

+    mamaTransport   cTransport          =   NULL;

+    const char*     cSource             =   NULL;

+             const char*     cSymbol             =   NULL;

+    jlong           transportPointer    =   0;

+    mama_status     status              =   MAMA_STATUS_OK;

+    char errorString[UTILS_MAX_ERROR_STRING_LENGTH];

+            

+    /*Get the transport pointer*/

+    assert(transport!=NULL);

+    transportPointer = (*env)->GetLongField(env, transport,

+            transportPointerFieldId_g);

+    cTransport = CAST_JLONG_TO_POINTER(mamaTransport, transportPointer);

+    assert(transportPointer!=0);

+            

+    /*Get the char* from the jstring*/

+    if(NULL!=source)

+    {

+         cSource = (*env)->GetStringUTFChars(env,source,0);

+         if(!cSource)return;

+    }

+             if(NULL!=symbol)

+    {

+         cSymbol = (*env)->GetStringUTFChars(env,symbol,0);

+         if(!cSymbol)return;

+    }

+

+    if(MAMA_STATUS_OK!=(mamaPublisher_create(

+                    &cPublisher,

+                    cTransport,

+                    cSymbol,

+                    cSource,

+                    NULL)))

+    {

+        if(cSource)(*env)->ReleaseStringUTFChars(env,source, cSource);

+                             if(cSymbol)(*env)->ReleaseStringUTFChars(env,symbol, cSymbol);

+        utils_buildErrorStringForStatus(

+                errorString, UTILS_MAX_ERROR_STRING_LENGTH,

+                "Failed to create publisher.", status);

+        utils_throwMamaException(env,errorString);

+        return;

+    }

+

+    (*env)->SetLongField(env,this,publisherPointerFieldId_g,

+                         CAST_POINTER_TO_JLONG(cPublisher));

+       

+    if(cSource)(*env)->ReleaseStringUTFChars(env,source, cSource);

+             if(cSymbol)(*env)->ReleaseStringUTFChars(env,symbol, cSymbol);

+   

+    return;

+}

+

/*

  * Class:     com_wombat_mama_MamaPublisher

  * Method:    _send

diff --git a/mama/jni/src/com/wombat/mama/MamaPublisher.java b/mama/jni/src/com/wombat/mama/MamaPublisher.java

index 0146945..c1e8dc8 100644

--- a/mama/jni/src/com/wombat/mama/MamaPublisher.java

+++ b/mama/jni/src/com/wombat/mama/MamaPublisher.java

@@ -39,6 +39,11 @@ public class MamaPublisher

     {

         _create(transport,topic);

     }

+            

+             public void create (MamaTransport transport, String source, String symbol)

+    {

+        _create(transport,source,symbol);

+    }

     public void send (MamaMsg msg)

     {

@@ -77,6 +82,8 @@ public class MamaPublisher

     }

     private native void _create (MamaTransport transport, String topic);

+            

+             private native void _create (MamaTransport transport, String source, String symbol);

     private native void _send (MamaMsg msg);

--

1.8.4.msysgit.0

 

 

Chad Meyer| Corporate & Investment Bank | PIM Market Data Services | J.P. Morgan | 4 Metrotech Center 23rd Floor Brooklyn, NY 11201 | Tel: (718) 242-5165 | M: (215) 801-2606 | chad.j.meyer@...

 

This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of JPMorgan Chase & Co., its subsidiaries and affiliates. This transmission may contain information that is proprietary, privileged, confidential and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by JPMorgan Chase & Co., its subsidiaries and affiliates, as applicable, for any loss or damage arising in any way from its use. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. Please refer to http://www.jpmorgan.com/pages/disclosures for disclosures relating to European legal entities.


This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of Intercontinental Exchange, Inc. (ICE), Euronext or any of their subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired.


This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of JPMorgan Chase & Co., its subsidiaries and affiliates. This transmission may contain information that is proprietary, privileged, confidential and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by JPMorgan Chase & Co., its subsidiaries and affiliates, as applicable, for any loss or damage arising in any way from its use. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. Please refer to http://www.jpmorgan.com/pages/disclosures for disclosures relating to European legal entities.

 

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

 

 

This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of JPMorgan Chase & Co., its subsidiaries and affiliates. This transmission may contain information that is proprietary, privileged, confidential and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by JPMorgan Chase & Co., its subsidiaries and affiliates, as applicable, for any loss or damage arising in any way from its use. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. Please refer to http://www.jpmorgan.com/pages/disclosures for disclosures relating to European legal entities.

 

This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of JPMorgan Chase & Co., its subsidiaries and affiliates. This transmission may contain information that is proprietary, privileged, confidential and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by JPMorgan Chase & Co., its subsidiaries and affiliates, as applicable, for any loss or damage arising in any way from its use. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. Please refer to http://www.jpmorgan.com/pages/disclosures for disclosures relating to European legal entities.



Re: [PATCH 2.3.1] MamaPublisher: Overloaded MamaPublisher create method

Chad Meyer
 

Hi Damian,

 

I have attached a patch in the bugzilla ticket containing a new JUnit test case for testing the new create method.

 

Regards,

 

Chad Meyer | Corporate & Investment Bank | PIM Market Data Services | J.P. Morgan | 4 Metrotech Center 23rd Floor Brooklyn, NY 11201 | Tel: (718) 242-5165 | M: (215) 801-2606 | chad.j.meyer@...

 

 

 

From: Damian Maguire [mailto:d.maguire@...]
Sent: Thursday, October 23, 2014 10:34 AM
To: Meyer, Chad J; Damian Maguire
Cc: openmama-dev@...; Glenn McClements
Subject: Re: [Openmama-dev] [PATCH 2.3.1] MamaPublisher: Overloaded MamaPublisher create method

 

Thanks for the ping Chad, I'll get looking at this as soon as I can and let you know if we have any questions.

Cheers,

Damian

On 23/10/14 15:10, Meyer, Chad J wrote:

Hi Damian,

 

Added comments about a week ago to the Bugzilla ticket referenced below regarding what I did for testing. Please let me know if you need more evidence of testing.

 

Regards,

 

Chad Meyer| Corporate & Investment Bank | PIM Market Data Services | J.P. Morgan| 4 Metrotech Center 23rd Floor Brooklyn, NY 11201 | Tel: (718) 242-5165 | M: (215) 801-2606 | chad.j.meyer@...

 

 

From: Damian Maguire [mailto:damian@...]
Sent: Thursday, September 25, 2014 10:09 AM
To: Meyer, Chad J
Cc: Glenn McClements; openmama-dev@...
Subject: Re: [Openmama-dev] [PATCH 2.3.1] MamaPublisher: Overloaded MamaPublisher create method

 

Hey Chad, 

 

I was just taking a look over this again, and decided that I'd stick it into Bugzilla to keep track of it there. If you'd like to sign up for an account you can add yourself as a CC to BZ164. We can follow up with any other required information there (though the main thing outstanding remains some evidence of testing, as mentioned in my previous mail).

 

Cheers, 

 

Damian

 

On Thu, Sep 18, 2014 at 11:56 AM, Damian Maguire <damian@...> wrote:

Cheers for the new patch Chad, looks good. 

 

At this stage we really need two things to progress getting this into OpenMAMA - firstly, can you raise a Bugzilla ticket, just to make it a bit easier to track the progress of the patch. Secondly, can you provide some evidence of testing? Generally we'd ask for unit tests, but the Java framework needs a bit of work, so in this case can you show a simple example application which demonstrates the usage of the new API? 

 

Thanks again for the contribution.

 

Damian

 

On Mon, Sep 15, 2014 at 3:31 PM, Meyer, Chad J <chad.j.meyer@...> wrote:

Hi Glenn,

 

I have applied the changes you recommended and created a new patch. Please see attached.

 

diff --git a/mama/jni/src/c/mamapublisherjni.c b/mama/jni/src/c/mamapublisherjni.c

index 518bacf..aa1c4c6 100644

--- a/mama/jni/src/c/mamapublisherjni.c

+++ b/mama/jni/src/c/mamapublisherjni.c

@@ -76,40 +76,47 @@ static void MAMACALLTYPE sendCompleteCB (mamaPublisher publisher,

/*

  * Class:     com_wombat_mama_MamaPublisher

  * Method:    _create

- * Signature: (Lcom/wombat/mama/Transport;Ljava/lang/String;)V

+ * Signature: (Lcom/wombat/mama/MamaTransport;Ljava/lang/String;Ljava/lang/String;)V

  */

JNIEXPORT void JNICALL Java_com_wombat_mama_MamaPublisher__1create

-  (JNIEnv* env, jobject this, jobject transport, jstring topic)

+  (JNIEnv* env, jobject this, jobject transport, jstring topic, jstring source)

{

-    mamaPublisher   cPublisher          =   NULL;

+             mamaPublisher   cPublisher          =   NULL;

     mamaTransport   cTransport          =   NULL;

-    const char*     cTopic              =   NULL;

+    const char*     cSource             =   NULL;

+             const char*     cTopic                                                       =   NULL;

     jlong           transportPointer    =   0;

     mama_status     status              =   MAMA_STATUS_OK;

     char errorString[UTILS_MAX_ERROR_STRING_LENGTH];

     /*Get the transport pointer*/

     assert(transport!=NULL);

     transportPointer = (*env)->GetLongField(env, transport,

             transportPointerFieldId_g);

+

     cTransport = CAST_JLONG_TO_POINTER(mamaTransport, transportPointer);

-    assert(transportPointer!=0);

 

+    assert(transportPointer!=0);

     /*Get the char* from the jstring*/

     if(NULL!=topic)

     {

          cTopic = (*env)->GetStringUTFChars(env,topic,0);

          if(!cTopic)return;

     }

-   

+             if(NULL!=source)

+    {

+         cSource = (*env)->GetStringUTFChars(env,source,0);

+         if(!cSource)return;

+    }

+

     if(MAMA_STATUS_OK!=(mamaPublisher_create(

                     &cPublisher,

                     cTransport,

                     cTopic,

-                    NULL,

+                    cSource,

                     NULL)))

     {

-        if(cTopic)(*env)->ReleaseStringUTFChars(env,topic, cTopic);

+                             if(cTopic)(*env)->ReleaseStringUTFChars(env,topic, cTopic);

+        if(cSource)(*env)->ReleaseStringUTFChars(env,source, cSource);

         utils_buildErrorStringForStatus(

                 errorString, UTILS_MAX_ERROR_STRING_LENGTH,

                 "Failed to create publisher.", status);

@@ -121,6 +128,7 @@ JNIEXPORT void JNICALL Java_com_wombat_mama_MamaPublisher__1create

                          CAST_POINTER_TO_JLONG(cPublisher));

        

     if(cTopic)(*env)->ReleaseStringUTFChars(env,topic, cTopic);

+             if(cSource)(*env)->ReleaseStringUTFChars(env,source, cSource);

    

     return;

}

diff --git a/mama/jni/src/com/wombat/mama/MamaPublisher.java b/mama/jni/src/com/wombat/mama/MamaPublisher.java

index 0146945..31bb1f5 100644

--- a/mama/jni/src/com/wombat/mama/MamaPublisher.java

+++ b/mama/jni/src/com/wombat/mama/MamaPublisher.java

@@ -34,10 +34,15 @@ public class MamaPublisher

 

     /*A long value containing a pointer to the underlying C publisher structure*/

     private long    publisherPointer_i   =   0;

+            

+             public void create (MamaTransport transport, String topic)

+    {

+        _create(transport,topic,null);

+    }

 

-    public void create (MamaTransport transport, String topic)

+             public void create (MamaTransport transport, String topic, String source)

     {

-        _create(transport,topic);

+        _create(transport,topic,source);

     }

 

     public void send (MamaMsg msg)

@@ -76,7 +81,7 @@ public class MamaPublisher

         _sendFromInbox(inbox,msg);

     }

 

-    private native void _create (MamaTransport transport, String topic);

+    private native void _create (MamaTransport transport, String topic, String source);

 

     private native void _send (MamaMsg msg);

 

--

1.8.4.msysgit.0

 

Regards,

 

Chad Meyer | Corporate & Investment Bank | PIM Market Data Services | J.P. Morgan | 4 Metrotech Center 23rd Floor Brooklyn, NY 11201 | Tel: (718) 242-5165 | M: (215) 801-2606 | chad.j.meyer@...

 

 

 

From: Glenn McClements [mailto:gmcclements@...]
Sent: Monday, September 08, 2014 7:14 AM
To: Meyer, Chad J; openmama-dev@...
Subject: Re: [Openmama-dev] [PATCH 2.3.1] MamaPublisher: Overloaded MamaPublisher create method

 

Thanks Chad.

 

For consistency though with the C++ interface, it should be (publisher, topic, source), not (publisher, source, topic).  

 

Also consider replacing/extending the existing JNI _create()

function rather than having two. This reduces code duplication and you already check for a NULL source being passed down so it should handle both Java methods. 

 

Glenn 

 

From: <Meyer>, Chad J <chad.j.meyer@...>
Date: Friday, 5 September 2014 22:42
To: "openmama-dev@..." <openmama-dev@...>
Subject: [Openmama-dev] [PATCH 2.3.1] MamaPublisher: Overloaded MamaPublisher create method

 

Hi,

 

Attached is a patch for OpenMAMA JNI that overloads the MamaPublisher create method. For consistency purposes, the new method requires two String parameters, source and symbol, as opposed to a single string currently found in the MamaPublisher class.  


diff --git a/mama/jni/src/c/mamapublisherjni.c b/mama/jni/src/c/mamapublisherjni.c

index 518bacf..629a51b 100644

--- a/mama/jni/src/c/mamapublisherjni.c

+++ b/mama/jni/src/c/mamapublisherjni.c

@@ -78,7 +78,7 @@ static void MAMACALLTYPE sendCompleteCB (mamaPublisher publisher,

  * Method:    _create

  * Signature: (Lcom/wombat/mama/Transport;Ljava/lang/String;)V

  */

-JNIEXPORT void JNICALL Java_com_wombat_mama_MamaPublisher__1create

+JNIEXPORT void JNICALL Java_com_wombat_mama_MamaPublisher__1create__Lcom_wombat_mama_MamaTransport_2Ljava_lang_String_2

   (JNIEnv* env, jobject this, jobject transport, jstring topic)

{

     mamaPublisher   cPublisher          =   NULL;

@@ -125,6 +125,66 @@ JNIEXPORT void JNICALL Java_com_wombat_mama_MamaPublisher__1create

     return;

}

 

+ /*

+ * Class:     com_wombat_mama_MamaPublisher

+ * Method:    _create

+ * Signature: (Lcom/wombat/mama/MamaTransport;Ljava/lang/String;Ljava/lang/String;)V

+ */

+JNIEXPORT void JNICALL Java_com_wombat_mama_MamaPublisher__1create__Lcom_wombat_mama_MamaTransport_2Ljava_lang_String_2Ljava_lang_String_2

+  (JNIEnv* env, jobject this, jobject transport, jstring source, jstring symbol)

+{

+             mamaPublisher   cPublisher          =   NULL;

+    mamaTransport   cTransport          =   NULL;

+    const char*     cSource             =   NULL;

+             const char*     cSymbol             =   NULL;

+    jlong           transportPointer    =   0;

+    mama_status     status              =   MAMA_STATUS_OK;

+    char errorString[UTILS_MAX_ERROR_STRING_LENGTH];

+            

+    /*Get the transport pointer*/

+    assert(transport!=NULL);

+    transportPointer = (*env)->GetLongField(env, transport,

+            transportPointerFieldId_g);

+    cTransport = CAST_JLONG_TO_POINTER(mamaTransport, transportPointer);

+    assert(transportPointer!=0);

+            

+    /*Get the char* from the jstring*/

+    if(NULL!=source)

+    {

+         cSource = (*env)->GetStringUTFChars(env,source,0);

+         if(!cSource)return;

+    }

+             if(NULL!=symbol)

+    {

+         cSymbol = (*env)->GetStringUTFChars(env,symbol,0);

+         if(!cSymbol)return;

+    }

+

+    if(MAMA_STATUS_OK!=(mamaPublisher_create(

+                    &cPublisher,

+                    cTransport,

+                    cSymbol,

+                    cSource,

+                    NULL)))

+    {

+        if(cSource)(*env)->ReleaseStringUTFChars(env,source, cSource);

+                             if(cSymbol)(*env)->ReleaseStringUTFChars(env,symbol, cSymbol);

+        utils_buildErrorStringForStatus(

+                errorString, UTILS_MAX_ERROR_STRING_LENGTH,

+                "Failed to create publisher.", status);

+        utils_throwMamaException(env,errorString);

+        return;

+    }

+

+    (*env)->SetLongField(env,this,publisherPointerFieldId_g,

+                         CAST_POINTER_TO_JLONG(cPublisher));

+       

+    if(cSource)(*env)->ReleaseStringUTFChars(env,source, cSource);

+             if(cSymbol)(*env)->ReleaseStringUTFChars(env,symbol, cSymbol);

+   

+    return;

+}

+

/*

  * Class:     com_wombat_mama_MamaPublisher

  * Method:    _send

diff --git a/mama/jni/src/com/wombat/mama/MamaPublisher.java b/mama/jni/src/com/wombat/mama/MamaPublisher.java

index 0146945..c1e8dc8 100644

--- a/mama/jni/src/com/wombat/mama/MamaPublisher.java

+++ b/mama/jni/src/com/wombat/mama/MamaPublisher.java

@@ -39,6 +39,11 @@ public class MamaPublisher

     {

         _create(transport,topic);

     }

+            

+             public void create (MamaTransport transport, String source, String symbol)

+    {

+        _create(transport,source,symbol);

+    }

     public void send (MamaMsg msg)

     {

@@ -77,6 +82,8 @@ public class MamaPublisher

     }

     private native void _create (MamaTransport transport, String topic);

+            

+             private native void _create (MamaTransport transport, String source, String symbol);

     private native void _send (MamaMsg msg);

--

1.8.4.msysgit.0

 

 

Chad Meyer| Corporate & Investment Bank | PIM Market Data Services | J.P. Morgan | 4 Metrotech Center 23rd Floor Brooklyn, NY 11201 | Tel: (718) 242-5165 | M: (215) 801-2606 | chad.j.meyer@...

 

This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of JPMorgan Chase & Co., its subsidiaries and affiliates. This transmission may contain information that is proprietary, privileged, confidential and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by JPMorgan Chase & Co., its subsidiaries and affiliates, as applicable, for any loss or damage arising in any way from its use. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. Please refer to http://www.jpmorgan.com/pages/disclosures for disclosures relating to European legal entities.


This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of Intercontinental Exchange, Inc. (ICE), Euronext or any of their subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired.


This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of JPMorgan Chase & Co., its subsidiaries and affiliates. This transmission may contain information that is proprietary, privileged, confidential and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by JPMorgan Chase & Co., its subsidiaries and affiliates, as applicable, for any loss or damage arising in any way from its use. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. Please refer to http://www.jpmorgan.com/pages/disclosures for disclosures relating to European legal entities.

 

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

 

 

This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of JPMorgan Chase & Co., its subsidiaries and affiliates. This transmission may contain information that is proprietary, privileged, confidential and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by JPMorgan Chase & Co., its subsidiaries and affiliates, as applicable, for any loss or damage arising in any way from its use. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. Please refer to http://www.jpmorgan.com/pages/disclosures for disclosures relating to European legal entities.

 

This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of JPMorgan Chase & Co., its subsidiaries and affiliates. This transmission may contain information that is proprietary, privileged, confidential and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by JPMorgan Chase & Co., its subsidiaries and affiliates, as applicable, for any loss or damage arising in any way from its use. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. Please refer to http://www.jpmorgan.com/pages/disclosures for disclosures relating to European legal entities.


Re: Wombat Queue Destroy

Sam Wilson <Sam.Wilson@...>
 

Hey Damian,

I'm just getting around to looking at this now. Would you prefer a patch that adds wombatQueue_deallocate, or one that merges both wombatQueue_allocate and wombatQueue_create into wombatQueue_allocate and makes wombatQueue_create a dummy function?

The advantage of the first option is that the API works more like it was intended, but it will break any current users of wombat queues.

The second option retains backward compatibility, but you end up losing the benefits of having separate allocate/create functions.

Thanks,
Sam

On 14-09-03 05:34 AM, Damian Maguire wrote:
Hey Sam,

Unfortunately this is a weakness in the API for the Wombat Queue implementation - it really should have a wombatQueue_deallocate, but it isn't presently available. If you'd like to raise an issue in bugzilla (bugs.openmama.org) we can look at getting it added. Better yet, we'd be happy to accept a patch which addresses the issue in the queue.

Thanks, 

Damian


On Tue, Sep 2, 2014 at 7:20 PM, Sam Wilson <Sam.Wilson@...> wrote:
Hello!

I'm trying to use Wombat Queue, but I can't figure out how to safely
free a queue when the creation fails. Here's my example:

     wombatQueue queue;
     wombatQueueStatus status = wombatQueue_allocate(&queue);
     if (WOMBAT_QUEUE_OK != status) {
         return; // log the error state or what have you
     }

     status = wombatQueue_create(queue, MAX_SIZE, INITIAL_SIZE,
                                 CHUNK_SIZE);
     if (WOMBAT_QUEUE_OK != status) {
         wombatQueue_destroy(queue); // Doesn't work because the
                                     // queue hasn't been created.

         // So how do I free the memory allocated by
         // wombatQueue_allocate?
     }

Thanks for your help,
Sam
_______________________________________________
Openmama-dev mailing list
Openmama-dev@...
https://lists.openmama.org/mailman/listinfo/openmama-dev



Re: VectorChar and VectorBool field type enumerator

Alireza Assadzadeh <Alireza.Assadzadeh@...>
 

Hi Damian,

 

I have raised Bugzilla ticket 168 (http://bugs.openmama.org/show_bug.cgi?id=168) and provided a patch to address this for C/C++ for the first stage.

 

Thanks.

 

--Alireza

 

From: Damian Maguire [mailto:damian@...]
Sent: Friday, September 19, 2014 11:32 AM
To: Alireza Assadzadeh
Cc: openmama-dev@...
Subject: Re: [Openmama-dev] VectorChar and VectorBool field type enumerator

 

Hey Alireza,

 

Thanks for sending this through, and sorry about the delayed response. In this case, I agree that these values should be added to the mamaFieldType enum, and their implementations should be completed across all the languages. 

 

At this stage you've really got two options - either raise a Bugzilla ticket and we'll see about getting it added when we have a chance, or submit a patch yourself which addresses the problems. For the patching option, that can be approached in stages easily enough - beginning with the enum updates (and associated mamaFieldTypeToString and stringToMamaFieldType changes, along with anything else which may misbehave given the new values), then filling in each of the language gaps in further commits.

 

Obviously we're happy to assist if you go down the route of patching yourself, just drop us a mail and we'll lend a hand.

 

Cheers, 

 

Damian

 

On Fri, Sep 5, 2014 at 8:35 PM, Alireza Assadzadeh <Alireza.Assadzadeh@...> wrote:

Hi folks,

 

I noticed that VectorChar and VectorBool do not have  a field type enumerator  in Mama (i.e. mamaFieldType enum in mama/fielddesc.h). Also, the related code for VectorChar and VectorBool in C/ C++, C#, JNI does not have the type related implementations for these vector types as compared to other vector types, such as VectorU32 (enumerator: MAMA_FIELD_TYPE_VECTOR_U32).

 

I imagine these types may not be widely and there are alternatives field types for them(e.g. Opaque, String and unsinged integer).

 

Should VectorChar and VectorBool  types be included in the mamaFieldType enum? For example with the numbers shown below:

 

<code>

diff --git a/mama/c_cpp/src/c/mama/fielddesc.h b/mama/c_cpp/src/c/mama/fielddesc.h

index e3af6e1..a374489 100644

--- a/mama/c_cpp/src/c/mama/fielddesc.h

+++ b/mama/c_cpp/src/c/mama/fielddesc.h

@@ -90,6 +90,8 @@ typedef enum mamaFieldType_

     MAMA_FIELD_TYPE_PRICE         =   27,

 

     /** Array type support */

+    MAMA_FIELD_TYPE_VECTOR_BOOL   =   29,

+    MAMA_FIELD_TYPE_VECTOR_CHAR   =   30,

     MAMA_FIELD_TYPE_VECTOR_I8     =   34,

     MAMA_FIELD_TYPE_VECTOR_U8     =   35,

     MAMA_FIELD_TYPE_VECTOR_I16    =   36,

</code>

 

And then also have the corresponding type related changes in the rest of Mama codebase?

 

Regards,.

 

--Alireza


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

 


[PATCH 2.3.1 5/5] MAMA: Update examples and test tools for completed support of Vector Bool and Vectar Char.

Alireza Assadzadeh <Alireza.Assadzadeh@...>
 

Signed-off-by: Alireza Assadzadeh <Alireza.Assadzadeh@solacesystems.com>
---
mama/c_cpp/src/examples/c/mamalistencachedc.c | 26 ++++++++++++++
.../c_cpp/src/examples/cpp/mamalistencachedcpp.cpp | 40 ++++++++++++++++++++++
mama/c_cpp/src/examples/cpp/mamalistencpp.cpp | 16 +++++++++
.../src/testtools/capturereplay/c/captureconvert.c | 10 ++++++
4 files changed, 92 insertions(+)

diff --git a/mama/c_cpp/src/examples/c/mamalistencachedc.c b/mama/c_cpp/src/examples/c/mamalistencachedc.c
index db6d3ee..6d8ccf4 100644
--- a/mama/c_cpp/src/examples/c/mamalistencachedc.c
+++ b/mama/c_cpp/src/examples/c/mamalistencachedc.c
@@ -2630,6 +2630,32 @@ void printField(mamaFieldCacheField field)
printf ("%s\n", priceString);
break;
}
+ case MAMA_FIELD_TYPE_VECTOR_BOOL:
+ {
+ const mama_bool_t* result = NULL;
+ mama_size_t size = 0;
+ mama_size_t i =0;
+ mamaFieldCacheField_getBoolVector(field,&result,&size);
+ printf("\n");
+ for (i=0;i<size;i++)
+ {
+ printf(" %d\n", (int)result[i]);
+ }
+ break;
+ }
+ case MAMA_FIELD_TYPE_VECTOR_CHAR:
+ {
+ const char* result = NULL;
+ mama_size_t size = 0;
+ mama_size_t i =0;
+ mamaFieldCacheField_getCharVector(field,&result,&size);
+ printf("\n");
+ for (i=0;i<size;i++)
+ {
+ printf(" %c\n", (int)result[i]);
+ }
+ break;
+ }
case MAMA_FIELD_TYPE_VECTOR_I8:
{
const mama_i8_t* result = NULL;
diff --git a/mama/c_cpp/src/examples/cpp/mamalistencachedcpp.cpp b/mama/c_cpp/src/examples/cpp/mamalistencachedcpp.cpp
index 23e94b8..e2c3f45 100644
--- a/mama/c_cpp/src/examples/cpp/mamalistencachedcpp.cpp
+++ b/mama/c_cpp/src/examples/cpp/mamalistencachedcpp.cpp
@@ -1287,6 +1287,22 @@ void DisplayCallback::displayMsgField (const MamaMsg& msg,
printData ("%s\n", price);
}
break;
+ case MAMA_FIELD_TYPE_VECTOR_BOOL:
+ {
+ const mama_bool_t* vectorBool;
+ size_t resultLen;
+ field.getVectorBool (vectorBool, resultLen);
+ displayVectorField (vectorBool, resultLen, "%d");
+ }
+ break;
+ case MAMA_FIELD_TYPE_VECTOR_CHAR:
+ {
+ const char* vectorChar;
+ size_t resultLen;
+ field.getVectorChar (vectorChar, resultLen);
+ displayVectorField (vectorChar, resultLen, "%c");
+ }
+ break;
case MAMA_FIELD_TYPE_VECTOR_I8:
{
const int8_t* vectorI8;
@@ -2149,6 +2165,30 @@ std::ostream& operator<<(std::ostream& os, const MamaFieldCacheField& field)
os << cachedPriceField.get(field).getAsString();
break;
}
+ case MAMA_FIELD_TYPE_VECTOR_BOOL:
+ {
+ MamaFieldCacheFieldBoolVector cachedVectorField;
+ const mama_bool_t* values = NULL;
+ mama_size_t size = 0;
+ cachedVectorField.get(field,values,size);
+ for (mama_size_t i = 0; i < size; ++i)
+ {
+ os << "[" << (values[i] ? 1 : 0) << "]";
+ }
+ break;
+ }
+ case MAMA_FIELD_TYPE_VECTOR_CHAR:
+ {
+ MamaFieldCacheFieldCharVector cachedVectorField;
+ const char* values = NULL;
+ mama_size_t size = 0;
+ cachedVectorField.get(field,values,size);
+ for (mama_size_t i = 0; i < size; ++i)
+ {
+ os << "[" << (char)values[i] << "]";
+ }
+ break;
+ }
case MAMA_FIELD_TYPE_VECTOR_I8:
{
MamaFieldCacheFieldI8Vector cachedVectorField;
diff --git a/mama/c_cpp/src/examples/cpp/mamalistencpp.cpp b/mama/c_cpp/src/examples/cpp/mamalistencpp.cpp
index 082d00a..ed81b9d 100644
--- a/mama/c_cpp/src/examples/cpp/mamalistencpp.cpp
+++ b/mama/c_cpp/src/examples/cpp/mamalistencpp.cpp
@@ -1226,6 +1226,22 @@ void DisplayCallback::displayMsgField (const MamaMsg& msg,
printData ("%s\n", price);
}
break;
+ case MAMA_FIELD_TYPE_VECTOR_BOOL:
+ {
+ const mama_bool_t* vectorBool;
+ size_t resultLen;
+ field.getVectorBool (vectorBool, resultLen);
+ displayVectorField (vectorBool, resultLen, "%d");
+ }
+ break;
+ case MAMA_FIELD_TYPE_VECTOR_CHAR:
+ {
+ const char* vectorChar;
+ size_t resultLen;
+ field.getVectorChar (vectorChar, resultLen);
+ displayVectorField (vectorChar, resultLen, "%c");
+ }
+ break;
case MAMA_FIELD_TYPE_VECTOR_I8:
{
const int8_t* vectorI8;
diff --git a/mama/c_cpp/src/testtools/capturereplay/c/captureconvert.c b/mama/c_cpp/src/testtools/capturereplay/c/captureconvert.c
index 4181219..b913a0c 100644
--- a/mama/c_cpp/src/testtools/capturereplay/c/captureconvert.c
+++ b/mama/c_cpp/src/testtools/capturereplay/c/captureconvert.c
@@ -538,6 +538,16 @@ static void copyMamaMsg (mamaMsg sourceMessage,
mamaMsg_destroy (internalTarget);
break;
}
+ case MAMA_FIELD_TYPE_VECTOR_BOOL:
+ {
+ MAMA_VECTOR_FIELD_COPY (Bool, mama_bool_t);
+ break;
+ }
+ case MAMA_FIELD_TYPE_VECTOR_CHAR:
+ {
+ MAMA_VECTOR_FIELD_COPY (Char, char);
+ break;
+ }
case MAMA_FIELD_TYPE_VECTOR_I8:
{
MAMA_VECTOR_FIELD_COPY (I8, mama_i8_t);
--
1.9.3


[PATCH 2.3.1 4/5] MAMA: Update gunittest for completed support of Vector Bool and Vectar Char.

Alireza Assadzadeh <Alireza.Assadzadeh@...>
 

Signed-off-by: Alireza Assadzadeh <Alireza.Assadzadeh@solacesystems.com>
---
.../gunittest/c/fieldcache/fieldcachefieldtest.cpp | 60 ++++++++++++++++
.../gunittest/c/mamamsg/msgfieldvectortests.cpp | 29 +++++---
.../src/gunittest/c/mamamsg/msgvectortests.cpp | 2 +-
.../src/gunittest/c/payload/fieldvectortests.cpp | 9 ++-
.../fieldcache/MamaFieldCacheFieldTypesTest.cpp | 80 ++++++++++++++++++++++
5 files changed, 168 insertions(+), 12 deletions(-)

diff --git a/mama/c_cpp/src/gunittest/c/fieldcache/fieldcachefieldtest.cpp b/mama/c_cpp/src/gunittest/c/fieldcache/fieldcachefieldtest.cpp
index 124c5b6..0b65f2b 100644
--- a/mama/c_cpp/src/gunittest/c/fieldcache/fieldcachefieldtest.cpp
+++ b/mama/c_cpp/src/gunittest/c/fieldcache/fieldcachefieldtest.cpp
@@ -662,6 +662,66 @@ TEST_F(MamaFieldCacheFieldTestC, testSetGetI8Vector)
DESTROY_FIELD
}

+TEST_F(MamaFieldCacheFieldTestC, testSetGetBoolVector)
+{
+ //TODO: AA: Change u8 test
+ const mama_u8_t* retValue = NULL;
+ mama_size_t retSize;
+ mama_u8_t dataVector[3] = { 1, 2, 3 };
+
+ CREATE_FIELD(1, MAMA_FIELD_TYPE_VECTOR_U8)
+
+ // Adding only 2 fields
+ ASSERT_EQ(MAMA_STATUS_OK, mamaFieldCacheField_setU8Vector(field, dataVector, 2));
+ ASSERT_EQ(MAMA_STATUS_OK, mamaFieldCacheField_getU8Vector(field, &retValue, &retSize));
+ ASSERT_EQ(2, retSize);
+ ASSERT_TRUE(retValue);
+ ASSERT_EQ(1, retValue[0]);
+ ASSERT_EQ(2, retValue[1]);
+
+ dataVector[0] = 10;
+ ASSERT_EQ(MAMA_STATUS_OK, mamaFieldCacheField_setU8Vector(field, dataVector, 3));
+ ASSERT_EQ(MAMA_STATUS_OK, mamaFieldCacheField_getU8Vector(field, &retValue, &retSize));
+
+ ASSERT_EQ(3, retSize);
+ ASSERT_TRUE(retValue);
+ ASSERT_EQ(10, retValue[0]);
+ ASSERT_EQ(2, retValue[1]);
+ ASSERT_EQ(3, retValue[2]);
+
+ DESTROY_FIELD
+}
+
+TEST_F(MamaFieldCacheFieldTestC, testSetGetCharVector)
+{
+ //TODO: AA: Change u8 test
+ const mama_u8_t* retValue = NULL;
+ mama_size_t retSize;
+ mama_u8_t dataVector[3] = { 1, 2, 3 };
+
+ CREATE_FIELD(1, MAMA_FIELD_TYPE_VECTOR_U8)
+
+ // Adding only 2 fields
+ ASSERT_EQ(MAMA_STATUS_OK, mamaFieldCacheField_setU8Vector(field, dataVector, 2));
+ ASSERT_EQ(MAMA_STATUS_OK, mamaFieldCacheField_getU8Vector(field, &retValue, &retSize));
+ ASSERT_EQ(2, retSize);
+ ASSERT_TRUE(retValue);
+ ASSERT_EQ(1, retValue[0]);
+ ASSERT_EQ(2, retValue[1]);
+
+ dataVector[0] = 10;
+ ASSERT_EQ(MAMA_STATUS_OK, mamaFieldCacheField_setU8Vector(field, dataVector, 3));
+ ASSERT_EQ(MAMA_STATUS_OK, mamaFieldCacheField_getU8Vector(field, &retValue, &retSize));
+
+ ASSERT_EQ(3, retSize);
+ ASSERT_TRUE(retValue);
+ ASSERT_EQ(10, retValue[0]);
+ ASSERT_EQ(2, retValue[1]);
+ ASSERT_EQ(3, retValue[2]);
+
+ DESTROY_FIELD
+}
+
TEST_F(MamaFieldCacheFieldTestC, testSetGetU8Vector)
{
const mama_u8_t* retValue = NULL;
diff --git a/mama/c_cpp/src/gunittest/c/mamamsg/msgfieldvectortests.cpp b/mama/c_cpp/src/gunittest/c/mamamsg/msgfieldvectortests.cpp
index 7d690e1..874bcd9 100644
--- a/mama/c_cpp/src/gunittest/c/mamamsg/msgfieldvectortests.cpp
+++ b/mama/c_cpp/src/gunittest/c/mamamsg/msgfieldvectortests.cpp
@@ -78,14 +78,16 @@ protected:
MsgFieldVectorBoolTests()
: mOut(NULL)
{
- mIn[0] = 1;
- mIn[1] = 2;
+ mIn[0] = 0;
+ mIn[1] = 1;
}

virtual void SetUp()
{
MsgFieldVectorTestsC::SetUp();

+ mamaMsg_addVectorBool (mMsg, NULL, 1, mIn, VECTOR_SIZE);
+
mOut = NULL;
}

@@ -100,21 +102,32 @@ protected:
* ****************************************************************************
*/

-TEST_F(MsgFieldVectorBoolTests, DISABLED_GetVectorBool)
+TEST_F(MsgFieldVectorBoolTests, GetVectorBool)
{
- /* getVectorBool is declared in msgfield.h but not defined */
+ mStatus = mamaMsg_getField (mMsg, NULL, 1, &mField);
+ ASSERT_EQ (mStatus, MAMA_STATUS_OK) << "Failed getting field";
+ mStatus = mamaMsgField_getVectorBool (mField, &mOut, &mSize);
+ ASSERT_EQ (mStatus, MAMA_STATUS_OK) << "Failed getting Vector Bool";
+ EXPECT_EQ (0, mOut[0]);
+ EXPECT_EQ (1, mOut[1]);
+ EXPECT_EQ (VECTOR_SIZE, mSize);
}

TEST_F(MsgFieldVectorBoolTests, DISABLED_GetVectorBoolNullField)
{
- /* getVectorBool is declared in msgfield.h but not defined */
+ mStatus = mamaMsgField_getVectorBool (NULL, &mOut, &mSize);
+ EXPECT_EQ (MAMA_STATUS_NULL_ARG, mStatus);
}

-TEST_F(MsgFieldVectorBoolTests, DISABLED_GetVectorBoolNullVector)
+TEST_F(MsgFieldVectorBoolTests, GetVectorBoolNullVector)
{
- /* getVectorBool is declared in msgfield.h but not defined */
+ mStatus = mamaMsg_getField (mMsg, NULL, 1, &mField);
+ ASSERT_EQ (MAMA_STATUS_OK, mStatus) << "Failed getting field";
+ mStatus = mamaMsgField_getVectorBool (mField, NULL, &mSize);
+ EXPECT_EQ (MAMA_STATUS_NULL_ARG, mStatus);
}

+
/*
* CHAR TEST SUITE
* ****************************************************************************
@@ -168,7 +181,7 @@ TEST_F(MsgFieldVectorCharTests, DISABLED_GetVectorCharNullField)
EXPECT_EQ (mStatus, MAMA_STATUS_NULL_ARG);
}

-TEST_F(MsgFieldVectorCharTests, DISABLED_GetVectorCharNullVector)
+TEST_F(MsgFieldVectorCharTests, GetVectorCharNullVector)
{
mamaMsg_getField (mMsg, NULL, 1, &mField);
mStatus = mamaMsgField_getVectorChar (mField, NULL, &mSize);
diff --git a/mama/c_cpp/src/gunittest/c/mamamsg/msgvectortests.cpp b/mama/c_cpp/src/gunittest/c/mamamsg/msgvectortests.cpp
index 8cd03b9..b72fa68 100644
--- a/mama/c_cpp/src/gunittest/c/mamamsg/msgvectortests.cpp
+++ b/mama/c_cpp/src/gunittest/c/mamamsg/msgvectortests.cpp
@@ -125,7 +125,7 @@ TEST_F(MsgVectorBoolTestsC, AddVectorBool)
&mOutSize);

EXPECT_EQ( mStatus, MAMA_STATUS_OK );
- // EXPECT_EQ( 0, ::memcmp( mIn, mOut, (sizeof(mama_bool_t) * VECTOR_SIZE) ) );
+ EXPECT_EQ( 0, ::memcmp( mIn, mOut, (sizeof(mama_bool_t) * VECTOR_SIZE) ) );
EXPECT_EQ( mOutSize, VECTOR_SIZE );
}

diff --git a/mama/c_cpp/src/gunittest/c/payload/fieldvectortests.cpp b/mama/c_cpp/src/gunittest/c/payload/fieldvectortests.cpp
index 9c701c8..4429347 100644
--- a/mama/c_cpp/src/gunittest/c/payload/fieldvectortests.cpp
+++ b/mama/c_cpp/src/gunittest/c/payload/fieldvectortests.cpp
@@ -118,19 +118,22 @@ TEST_F(FieldVectorBoolTests, GetVectorBool)
{
m_payloadBridge->msgPayloadGetField (m_msg, NULL, 1, &m_field);
m_status = m_payloadBridge->msgFieldPayloadGetVectorBool(m_field, &m_out, &m_size);
- ASSERT_EQ (MAMA_STATUS_NOT_IMPLEMENTED, m_status);
+ ASSERT_EQ (MAMA_STATUS_OK, m_status);
+ ASSERT_EQ (1, m_out[0]);
+ ASSERT_EQ (0, m_out[1]);
+ ASSERT_EQ ((mama_size_t) VECTOR_SIZE * sizeof(mama_bool_t), m_size);
}

TEST_F(FieldVectorBoolTests, GetVectorBoolNullOut)
{
m_status = m_payloadBridge->msgFieldPayloadGetVectorBool(m_field, NULL, &m_size);
- ASSERT_EQ (MAMA_STATUS_NOT_IMPLEMENTED, m_status);
+ ASSERT_EQ (MAMA_STATUS_NULL_ARG, m_status);
}

TEST_F(FieldVectorBoolTests, GetVectorBoolNullSize)
{
m_status = m_payloadBridge->msgFieldPayloadGetVectorBool(m_field, &m_out, NULL);
- ASSERT_EQ (MAMA_STATUS_NOT_IMPLEMENTED, m_status);
+ ASSERT_EQ (MAMA_STATUS_NULL_ARG, m_status);
}

/**
diff --git a/mama/c_cpp/src/gunittest/cpp/fieldcache/MamaFieldCacheFieldTypesTest.cpp b/mama/c_cpp/src/gunittest/cpp/fieldcache/MamaFieldCacheFieldTypesTest.cpp
index ee4c6b1..da62656 100644
--- a/mama/c_cpp/src/gunittest/cpp/fieldcache/MamaFieldCacheFieldTypesTest.cpp
+++ b/mama/c_cpp/src/gunittest/cpp/fieldcache/MamaFieldCacheFieldTypesTest.cpp
@@ -499,6 +499,86 @@ TEST_F(MamaFieldCacheFieldTypesTest, testDateTime)
ASSERT_DOUBLE_EQ(2500, value.getEpochTimeSeconds());
}

+TEST_F(MamaFieldCacheFieldTypesTest, testBoolVector)
+{
+ MamaFieldCacheField fieldBase;
+ fieldBase.create(1, MAMA_FIELD_TYPE_VECTOR_BOOL, "");
+ MamaFieldCacheFieldBoolVector field;
+
+ mama_bool_t values[5] = { 0, 1, 0, 1, 1 };
+ field.set(fieldBase, values, 5);
+ ASSERT_EQ(0, field.get(fieldBase, 0));
+ ASSERT_EQ(1, field.get(fieldBase, 1));
+ ASSERT_EQ(0, field.get(fieldBase, 2));
+ ASSERT_EQ(1, field.get(fieldBase, 3));
+ ASSERT_EQ(1, field.get(fieldBase, 4));
+
+ const mama_bool_t* result = NULL;
+ mama_size_t size;
+ field.get(fieldBase, result, size);
+ ASSERT_EQ(5, size);
+ ASSERT_EQ(0, result[0]);
+ ASSERT_EQ(1, result[1]);
+ ASSERT_EQ(0, result[2]);
+ ASSERT_EQ(1, result[3]);
+ ASSERT_EQ(1, result[4]);
+ getFieldValue(fieldBase, result, size);
+ ASSERT_EQ(5, size);
+ ASSERT_EQ(0, result[0]);
+ ASSERT_EQ(1, result[1]);
+ ASSERT_EQ(0, result[2]);
+ ASSERT_EQ(1, result[3]);
+ ASSERT_EQ(1, result[4]);
+
+ values[2] = 1;
+ setFieldValue(fieldBase, values, 5);
+ ASSERT_EQ(0, field.get(fieldBase, 0));
+ ASSERT_EQ(1, field.get(fieldBase, 1));
+ ASSERT_EQ(1, field.get(fieldBase, 2));
+ ASSERT_EQ(1, field.get(fieldBase, 3));
+ ASSERT_EQ(1, field.get(fieldBase, 4));
+}
+
+TEST_F(MamaFieldCacheFieldTypesTest, testCharVector)
+{
+ MamaFieldCacheField fieldBase;
+ fieldBase.create(1, MAMA_FIELD_TYPE_VECTOR_CHAR, "");
+ MamaFieldCacheFieldI8Vector field;
+
+ mama_i8_t values[5] = { 'E', 'F', 'V', 'H', 'I' };
+ field.set(fieldBase, values, 5);
+ ASSERT_EQ('E', field.get(fieldBase, 0));
+ ASSERT_EQ('F', field.get(fieldBase, 1));
+ ASSERT_EQ('V', field.get(fieldBase, 2));
+ ASSERT_EQ('H', field.get(fieldBase, 3));
+ ASSERT_EQ('I', field.get(fieldBase, 4));
+
+ const mama_i8_t* result = NULL;
+ mama_size_t size;
+ field.get(fieldBase, result, size);
+ ASSERT_EQ(5, size);
+ ASSERT_EQ('E', result[0]);
+ ASSERT_EQ('F', result[1]);
+ ASSERT_EQ('V', result[2]);
+ ASSERT_EQ('H', result[3]);
+ ASSERT_EQ('I', result[4]);
+ getFieldValue(fieldBase, result, size);
+ ASSERT_EQ(5, size);
+ ASSERT_EQ('E', result[0]);
+ ASSERT_EQ('F', result[1]);
+ ASSERT_EQ('V', result[2]);
+ ASSERT_EQ('H', result[3]);
+ ASSERT_EQ('I', result[4]);
+
+ values[2] = 'G';
+ setFieldValue(fieldBase, values, 5);
+ ASSERT_EQ('E', field.get(fieldBase, 0));
+ ASSERT_EQ('F', field.get(fieldBase, 1));
+ ASSERT_EQ('G', field.get(fieldBase, 2));
+ ASSERT_EQ('H', field.get(fieldBase, 3));
+ ASSERT_EQ('I', field.get(fieldBase, 4));
+}
+
TEST_F(MamaFieldCacheFieldTypesTest, testI8Vector)
{
MamaFieldCacheField fieldBase;
--
1.9.3


[PATCH 2.3.1 3/5] QPID: Add support for Vector Bool and Vector Char field types.

Alireza Assadzadeh <Alireza.Assadzadeh@...>
 

Signed-off-by: Alireza Assadzadeh <Alireza.Assadzadeh@solacesystems.com>
---
mama/c_cpp/src/c/payload/qpidmsg/field.c | 12 +++++++++++-
mama/c_cpp/src/c/payload/qpidmsg/payload.c | 20 ++++++++++++++++++--
2 files changed, 29 insertions(+), 3 deletions(-)

diff --git a/mama/c_cpp/src/c/payload/qpidmsg/field.c b/mama/c_cpp/src/c/payload/qpidmsg/field.c
index ae988e9..49ac087 100644
--- a/mama/c_cpp/src/c/payload/qpidmsg/field.c
+++ b/mama/c_cpp/src/c/payload/qpidmsg/field.c
@@ -919,7 +919,7 @@ qpidmsgFieldPayload_getVectorBool (const msgFieldPayload field,
const mama_bool_t** result,
mama_size_t* size)
{
- return MAMA_STATUS_NOT_IMPLEMENTED;
+ GET_VECTOR_FIELD (_bool, mama_bool_t);
}

mama_status
@@ -1264,6 +1264,16 @@ qpidmsgFieldPayload_getAsString (const msgFieldPayload field,
long long unsigned);
break;
}
+ case MAMA_FIELD_TYPE_VECTOR_BOOL:
+ {
+ EXPAND_PRINT_VECTOR_MACROS (mama_bool_t, Bool, "%u", mama_bool_t);
+ break;
+ }
+ case MAMA_FIELD_TYPE_VECTOR_CHAR:
+ {
+ EXPAND_PRINT_VECTOR_MACROS (char, Char, "%c", char);
+ break;
+ }
case MAMA_FIELD_TYPE_VECTOR_I8:
{
EXPAND_PRINT_VECTOR_MACROS (mama_i8_t, I8, "%d", mama_i8_t);
diff --git a/mama/c_cpp/src/c/payload/qpidmsg/payload.c b/mama/c_cpp/src/c/payload/qpidmsg/payload.c
index 09daab4..2e69769 100644
--- a/mama/c_cpp/src/c/payload/qpidmsg/payload.c
+++ b/mama/c_cpp/src/c/payload/qpidmsg/payload.c
@@ -1166,6 +1166,16 @@ qpidmsgPayload_apply (msgPayload dest,
UPDATE_VECTOR_FIELD (U8, mama_u8_t);
break;
}
+ case MAMA_FIELD_TYPE_VECTOR_BOOL:
+ {
+ UPDATE_VECTOR_FIELD (Bool, mama_bool_t);
+ break;
+ }
+ case MAMA_FIELD_TYPE_VECTOR_CHAR:
+ {
+ UPDATE_VECTOR_FIELD (Char, char);
+ break;
+ }
case MAMA_FIELD_TYPE_VECTOR_I8:
{
UPDATE_VECTOR_FIELD (I8, mama_i8_t);
@@ -3733,6 +3743,12 @@ qpidmsgPayloadImpl_addFieldToPayload (msgPayload msg,
return status;
break;
}
+ case MAMA_FIELD_TYPE_VECTOR_BOOL:
+ ADD_VECTOR_FIELD_VALUE_TO_MESSAGE(Bool, mama_bool_t);
+ break;
+ case MAMA_FIELD_TYPE_VECTOR_CHAR:
+ ADD_VECTOR_FIELD_VALUE_TO_MESSAGE(Char, char);
+ break;
case MAMA_FIELD_TYPE_VECTOR_I8:
ADD_VECTOR_FIELD_VALUE_TO_MESSAGE(I8, mama_i8_t);
break;
@@ -3912,14 +3928,14 @@ qpidmsgPayloadImpl_arrayToMamaType (pn_type_t type)
switch(type)
{
case PN_NULL: return MAMA_FIELD_TYPE_UNKNOWN;
- case PN_BOOL: return MAMA_FIELD_TYPE_VECTOR_U8;
+ case PN_BOOL: return MAMA_FIELD_TYPE_VECTOR_BOOL;
case PN_UBYTE: return MAMA_FIELD_TYPE_VECTOR_U8;
case PN_BYTE: return MAMA_FIELD_TYPE_VECTOR_I8;
case PN_USHORT: return MAMA_FIELD_TYPE_VECTOR_U16;
case PN_SHORT: return MAMA_FIELD_TYPE_VECTOR_I16;
case PN_UINT: return MAMA_FIELD_TYPE_VECTOR_U32;
case PN_INT: return MAMA_FIELD_TYPE_VECTOR_I32;
- case PN_CHAR: return MAMA_FIELD_TYPE_VECTOR_U8;
+ case PN_CHAR: return MAMA_FIELD_TYPE_VECTOR_CHAR;
case PN_ULONG: return MAMA_FIELD_TYPE_VECTOR_U64;
case PN_LONG: return MAMA_FIELD_TYPE_VECTOR_I64;
case PN_TIMESTAMP: return MAMA_FIELD_TYPE_VECTOR_TIME;
--
1.9.3

921 - 940 of 2306