Date   

Re: [PATCH] [mamda] map a delete msg through mamda as an error callback

Ian Bell <IBell@...>
 

-----Original Message-----
From: Mike Schonberg
Sent: 21 May 2012 21:48
To: Ian Bell; openmama-dev@lists.openmama.org
Subject: RE: [Openmama-dev] [PATCH] [mamda] map a delete msg through mamda as an error callback



-----Original Message-----
From: openmama-dev-bounces@lists.openmama.org [mailto:openmama-dev-
bounces@lists.openmama.org] On Behalf Of Ian Bell
Sent: Friday, May 18, 2012 8:58 AM
To: openmama-dev@lists.openmama.org
Subject: [Openmama-dev] [PATCH] [mamda] map a delete msg through mamda
as an error callback

commit be5ec93af947d5ed9458bf8a5e05b7300a9322d6

Author: Ian Bell <IBell@nyx.com>

Date: Thu May 17 21:47:41 2012 +0100



[mamda] map a delete msg through mamda as an error callback
We need a little more information here. What is a "delete" message? When/why does it get sent? Why is it an error? This comment will ultimately go into the release notes.

Regards,
-Mike

When using a MamdaSubscription and a msg of type delete is received Mamda handles this internally and did not notify the user that this had happened. As no more messages were received after the delete msg this symbol effectively stopped ticking. This patch fires a callback on the MamdaErrorListener to inform the user of the delete msg so they can take any action they wish based on this information. (eg delete the subscription.)

I will try to be more verbose on any less straight forward patches in future.

Ian


Signed-off-by: Ian Bell <IBell@nyx.com>



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

index 1c48c00..ab51f63 100644

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

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

@@ -94,6 +94,8 @@ typedef enum

MAMA_STATUS_INVALID_QUEUE = 27,

/* Not modifiable */

MAMA_STATUS_NOT_MODIFIABLE = 28,

+ /* Message Type DELETE */

+ MAMA_STATUS_DELETE = 29,

/* Not permissioned for the subject */

MAMA_STATUS_NOT_PERMISSIONED =
4001,

/* Subscription is in an invalid state. */

diff --git a/mama/c_cpp/src/c/status.c b/mama/c_cpp/src/c/status.c

index e8c1c31..f5cb3ff 100644

--- a/mama/c_cpp/src/c/status.c

+++ b/mama/c_cpp/src/c/status.c

@@ -57,6 +57,7 @@ mamaStatus_stringForStatus (mama_status status)

case MAMA_STATUS_NOT_INSTALLED : return "NOT_INSTALLED";

case MAMA_STATUS_NO_BRIDGE_IMPL : return "NO_BRIDGE_IMPL";

case MAMA_STATUS_INVALID_QUEUE : return "INVALID_QUEUE";

+ case MAMA_STATUS_DELETE : return "STATUS_DELETE";

case MAMA_STATUS_NOT_MODIFIABLE : return "NOT_MODIFIABLE";

case MAMA_STATUS_NOT_PERMISSIONED : return
"MAMA_STATUS_NOT_PERMISSIONED";

case MAMA_STATUS_SUBSCRIPTION_INVALID_STATE: return
"MAMA_STATUS_SUBSCRIPTION_INVALID_STATE";

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

index 52060d9..65da8d9 100644

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

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

@@ -81,6 +81,10 @@ public class MamaMsgStatus

/** Message with duplicate sequence number */

public static final short STATUS_DUPLICATE = 15;

+ /** Message with the type of DELETE */

+ public static final short STATUS_DELETE = 17;

+

+

public static final short STATUS_EXCEPTION = 999;

/**

diff --git a/mamda/c_cpp/src/cpp/MamdaSubscription.cpp
b/mamda/c_cpp/src/cpp/MamdaSubscription.cpp

index 9b6599c..d9a9d30 100644

--- a/mamda/c_cpp/src/cpp/MamdaSubscription.cpp

+++ b/mamda/c_cpp/src/cpp/MamdaSubscription.cpp

@@ -471,6 +471,21 @@ namespace Wombat

switch (msgType)

{

case MAMA_MSG_TYPE_DELETE:

+ if (subscription->checkDebugLevel
+ (MAMA_LOG_LEVEL_FINE))

+ {

+ const char *contentSymbol = "N/A";

+ msg.tryString (MamdaCommonFields::ISSUE_SYMBOL,
contentSymbol);

+

+ mama_forceLog (MAMA_LOG_LEVEL_FINE,

+ "MamdaSubscription (%s.%s(%s)) "

+ "ignoring msg. type: %s\n",

+ mSource->getPublisherSourceName(),

+ mSymbol.c_str (),

+ contentSymbol,

+ msg.getMsgTypeName());

+ }

+ onError (subscription,
+ MAMA_STATUS_DELETE , "Msg
Type Delete");

+ return;

case MAMA_MSG_TYPE_EXPIRE:

if (subscription->checkDebugLevel
(MAMA_LOG_LEVEL_FINE))

{

@@ -566,6 +581,11 @@ namespace Wombat

code = MAMDA_ERROR_BAD_SYMBOL;

errStr = "bad symbol";

break;

+ case MAMA_STATUS_DELETE:

+ severity = MAMDA_SEVERITY_OK;

+ code = MAMDA_ERROR_DELETE;

+ errStr = "message type delete";

+ break;

case MAMA_STATUS_TIMEOUT:

severity = MAMDA_SEVERITY_HIGH;

code = MAMDA_ERROR_TIME_OUT;

diff --git a/mamda/c_cpp/src/cpp/mamda/MamdaErrorListener.h
b/mamda/c_cpp/src/cpp/mamda/MamdaErrorListener.h

index d93877f..5168987 100644

--- a/mamda/c_cpp/src/cpp/mamda/MamdaErrorListener.h

+++ b/mamda/c_cpp/src/cpp/mamda/MamdaErrorListener.h

@@ -57,7 +57,7 @@ namespace Wombat

MAMDA_ERROR_TIME_OUT,

MAMDA_ERROR_ENTITLEMENT,

MAMDA_ERROR_NOT_FOUND,

- MAMDA_ERROR_WATCH_THIS_SPACE

+ MAMDA_ERROR_DELETE

};

/**

diff --git a/mamda/java/com/wombat/mamda/MamdaErrorCode.java
b/mamda/java/com/wombat/mamda/MamdaErrorCode.java

index fa25213..59de128 100644

--- a/mamda/java/com/wombat/mamda/MamdaErrorCode.java

+++ b/mamda/java/com/wombat/mamda/MamdaErrorCode.java

@@ -72,6 +72,9 @@ public class MamdaErrorCode

/** Bandwidth exceeded */

public static final short MAMDA_ERROR_BANDWIDTH_EXCEEDED = 14;

+ /** Message of type DELETE */

+ public static final short MAMDA_ERROR_DELETE = 17;

+

public static final short MAMDA_ERROR_EXCEPTION = 999;



@@ -100,6 +103,7 @@ public class MamdaErrorCode

case MAMDA_ERROR_TOPIC_CHANGE: return "TOPIC_CHANGE";

case MAMDA_ERROR_BANDWIDTH_EXCEEDED: return
"BANDWIDTH_EXCEEDED";

case MAMDA_ERROR_EXCEPTION: return "EXCEPTION PROCESSING
MESSAGE";

+ case MAMDA_ERROR_DELETE: return "MESSAGE TYPE DELETE";

default: return "UNKNOWN";

}

}

@@ -124,6 +128,7 @@ public class MamdaErrorCode

case MamaMsgStatus.STATUS_TOPIC_CHANGE: return
MAMDA_ERROR_TOPIC_CHANGE;

case MamaMsgStatus.STATUS_BANDWIDTH_EXCEEDED: return
MAMDA_ERROR_BANDWIDTH_EXCEEDED;

case MamaMsgStatus.STATUS_EXCEPTION: return
MAMDA_ERROR_EXCEPTION;

+ case MamaMsgStatus.STATUS_DELETE: return
MAMDA_ERROR_DELETE;

}

return -1;

diff --git a/mamda/java/com/wombat/mamda/MamdaSubscription.java
b/mamda/java/com/wombat/mamda/MamdaSubscription.java

index 3d82225..46efd13 100644

--- a/mamda/java/com/wombat/mamda/MamdaSubscription.java

+++ b/mamda/java/com/wombat/mamda/MamdaSubscription.java

@@ -470,10 +470,15 @@ public class MamdaSubscription

short msgType = MamaMsgType.typeForMsg (msg);

int msgStatus = MamaMsgStatus.statusForMsg (msg);

mLatestMsg = msg;

+ short mywombatStatus = 17;

+ int myplatformError = 0;

+ Exception myException = new Exception();

switch (msgType)

{

case MamaMsgType.TYPE_DELETE:

+ onError (subscription, mywombatStatus,
+ myplatformError,
"Message Type Delete", myException);

+ return;

case MamaMsgType.TYPE_EXPIRE:

subscription.destroy();

mLatestMsg = null;


________________________________

Please consider the environment before printing this e-mail.

This e-mail may contain confidential and/or privileged information. If
you are not the intended recipient or have received this e-mail in
error, please advise the sender immediately by reply e-mail and delete
this message and any attachments without retaining a copy.

Any unauthorised copying, disclosure or distribution of the material
in this e-mail is strictly forbidden.

Please consider the environment before printing this e-mail.

This e-mail may contain confidential and/or privileged information. If you are not the intended recipient or have received this e-mail in error, please advise the sender immediately by reply e-mail and delete this message and any attachments without retaining a copy.

Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden.


Re: Upcoming Patches

Ian Bell <IBell@...>
 

Hi

As these patches were fairly simple and confined to separate areas i just saved off the diffs from the changesets, then applied and tested them individually.

I have a few more complicated patches left to submit but wasn't completely happy with them so held them back. I will use format patch for them.

Ian

-----Original Message-----
From: Mike Schonberg
Sent: 21 May 2012 21:54
To: Ian Bell; openmama-dev@lists.openmama.org
Subject: RE: Upcoming Patches

Ian,

How are you generating the .patch attachments? Git am does not parse them properly; however git apply works. Git am is a lot less work because it extracts the commit comment, etc. from the patch file.

Git format-patch generates a file that works with git am.

Regards,
-Mike

-----Original Message-----
From: openmama-dev-bounces@lists.openmama.org [mailto:openmama-dev-
bounces@lists.openmama.org] On Behalf Of Ian Bell
Sent: Friday, May 18, 2012 8:53 AM
To: openmama-dev@lists.openmama.org
Subject: [Openmama-dev] Upcoming Patches

Hi



The following patches are a result of ongoing maintenance of the
commercial version of MAMA.



Patches will be submitted every 2-3 weeks to this list for review and
application to OpenMAMA. As this is the first set there are a few
more than will usually be the case.



Ian Bell

Senior Software Engineer

NYSE Technologies
IBell@nyx.com




________________________________

Please consider the environment before printing this e-mail.

This e-mail may contain confidential and/or privileged information. If
you are not the intended recipient or have received this e-mail in
error, please advise the sender immediately by reply e-mail and delete
this message and any attachments without retaining a copy.

Any unauthorised copying, disclosure or distribution of the material
in this e-mail is strictly forbidden.

Please consider the environment before printing this e-mail.

This e-mail may contain confidential and/or privileged information. If you are not the intended recipient or have received this e-mail in error, please advise the sender immediately by reply e-mail and delete this message and any attachments without retaining a copy.

Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden.


Re: [PATCH] [mamda] map a delete msg through mamda as an error callback

Mike Schonberg <mschonberg@...>
 

Thanks Ian.

-Mike

-----Original Message-----
From: Ian Bell
Sent: Monday, May 21, 2012 11:39 PM
To: Mike Schonberg; openmama-dev@lists.openmama.org
Subject: RE: [Openmama-dev] [PATCH] [mamda] map a delete msg through
mamda as an error callback



-----Original Message-----
From: Mike Schonberg
Sent: 21 May 2012 21:48
To: Ian Bell; openmama-dev@lists.openmama.org
Subject: RE: [Openmama-dev] [PATCH] [mamda] map a delete msg through
mamda as an error callback



-----Original Message-----
From: openmama-dev-bounces@lists.openmama.org [mailto:openmama-
dev-
bounces@lists.openmama.org] On Behalf Of Ian Bell
Sent: Friday, May 18, 2012 8:58 AM
To: openmama-dev@lists.openmama.org
Subject: [Openmama-dev] [PATCH] [mamda] map a delete msg through
mamda
as an error callback

commit be5ec93af947d5ed9458bf8a5e05b7300a9322d6

Author: Ian Bell <IBell@nyx.com>

Date: Thu May 17 21:47:41 2012 +0100



[mamda] map a delete msg through mamda as an error callback
We need a little more information here. What is a "delete" message?
When/why does it get sent? Why is it an error? This comment will ultimately
go into the release notes.

Regards,
-Mike

When using a MamdaSubscription and a msg of type delete is received
Mamda handles this internally and did not notify the user that this had
happened. As no more messages were received after the delete msg this
symbol effectively stopped ticking. This patch fires a callback on the
MamdaErrorListener to inform the user of the delete msg so they can take
any action they wish based on this information. (eg delete the subscription.)

I will try to be more verbose on any less straight forward patches in future.

Ian


Signed-off-by: Ian Bell <IBell@nyx.com>



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

index 1c48c00..ab51f63 100644

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

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

@@ -94,6 +94,8 @@ typedef enum

MAMA_STATUS_INVALID_QUEUE = 27,

/* Not modifiable */

MAMA_STATUS_NOT_MODIFIABLE = 28,

+ /* Message Type DELETE */

+ MAMA_STATUS_DELETE = 29,

/* Not permissioned for the subject */

MAMA_STATUS_NOT_PERMISSIONED =
4001,

/* Subscription is in an invalid state. */

diff --git a/mama/c_cpp/src/c/status.c b/mama/c_cpp/src/c/status.c

index e8c1c31..f5cb3ff 100644

--- a/mama/c_cpp/src/c/status.c

+++ b/mama/c_cpp/src/c/status.c

@@ -57,6 +57,7 @@ mamaStatus_stringForStatus (mama_status status)

case MAMA_STATUS_NOT_INSTALLED : return "NOT_INSTALLED";

case MAMA_STATUS_NO_BRIDGE_IMPL : return "NO_BRIDGE_IMPL";

case MAMA_STATUS_INVALID_QUEUE : return "INVALID_QUEUE";

+ case MAMA_STATUS_DELETE : return "STATUS_DELETE";

case MAMA_STATUS_NOT_MODIFIABLE : return "NOT_MODIFIABLE";

case MAMA_STATUS_NOT_PERMISSIONED : return
"MAMA_STATUS_NOT_PERMISSIONED";

case MAMA_STATUS_SUBSCRIPTION_INVALID_STATE: return
"MAMA_STATUS_SUBSCRIPTION_INVALID_STATE";

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

index 52060d9..65da8d9 100644

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

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

@@ -81,6 +81,10 @@ public class MamaMsgStatus

/** Message with duplicate sequence number */

public static final short STATUS_DUPLICATE = 15;

+ /** Message with the type of DELETE */

+ public static final short STATUS_DELETE = 17;

+

+

public static final short STATUS_EXCEPTION = 999;

/**

diff --git a/mamda/c_cpp/src/cpp/MamdaSubscription.cpp
b/mamda/c_cpp/src/cpp/MamdaSubscription.cpp

index 9b6599c..d9a9d30 100644

--- a/mamda/c_cpp/src/cpp/MamdaSubscription.cpp

+++ b/mamda/c_cpp/src/cpp/MamdaSubscription.cpp

@@ -471,6 +471,21 @@ namespace Wombat

switch (msgType)

{

case MAMA_MSG_TYPE_DELETE:

+ if (subscription->checkDebugLevel
+ (MAMA_LOG_LEVEL_FINE))

+ {

+ const char *contentSymbol = "N/A";

+ msg.tryString (MamdaCommonFields::ISSUE_SYMBOL,
contentSymbol);

+

+ mama_forceLog (MAMA_LOG_LEVEL_FINE,

+ "MamdaSubscription (%s.%s(%s)) "

+ "ignoring msg. type: %s\n",

+ mSource->getPublisherSourceName(),

+ mSymbol.c_str (),

+ contentSymbol,

+ msg.getMsgTypeName());

+ }

+ onError (subscription,
+ MAMA_STATUS_DELETE , "Msg
Type Delete");

+ return;

case MAMA_MSG_TYPE_EXPIRE:

if (subscription->checkDebugLevel
(MAMA_LOG_LEVEL_FINE))

{

@@ -566,6 +581,11 @@ namespace Wombat

code = MAMDA_ERROR_BAD_SYMBOL;

errStr = "bad symbol";

break;

+ case MAMA_STATUS_DELETE:

+ severity = MAMDA_SEVERITY_OK;

+ code = MAMDA_ERROR_DELETE;

+ errStr = "message type delete";

+ break;

case MAMA_STATUS_TIMEOUT:

severity = MAMDA_SEVERITY_HIGH;

code = MAMDA_ERROR_TIME_OUT;

diff --git a/mamda/c_cpp/src/cpp/mamda/MamdaErrorListener.h
b/mamda/c_cpp/src/cpp/mamda/MamdaErrorListener.h

index d93877f..5168987 100644

--- a/mamda/c_cpp/src/cpp/mamda/MamdaErrorListener.h

+++ b/mamda/c_cpp/src/cpp/mamda/MamdaErrorListener.h

@@ -57,7 +57,7 @@ namespace Wombat

MAMDA_ERROR_TIME_OUT,

MAMDA_ERROR_ENTITLEMENT,

MAMDA_ERROR_NOT_FOUND,

- MAMDA_ERROR_WATCH_THIS_SPACE

+ MAMDA_ERROR_DELETE

};

/**

diff --git a/mamda/java/com/wombat/mamda/MamdaErrorCode.java
b/mamda/java/com/wombat/mamda/MamdaErrorCode.java

index fa25213..59de128 100644

--- a/mamda/java/com/wombat/mamda/MamdaErrorCode.java

+++ b/mamda/java/com/wombat/mamda/MamdaErrorCode.java

@@ -72,6 +72,9 @@ public class MamdaErrorCode

/** Bandwidth exceeded */

public static final short MAMDA_ERROR_BANDWIDTH_EXCEEDED = 14;

+ /** Message of type DELETE */

+ public static final short MAMDA_ERROR_DELETE = 17;

+

public static final short MAMDA_ERROR_EXCEPTION = 999;



@@ -100,6 +103,7 @@ public class MamdaErrorCode

case MAMDA_ERROR_TOPIC_CHANGE: return "TOPIC_CHANGE";

case MAMDA_ERROR_BANDWIDTH_EXCEEDED: return
"BANDWIDTH_EXCEEDED";

case MAMDA_ERROR_EXCEPTION: return "EXCEPTION
PROCESSING
MESSAGE";

+ case MAMDA_ERROR_DELETE: return "MESSAGE TYPE DELETE";

default: return "UNKNOWN";

}

}

@@ -124,6 +128,7 @@ public class MamdaErrorCode

case MamaMsgStatus.STATUS_TOPIC_CHANGE: return
MAMDA_ERROR_TOPIC_CHANGE;

case MamaMsgStatus.STATUS_BANDWIDTH_EXCEEDED: return
MAMDA_ERROR_BANDWIDTH_EXCEEDED;

case MamaMsgStatus.STATUS_EXCEPTION: return
MAMDA_ERROR_EXCEPTION;

+ case MamaMsgStatus.STATUS_DELETE: return
MAMDA_ERROR_DELETE;

}

return -1;

diff --git a/mamda/java/com/wombat/mamda/MamdaSubscription.java
b/mamda/java/com/wombat/mamda/MamdaSubscription.java

index 3d82225..46efd13 100644

--- a/mamda/java/com/wombat/mamda/MamdaSubscription.java

+++ b/mamda/java/com/wombat/mamda/MamdaSubscription.java

@@ -470,10 +470,15 @@ public class MamdaSubscription

short msgType = MamaMsgType.typeForMsg (msg);

int msgStatus = MamaMsgStatus.statusForMsg (msg);

mLatestMsg = msg;

+ short mywombatStatus = 17;

+ int myplatformError = 0;

+ Exception myException = new Exception();

switch (msgType)

{

case MamaMsgType.TYPE_DELETE:

+ onError (subscription, mywombatStatus,
+ myplatformError,
"Message Type Delete", myException);

+ return;

case MamaMsgType.TYPE_EXPIRE:

subscription.destroy();

mLatestMsg = null;


________________________________

Please consider the environment before printing this e-mail.

This e-mail may contain confidential and/or privileged information. If
you are not the intended recipient or have received this e-mail in
error, please advise the sender immediately by reply e-mail and delete
this message and any attachments without retaining a copy.

Any unauthorised copying, disclosure or distribution of the material
in this e-mail is strictly forbidden.
Please consider the environment before printing this email.

Visit our website at http://www.nyse.com

****************************************************

Note: The information contained in this message and any attachment to it is privileged, confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by replying to the message, and please delete it from your system. Thank you. NYSE Euronext.


Re: [PATCH] [common] Added some other pthread calls to linux os abstraction layer

Mike Schonberg <mschonberg@...>
 

Ian,

I believe that we need equivalents defined in common/.../windows/lock.h.

On Fri, 18 May 2012, Ian Bell wrote:


commit cd1c6ae95f2d709136b687f4c40d11a446d4990c

Author: Ian Bell <IBell@nyx.com>

Date: Thu May 17 21:38:59 2012 +0100



[common] Added some other pthread calls to linux os abstraction layer

Signed-off-by: Ian Bell <IBell@nyx.com>



diff --git a/common/c_cpp/src/c/linux/port.h b/common/c_cpp/src/c/linux/port.h

index b40b4fa..a94ac7f 100644

--- a/common/c_cpp/src/c/linux/port.h

+++ b/common/c_cpp/src/c/linux/port.h

@@ -58,6 +58,7 @@ extern "C"

/* PTHREAD static locks are easy */

typedef pthread_mutex_t wthread_static_mutex_t;

#define WSTATIC_MUTEX_INITIALIZER PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP

+#define WTHREAD_MUTEX_RECURSIVE PTHREAD_MUTEX_RECURSIVE
This can be a no-op as Windows condition variables are always recursive.


#define wthread_static_mutex_lock(x) pthread_mutex_lock((x))

#define wthread_static_mutex_unlock(x) pthread_mutex_unlock((x))

@@ -135,6 +136,7 @@ int wsem_timedwait (wsem_t* sem, unsigned int ts);

#define wthread_cond_signal pthread_cond_signal

#define wthread_cond_destroy pthread_cond_destroy

#define wthread_cond_wait pthread_cond_wait

+#define wthread_cond_broadcast pthread_cond_broadcast
We may need to change the implementation to use Windows condition variables or
or change the Event to be manual reset and add locking/and a condition variable
to ensure the desired number of threads run (one or all).

#define wthread_spinlock_t pthread_spinlock_t

#define wthread_spin_init pthread_spin_init

@@ -147,6 +149,7 @@ int wsem_timedwait (wsem_t* sem, unsigned int ts);

#define wthread_mutexattr_t pthread_mutexattr_t

#define wthread_mutexattr_init pthread_mutexattr_init

+#define wthread_mutexattr_destroy pthread_mutexattr_destroy
This will be a no-op as well.

Regards,
-Mike


#define wthread_mutexattr_settype pthread_mutexattr_settype

#define wGetCurrentThreadId pthread_self


______________________________________________________________________________________________________________________________________________________________________________________________________________
Please consider the environment before printing this e-mail.

This e-mail may contain confidential and/or privileged information. If you are not the intended recipient or have received this e-mail in error, please advise the sender immediately by reply e-mail and
delete this message and any attachments without retaining a copy.

Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

Please consider the environment before printing this email.

Visit our website at http://www.nyse.com

****************************************************

Note: The information contained in this message and any attachment to it is privileged, confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by replying to the message, and please delete it from your system. Thank you. NYSE Euronext.


Re: Avis transport and msg bridges not decoupled to allow use of one without the other

Michael Schonberg <mschonberg@...>
 

David,

I think that you may be able to use the Avis payload as it stands purely through
the payload bridge and MamaMsg interfaces. See the inline commentary for
details.

This hightlights the larger issue: we need a good open source payload!
Ultimately, I would like to see a number of open source payloads, but one decent
one would be a good start. I have been looking at Google Protocol Buffers, and I
think that it might work well. This is a topic for another thread, but worth
mentioning here.

On Tue, 22 May 2012, David Ashburner wrote:

Hi Guys, I have been looking that example payload and bridge code and doing
some test coding around building a different bridge. Initially I was thinking
of just doing the bridge and using the Avis msg payload, however I think the
Avis payload and transport bridges are a little tightly coupled to allow one
to be used without the other. this may be inadvertent or done for optimisation
reasons but given it is the only example is not so good.
I agree that the coupling you describe is not good. I think that it is possible
to use the Avis payload in another transport without using the Attributes
directly. The Avis transport needs the Attributes to specify the topic as I
describe below. Other middlewares should be able simply use the MamaMsg and
msgBridge APIs.

Payloads and transports are intended to be completely independent in OpenMAMA:
transports should pass byte arrays to payloads to decode incoming messages and
rely on the payload implementation to encode messages to byte arrays for
publishing.

The Avis middleware/transport bridge access the Attributes directly in the
following methods from msg.c:
avisBridgeMamaMsg_destroyMiddlewareMsg()
avisBridgeMamaMsg_detach()
avisBridgeMamaMsg_getNativeHandle()
avisBridgeMamaMsgImpl_setAttributesAndSecure()

I think that they could all be replaced to mamaMsg_xxx() and msgBrdige->xxx()
calls, but I need to take a closer look to be certain.

I will reach out to the author of the bridge and try to determine the rational
for accessing the Attributes directly rather than through the bridge.


I am assuming that a transport bridge should be able to function without any
hard coded information about the payload format being used, so in the code
fragment below the passed in mamaMsg could be one of a nunber of payload
implementations. The call mamaMsgImpl_getPayloadBuffer() should return a
packed message buffer ready for passing to the transport for sending.
This is correct; however, the Avis transport can only send Avis "Attribute"
objects and it musg add topic information to the Attributes prior to
publishing and extract them on receipt. This is necessary because Avis/Elvin is
content based rather than topic based. We fake topic based messaging by adding a
field that specifies the topic for the message and subscribe to all messages
that contain the desired topic field value. This code is in publisher.c (the
code you quote below) and sub.c.

Other transports for topic based middlewares should not need to embed the topic
in the payload, and therefore, do not need cast the void pointers to Attributes.

Regards,
-Mike


The Avis transport bridge makes the assumption that it will receive an
Attribute object, tweaks with this object then passes it to the sending
routine. I can see why it is more efficient for the getPayloadBuffer to return
the Attribute object rather than a flattened buffer as the later elvin_send
call takes and Attribute object as a parameter so to avoid serialising and
un-serialising again the assumption is made that a pointer to the Attribute
object will be passed.

Digging upstream inside the getPayloadBuffer() call it is resolved to the avis
payload bridge function avismsgPayload_getByteBuffer(). In this function a
pointer to the Attributes is returned instead of the Attributes being
serialised with avismsgPayload_serialize(). I understand that is not optimal
to serialize, then have to unserialize again only to have the message
serialized again in the send but I'm thinking that ba more flexible solution
would be to do it properly and create a patch to Avis to add a send method for
a pre-serialised buffer.

Interested if anyone else has come across this and if any sees it as a
problem. Regards, David

snip ----bridge/avis/publish.c ----x

 146 /*Send a message.*/
 147 mama_status
 148 avisBridgeMamaPublisher_send (publisherBridge publisher, mamaMsg msg)
 149 {
 150     mama_size_t        dataLen;
 151     mama_status        status
 152     Attributes* attributes = NULL;
 153    
 154     CHECK_PUBLISHER(publisher);
 155
 156     status = mamaMsgImpl_getPayloadBuffer (msg, (const void**)&attributes, &dataLen);
 157     if (attributes == NULL)
 158         return MAMA_STATUS_INVALID_ARG;
 159
 160     mamaMsg_updateString(msg, SUBJECT_FIELD_NAME, 0, avisPublisher(publisher)->mSubject);
 161
 162     if (!elvin_send(avisPublisher(publisher)->mAvis, attributes)) {
 163         mama_log (MAMA_LOG_LEVEL_ERROR, "avisBridgeMamaPublisher_send(): "
 164                   "Could not send message.");
 165         return MAMA_STATUS_PLATFORM;
 166     }



Re: [PATCH] [common] Added some other pthread calls to linux os abstraction layer

Ian Bell <IBell@...>
 

Hi Mike

As you have pointed out below adding this to windows is a bit less straightforward and requires a bit more testing. I was going to bundle the windows code together with some other patches i have for the windows layer to cut down on the testing effort.

To this end iI have also been adding some unittests to the common folder to facilitate testing of these components separately from mama.

As i have not yet submitted any patches which require this feature to be present in the abstraction layer i can hold this patch until such time as the windows version is ready if you prefer.

Ian

-----Original Message-----
From: Mike Schonberg
Sent: 23 May 2012 01:32
To: Ian Bell; openmama-dev@lists.openmama.org
Subject: RE: [PATCH] [common] Added some other pthread calls to linux os abstraction layer


Ian,

I believe that we need equivalents defined in common/.../windows/lock.h.

On Fri, 18 May 2012, Ian Bell wrote:


commit cd1c6ae95f2d709136b687f4c40d11a446d4990c

Author: Ian Bell <IBell@nyx.com>

Date: Thu May 17 21:38:59 2012 +0100



[common] Added some other pthread calls to linux os abstraction
layer

Signed-off-by: Ian Bell <IBell@nyx.com>



diff --git a/common/c_cpp/src/c/linux/port.h
b/common/c_cpp/src/c/linux/port.h

index b40b4fa..a94ac7f 100644

--- a/common/c_cpp/src/c/linux/port.h

+++ b/common/c_cpp/src/c/linux/port.h

@@ -58,6 +58,7 @@ extern "C"

/* PTHREAD static locks are easy */

typedef pthread_mutex_t wthread_static_mutex_t;

#define WSTATIC_MUTEX_INITIALIZER
PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP

+#define WTHREAD_MUTEX_RECURSIVE PTHREAD_MUTEX_RECURSIVE
This can be a no-op as Windows condition variables are always recursive.


#define wthread_static_mutex_lock(x) pthread_mutex_lock((x))

#define wthread_static_mutex_unlock(x) pthread_mutex_unlock((x))

@@ -135,6 +136,7 @@ int wsem_timedwait (wsem_t* sem, unsigned int ts);

#define wthread_cond_signal pthread_cond_signal

#define wthread_cond_destroy pthread_cond_destroy

#define wthread_cond_wait pthread_cond_wait

+#define wthread_cond_broadcast pthread_cond_broadcast
We may need to change the implementation to use Windows condition variables or or change the Event to be manual reset and add locking/and a condition variable to ensure the desired number of threads run (one or all).

#define wthread_spinlock_t pthread_spinlock_t

#define wthread_spin_init pthread_spin_init

@@ -147,6 +149,7 @@ int wsem_timedwait (wsem_t* sem, unsigned int ts);

#define wthread_mutexattr_t pthread_mutexattr_t

#define wthread_mutexattr_init pthread_mutexattr_init

+#define wthread_mutexattr_destroy pthread_mutexattr_destroy
This will be a no-op as well.

Regards,
-Mike


#define wthread_mutexattr_settype pthread_mutexattr_settype

#define wGetCurrentThreadId pthread_self


______________________________________________________________________
______________________________________________________________________
__________________________________________________________________
Please consider the environment before printing this e-mail.

This e-mail may contain confidential and/or privileged information. If
you are not the intended recipient or have received this e-mail in error, please advise the sender immediately by reply e-mail and delete this message and any attachments without retaining a copy.

Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

Please consider the environment before printing this e-mail.

This e-mail may contain confidential and/or privileged information. If you are not the intended recipient or have received this e-mail in error, please advise the sender immediately by reply e-mail and delete this message and any attachments without retaining a copy.

Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden.


Re: [PATCH] [common] Added some other pthread calls to linux os abstraction layer

Michael Schonberg <mschonberg@...>
 

On Wed, 23 May 2012, Ian Bell wrote:

Hi Mike

As you have pointed out below adding this to windows is a bit less
straightforward and requires a bit more testing. I was going to bundle the
windows code together with some other patches i have for the windows layer to
cut down on the testing effort.
That is fine. As long as it makes it in.

To this end iI have also been adding some unittests to the common folder to
facilitate testing of these components separately from mama.

As i have not yet submitted any patches which require this feature to be
present in the abstraction layer i can hold this patch until such time as the
windows version is ready if you prefer.
I will hold the patch back until you submit the windows changes, and push them
together.

I plan on pushing your other patches to a "next" branch for pending changes, and
I will leave this one out until the Windows changes are ready.

Regards,
-Mike


Ian

-----Original Message-----
From: Mike Schonberg
Sent: 23 May 2012 01:32
To: Ian Bell; openmama-dev@lists.openmama.org
Subject: RE: [PATCH] [common] Added some other pthread calls to linux os abstraction layer


Ian,

I believe that we need equivalents defined in common/.../windows/lock.h.

On Fri, 18 May 2012, Ian Bell wrote:


commit cd1c6ae95f2d709136b687f4c40d11a446d4990c

Author: Ian Bell <IBell@nyx.com>

Date: Thu May 17 21:38:59 2012 +0100



[common] Added some other pthread calls to linux os abstraction
layer

Signed-off-by: Ian Bell <IBell@nyx.com>



diff --git a/common/c_cpp/src/c/linux/port.h
b/common/c_cpp/src/c/linux/port.h

index b40b4fa..a94ac7f 100644

--- a/common/c_cpp/src/c/linux/port.h

+++ b/common/c_cpp/src/c/linux/port.h

@@ -58,6 +58,7 @@ extern "C"

/* PTHREAD static locks are easy */

typedef pthread_mutex_t wthread_static_mutex_t;

#define WSTATIC_MUTEX_INITIALIZER
PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP

+#define WTHREAD_MUTEX_RECURSIVE PTHREAD_MUTEX_RECURSIVE
This can be a no-op as Windows condition variables are always recursive.


#define wthread_static_mutex_lock(x) pthread_mutex_lock((x))

#define wthread_static_mutex_unlock(x) pthread_mutex_unlock((x))

@@ -135,6 +136,7 @@ int wsem_timedwait (wsem_t* sem, unsigned int ts);

#define wthread_cond_signal pthread_cond_signal

#define wthread_cond_destroy pthread_cond_destroy

#define wthread_cond_wait pthread_cond_wait

+#define wthread_cond_broadcast pthread_cond_broadcast
We may need to change the implementation to use Windows condition variables or or change the Event to be manual reset and add locking/and a condition variable to ensure the desired number of threads run (one or all).

#define wthread_spinlock_t pthread_spinlock_t

#define wthread_spin_init pthread_spin_init

@@ -147,6 +149,7 @@ int wsem_timedwait (wsem_t* sem, unsigned int ts);

#define wthread_mutexattr_t pthread_mutexattr_t

#define wthread_mutexattr_init pthread_mutexattr_init

+#define wthread_mutexattr_destroy pthread_mutexattr_destroy
This will be a no-op as well.

Regards,
-Mike


#define wthread_mutexattr_settype pthread_mutexattr_settype

#define wGetCurrentThreadId pthread_self


______________________________________________________________________
______________________________________________________________________
__________________________________________________________________
Please consider the environment before printing this e-mail.

This e-mail may contain confidential and/or privileged information. If
you are not the intended recipient or have received this e-mail in error, please advise the sender immediately by reply e-mail and delete this message and any attachments without retaining a copy.

Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

Please consider the environment before printing this e-mail.

This e-mail may contain confidential and/or privileged information. If you are not the intended recipient or have received this e-mail in error, please advise the sender immediately by reply e-mail and delete this message and any attachments without retaining a copy.

Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden.
_______________________________________________
Openmama-dev mailing list
Openmama-dev@lists.openmama.org
http://lists.openmama.org/listinfo/openmama-dev


OpenMAMA-2.1.1.2 and New Branches

Michael Schonberg <mschonberg@...>
 

I pushed a number of changes to the git repository this week, and created two
new branches.

The new branches are "next" and OpenMama-2.1.1. The next branch contains all the
patches submitted to the mailing list that are under consideration for the next
scheduled release, OpenMAMA-2.1.2. This includes all of the patches submitted to
openmama-dev thus far. The OpenMAMA-2.1.1 branch is the current stable branch
starting from the April 29 2.1.1.1 release which is tagged with
OpenMAMA-2.1.1.1. Only critical bug fixes and very low impact changes will be
merged into the stable branches. All changes to the stable branches must be
first committed to master.

I will be posting additional details on the development cycle and how changes
get into the next, master and stable branches to the web site and openmama-dev
in the coming days.

The changes for 2.1.1.2 are described below. The source and binaries are not
available on the web site yet as there are some issues uploading files at the
moment. I expect to have this resolved shortly.

Regards,
-Michael Schonberg <mschonberg@nyx.com>

CHANGES:
OpenMAMA 2.1.1.2

This release contains very minor fixes focusing on the build environment. The
2.1.1.1 release, which introduced OpenMAMDA in addition to C++ and Java support,
complicated the build environment significantly. These changes address some of
the build issues encountered. Subsequent minor releases will attempt to further
simplify the build process.

Changes:

Add patch for -lmama for news and orderbook examples

The news and orderbook examples were not building because the linker could
not find libmama. This patch adjusts the link flags to include the path to
the mama c libraries.

Signed-off-by: Mike Schonberg <mschonberg@nyx.com>

Add libpthread to library list for sem_timedwait

configure.ac needs to search for sem_timedwait in both librt and libpthread.
On OS's like certain Solaris versions that do not support sem_timedwait(),
OpenMAMA provides an implentation.

Signed-off-by: Mike Schonberg <mschonberg@nyx.com>

Updated Build Instructions

Added better download and build instructions for the Avis client and router.

For the OpenMAMA build it is necessary to specify --with-avis to build the
Avis bridge, and it is also necessary to invoke generateBuildFiles.sh prior
to building source from a cloned git repository.

Signed-off-by: Mike Schonberg <mschonberg@nyx.com>

[mama] Adding .gitignore

This patch introduces a .gitignore file to force git to skip known build
artifacts when displaying status information.

Signed-off-by: Mark Spielman <mark.spielman@solacesystems.com>


OpenMama Bridge Developer Guide

Jacobraj Benet <JBenet@...>
 

Hello everyone,

Find attached the initial draft of the OpenMAMA Bridge developers Guide, This is an initial draft and would be refined and improved over the coming weeks.

Please do provide any feedbacks/recommendation regarding this document to the dev list.

We are also able to contribute some the resourcing from our tech writer team, the week of the 25th to finalize this document and if possible feedback in advance would be appreciated.

Thanks,
Jacob


Please consider the environment before printing this email.

Visit our website at http://www.nyse.com
*****************************************************************************
Note: The information contained in this message and any attachment to it is privileged, confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by replying to the message, and please delete it from your system. Thank you. NYSE Euronext.


Re: OpenMama Bridge Developer Guide

Glenn McClements <gmcclements@...>
 

Jacob (and other folks),
Any chance this can be moved to some form of Wiki for community editing? I'm reviewing the doc and am noting down changes, but it would be just as quick to edit the doc itself if it was available. 

Glenn 

From: Jacobraj Benet <JBenet@...>
Date: Tue, 12 Jun 2012 17:33:44 +0100
To: "openmama-dev@..." <openmama-dev@...>
Subject: [Openmama-dev] OpenMama Bridge Developer Guide

Hello everyone,

Find attached the initial draft of the OpenMAMA Bridge developers Guide, This is an initial draft and would be refined and improved over the coming weeks.

Please do provide any feedbacks/recommendation regarding this document to the dev list.

We are also able to contribute some the resourcing from our tech writer team, the week of the 25th to finalize this document and if possible feedback in advance would be appreciated.

Thanks,
Jacob


Please consider the environment before printing this email.

Visit our website at http://www.nyse.com
*****************************************************************************
Note: The information contained in this message and any attachment to it is privileged, confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by replying to the message, and please delete it from your system. Thank you. NYSE Euronext.



Please consider the environment before printing this e-mail.

This e-mail may contain confidential and/or privileged information. If you are not the intended recipient or have received this e-mail in error, please advise the sender immediately by reply e-mail and delete this message and any attachments without retaining a copy.

Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden.


Re: OpenMama Bridge Developer Guide

Mike Schonberg <mschonberg@...>
 

Glenn,

 

A Wiki is a good idea. In the meantime, can you make the revisions in the word doc for the time being. We are also planning on adding a section on how to implement minimal bridge functionality. Jacob is working on that now.

 

Regards,

-Mike

 

From: openmama-dev-bounces@... [mailto:openmama-dev-bounces@...] On Behalf Of Glenn McClements
Sent: Wednesday, June 13, 2012 7:28 AM
To: Jacobraj Benet; openmama-dev@...
Subject: Re: [Openmama-dev] OpenMama Bridge Developer Guide

 

Jacob (and other folks),

Any chance this can be moved to some form of Wiki for community editing? I'm reviewing the doc and am noting down changes, but it would be just as quick to edit the doc itself if it was available. 

 

Glenn 

 

From: Jacobraj Benet <JBenet@...>
Date: Tue, 12 Jun 2012 17:33:44 +0100
To: "openmama-dev@..." <openmama-dev@...>
Subject: [Openmama-dev] OpenMama Bridge Developer Guide

 

Hello everyone,

 

Find attached the initial draft of the OpenMAMA Bridge developers Guide, This is an initial draft and would be refined and improved over the coming weeks.

 

Please do provide any feedbacks/recommendation regarding this document to the dev list.

 

We are also able to contribute some the resourcing from our tech writer team, the week of the 25th to finalize this document and if possible feedback in advance would be appreciated.

 

Thanks,

Jacob


Please consider the environment before printing this email.

Visit our website at http://www.nyse.com
*****************************************************************************
Note: The information contained in this message and any attachment to it is privileged, confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by replying to the message, and please delete it from your system. Thank you. NYSE Euronext.

 


Please consider the environment before printing this e-mail.

This e-mail may contain confidential and/or privileged information. If you are not the intended recipient or have received this e-mail in error, please advise the sender immediately by reply e-mail and delete this message and any attachments without retaining a copy.

Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden.


Please consider the environment before printing this email.

Visit our website at http://www.nyse.com
*****************************************************************************
Note: The information contained in this message and any attachment to it is privileged, confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by replying to the message, and please delete it from your system. Thank you. NYSE Euronext.


Re: OpenMama Bridge Developer Guide

Jacobraj Benet <JBenet@...>
 

Also find attached the initial draft of the Bridge Developer Guide in word document format.

Do reply back with any suggestions.

Thanks,
Jacob

From: Jacobraj Benet <jbenet@...>
Date: Tuesday, June 12, 2012 11:33 AM
To: "openmama-dev@..." <openmama-dev@...>
Subject: OpenMama Bridge Developer Guide

Hello everyone,

Find attached the initial draft of the OpenMAMA Bridge developers Guide, This is an initial draft and would be refined and improved over the coming weeks.

Please do provide any feedbacks/recommendation regarding this document to the dev list.

We are also able to contribute some the resourcing from our tech writer team, the week of the 25th to finalize this document and if possible feedback in advance would be appreciated.

Thanks,
Jacob


Please consider the environment before printing this email.

Visit our website at http://www.nyse.com
*****************************************************************************
Note: The information contained in this message and any attachment to it is privileged, confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by replying to the message, and please delete it from your system. Thank you. NYSE Euronext.


Соберем gля Вас по сeти интeрнет базу gaнных пoтенциaльных клиeнтoв для Вашeго Бизнеcа Bce контakты Пoдpoбнeе Email:prodawez@mixmail.com Тeл:+79IЗ79З6ЗЧ2 Skype:s.3837 ICQ:6288862

openmama-dev@...
 

Соберем gля Вас по сeти интeрнет базу gaнных
пoтенциaльных клиeнтoв для Вашeго Бизнеcа
Bce контakты Пoдpoбнeе по
Email: prodawez@mixmail.com
Тeл: +79IЗ79З6ЗЧ2
Skype: s.3837
ICQ: 6288862
CONFIDENTIALITY NOTICE:
This is a transmission from Kohl's Department Stores, Inc.
and may contain information which is confidential and proprietary.
If you are not the addressee, any disclosure, copying or distribution or use of the contents of this message is expressly prohibited.
If you have received this transmission in error, please destroy it and notify us immediately at 262-703-7000.

CAUTION:
Internet and e-mail communications are Kohl's property and Kohl's reserves the right to retrieve and read any message created, sent and received. Kohl's reserves the right to monitor messages by authorized Kohl's Associates at any time
without any further consent.


Open Data Model Docs available for feedback (OpenMDM)

Jamie Hill
 

Hey All,

We are delighted to announce the release of the OpenMDM Phase 2 Equities and Indices Consultation documentation which shall be published over the next week.  

In this first documentation release, the following have been provided:

1.       A quick reference guide providing background information to the initiative and detailing the current documentation under release - OpenMDM_QuickReference_2.0.pdf

2.       The OpenMDM Reference Guide  - OpenMDM Reference Guide 2.0.pdf

Both documents can be obtained upon request from opendatamodel@...

Early next week we shall be adding a feedback tracker document onto Google docs which will enable you to browse and comment on general feedback received throughout the consultation period which will run from the 9th of July until the 30th of July.


Regards,


Jamie

www.openmama.org


Issues with make clean

Mark Spielman
 

I cloned the OpenMAMA 2.1 build and did:

 

./generateBuildFiles.sh

./configure --prefix=$PWD/openmama-install --avis-path=<internal-path>/avis-install

make

make install

 

This was successful. Then I tried a make clean and got the following error. It seems to me without digging to deeply into this, that the make clean has issues with the jni files. Is anyone else seeing this?

 

BUILD SUCCESSFUL

Total time: 0 seconds

make[1]: Entering directory `/home/mspielman/svndir/rnd_openmama/mama/jni'

CDPATH="${ZSH_VERSION+.}:" && cd . && /bin/sh /home/mspielman/svndir/rnd_openmama/mama/jni/etc/missing --run aclocal-1.11

/bin/sh: /home/mspielman/svndir/rnd_openmama/mama/jni/etc/missing: No such file or directory

make[1]: *** [aclocal.m4] Error 127

make[1]: Leaving directory `/home/mspielman/svndir/rnd_openmama/mama/jni'

/home/mspielman/svndir/rnd_openmama

rm -r mama/jni/mamajni

rm: cannot remove `mama/jni/mamajni': No such file or directory

make: *** [mamajni-clean] Error 1

 

Cheers,

Mark

 

 

 

 

Mark Spielman

Development Lead, Solace Systems Professional Services
+1-613-271-1010 x1021

mark.spielman@...

www.solacesystems.com

 

 


Question about adding subscriptions without refresh.

Mark Spielman
 

In developing a transport bridge for openMAMA, I came across what I believe is an issue with mama/c_cpp/src/c/transport.c. The mamaTransport_addSubscription() will return MAMA_STATUS_NOMEM if the self->mRefreshTransport is not set. This blocked us from successfully establishing a subscription in the case where a refresh was not desired.

 

I have a patch that I could submit that would change the method to the following. But before doing so, I’d like to ask if there is anything I missed? Below is how we updated the code to work.

 

mama_status

mamaTransport_addSubscription (mamaTransport    transport,

                               mamaSubscription subscription,

                               void**           result)

{

    SubscriptionInfo*   handle = NULL;

 

    if (self->mRefreshTransport) {

        handle = refreshTransport_allocateSubscInfo (self->mRefreshTransport);

 

        if (handle == NULL) return MAMA_STATUS_NOMEM;

 

        handle->mSubscription = subscription;

    }

    *result = handle;

 

    if (self->mRefreshTransport)

        refreshTransport_addSubscription (self->mRefreshTransport, handle);

 

    return MAMA_STATUS_OK;

}

 

Thanks

Mark

 

 

 

 

Mark Spielman

Development Lead, Solace Systems Professional Services
+1-613-271-1010 x1021

mark.spielman@...

www.solacesystems.com

 

 


Re: Issues with make clean

Mike Schonberg <mschonberg@...>
 

Mark,

 

Is your Java build succeeding? You can tell by the presence of libmamajni.so in your lib directory. I suspect that it might not be which might cause the clean step to fail.

 

If you are not using java, or MAMDA you can run “make mama-install” to build only OpenMAMA C/C++. I plan to re-work the build scripts to build less by default in the near future.

 

Regards,

-Mike

 

From: openmama-dev-bounces@... [mailto:openmama-dev-bounces@...] On Behalf Of Mark Spielman
Sent: Wednesday, July 11, 2012 12:55 PM
To: openmama-dev@...
Subject: [Openmama-dev] Issues with make clean

 

I cloned the OpenMAMA 2.1 build and did:

 

./generateBuildFiles.sh

./configure --prefix=$PWD/openmama-install --avis-path=<internal-path>/avis-install

make

make install

 

This was successful. Then I tried a make clean and got the following error. It seems to me without digging to deeply into this, that the make clean has issues with the jni files. Is anyone else seeing this?

 

BUILD SUCCESSFUL

Total time: 0 seconds

make[1]: Entering directory `/home/mspielman/svndir/rnd_openmama/mama/jni'

CDPATH="${ZSH_VERSION+.}:" && cd . && /bin/sh /home/mspielman/svndir/rnd_openmama/mama/jni/etc/missing --run aclocal-1.11

/bin/sh: /home/mspielman/svndir/rnd_openmama/mama/jni/etc/missing: No such file or directory

make[1]: *** [aclocal.m4] Error 127

make[1]: Leaving directory `/home/mspielman/svndir/rnd_openmama/mama/jni'

/home/mspielman/svndir/rnd_openmama

rm -r mama/jni/mamajni

rm: cannot remove `mama/jni/mamajni': No such file or directory

make: *** [mamajni-clean] Error 1

 

Cheers,

Mark

 

 

 

 

Mark Spielman

Development Lead, Solace Systems Professional Services
+1-613-271-1010 x1021

mark.spielman@...

www.solacesystems.com

 

 


Please consider the environment before printing this email.

Visit our website at http://www.nyse.com
*****************************************************************************
Note: The information contained in this message and any attachment to it is privileged, confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by replying to the message, and please delete it from your system. Thank you. NYSE Euronext.


Re: Question about adding subscriptions without refresh.

mschonberg <mschonberg@...>
 

Mark,

Your fix is correct. The current implementation is clearly wrong. I am not sure
when this was introduced, but I suspect it was a recent change. It might be
worth looking into.

Regards,
-Mike

On Wed, 11 Jul 2012, Mark Spielman wrote:


In developing a transport bridge for openMAMA, I came across what I believe
is an issue with mama/c_cpp/src/c/transport.c. The
mamaTransport_addSubscription() will return MAMA_STATUS_NOMEM if the
self->mRefreshTransport is not set. This blocked us from successfully
establishing a subscription in the case where a refresh was not desired.

 

I have a patch that I could submit that would change the method to the
following. But before doing so, I’d like to ask if there is anything I
missed? Below is how we updated the code to work.



mama_status
mamaTransport_addSubscription (mamaTransport    transport,
                               mamaSubscription subscription,
                               void**           result)
{
    SubscriptionInfo*   handle = NULL;
 
    if (self->mRefreshTransport) {
        handle = refreshTransport_allocateSubscInfo (self->mRefreshTransport);
 
        if (handle == NULL) return MAMA_STATUS_NOMEM;
 
        handle->mSubscription = subscription;
    }

    *result = handle;

    if (self->mRefreshTransport)
        refreshTransport_addSubscription (self->mRefreshTransport, handle);

    return MAMA_STATUS_OK;
}

 

Thanks

Mark

 

 

 

 

Mark Spielman

Development Lead, Solace Systems Professional Services
+1-613-271-1010 x1021

mark.spielman@solacesystems.com

www.solacesystems.com

 

 



Re: Question about adding subscriptions without refresh.

Mark Spielman
 

Thanks Mike. Would you like me to post the fix as a proper patch then? Or would you like to look through the submissions and back track on when this was introduced?

Cheers,
Mark

-----Original Message-----
From: Michael Schonberg [mailto:mikeschonberg@gmail.com] On Behalf Of mschonberg
Sent: Wednesday, July 11, 2012 9:00 PM
To: Mark Spielman
Cc: openmama-dev@lists.openmama.org
Subject: Re: [Openmama-dev] Question about adding subscriptions without refresh.

Mark,

Your fix is correct. The current implementation is clearly wrong. I am not sure when this was introduced, but I suspect it was a recent change. It might be worth looking into.

Regards,
-Mike

On Wed, 11 Jul 2012, Mark Spielman wrote:


In developing a transport bridge for openMAMA, I came across what I
believe is an issue with mama/c_cpp/src/c/transport.c. The
mamaTransport_addSubscription() will return MAMA_STATUS_NOMEM if the
self->mRefreshTransport is not set. This blocked us from successfully
establishing a subscription in the case where a refresh was not desired.

 

I have a patch that I could submit that would change the method to the
following. But before doing so, I’d like to ask if there is anything I
missed? Below is how we updated the code to work.



mama_status
mamaTransport_addSubscription (mamaTransport    transport,
                               mamaSubscription subscription,
                               void**           result) {
    SubscriptionInfo*   handle = NULL;
 
    if (self->mRefreshTransport) {
        handle = refreshTransport_allocateSubscInfo
(self->mRefreshTransport);
 
        if (handle == NULL) return MAMA_STATUS_NOMEM;
 
        handle->mSubscription = subscription;
    }

    *result = handle;

    if (self->mRefreshTransport)
        refreshTransport_addSubscription (self->mRefreshTransport,
handle);

    return MAMA_STATUS_OK;
}

 

Thanks

Mark

 

 

 

 

Mark Spielman

Development Lead, Solace Systems Professional Services
+1-613-271-1010 x1021

mark.spielman@solacesystems.com

www.solacesystems.com

 

 



Re: Issues with make clean

Mark Spielman
 

Thanks Mike. I will investigate further and report back when I have a second to revert to this clean state.

 

Cheers,

Mark

 

From: Mike Schonberg [mailto:mschonberg@...]
Sent: Wednesday, July 11, 2012 8:44 PM
To: Mark Spielman; openmama-dev@...
Subject: RE: Issues with make clean

 

Mark,

 

Is your Java build succeeding? You can tell by the presence of libmamajni.so in your lib directory. I suspect that it might not be which might cause the clean step to fail.

 

If you are not using java, or MAMDA you can run “make mama-install” to build only OpenMAMA C/C++. I plan to re-work the build scripts to build less by default in the near future.

 

Regards,

-Mike

 

From: openmama-dev-bounces@... [mailto:openmama-dev-bounces@...] On Behalf Of Mark Spielman
Sent: Wednesday, July 11, 2012 12:55 PM
To: openmama-dev@...
Subject: [Openmama-dev] Issues with make clean

 

I cloned the OpenMAMA 2.1 build and did:

 

./generateBuildFiles.sh

./configure --prefix=$PWD/openmama-install --avis-path=<internal-path>/avis-install

make

make install

 

This was successful. Then I tried a make clean and got the following error. It seems to me without digging to deeply into this, that the make clean has issues with the jni files. Is anyone else seeing this?

 

BUILD SUCCESSFUL

Total time: 0 seconds

make[1]: Entering directory `/home/mspielman/svndir/rnd_openmama/mama/jni'

CDPATH="${ZSH_VERSION+.}:" && cd . && /bin/sh /home/mspielman/svndir/rnd_openmama/mama/jni/etc/missing --run aclocal-1.11

/bin/sh: /home/mspielman/svndir/rnd_openmama/mama/jni/etc/missing: No such file or directory

make[1]: *** [aclocal.m4] Error 127

make[1]: Leaving directory `/home/mspielman/svndir/rnd_openmama/mama/jni'

/home/mspielman/svndir/rnd_openmama

rm -r mama/jni/mamajni

rm: cannot remove `mama/jni/mamajni': No such file or directory

make: *** [mamajni-clean] Error 1

 

Cheers,

Mark

 

 

 

 

Mark Spielman

Development Lead, Solace Systems Professional Services
+1-613-271-1010 x1021

mark.spielman@...

www.solacesystems.com

 

 


Please consider the environment before printing this email.

Visit our website at http://www.nyse.com
*****************************************************************************
Note: The information contained in this message and any attachment to it is privileged, confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by replying to the message, and please delete it from your system. Thank you. NYSE Euronext.

201 - 220 of 2305