Date   

Re: Question about adding subscriptions without refresh.

mschonberg <mschonberg@...>
 

On Thu, 12 Jul 2012, Mark Spielman wrote:

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?
I found the problem. We previously had unnecessary #ifdef's that allowed us to
conditionally compile MAMA without any refresh logic. When we removed the
conditional compilation, we erroneously deleted the code that maintained the
list of subscriptions in the parent transport rather than the "refresh"
transport. A patch that restores the correct logic will follow shortly.

Regards,
-Mike


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

 

 


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


[PATCH] [mama] Use local subscription list when refreshes disabled

mschonberg@...
 

From: Mike Schonberg <mschonberg@nyx.com>

Normally, with refreshes enabled, mamaTransport delegates maintaining a list of
subscriptions to the refresh sub-transport; however, when refreshes are disabled
with the "disable_refresh" transport property or programatically, the
mamaTransport must maintain this list. A previous refactoring effort,
erroneously removed the code that maintained this list when refresh messages are
disabled. This patch restores that code.

Signed-off-by: Michael Schonberg <mschobnerg@nyx.com>
---
mama/c_cpp/src/c/transport.c | 24 ++++++++++++++++++++++++
1 files changed, 24 insertions(+), 0 deletions(-)

diff --git a/mama/c_cpp/src/c/transport.c b/mama/c_cpp/src/c/transport.c
index d51d12d..742f05b 100644
--- a/mama/c_cpp/src/c/transport.c
+++ b/mama/c_cpp/src/c/transport.c
@@ -1549,6 +1549,8 @@ mamaTransport_addSubscription (mamaTransport transport,

if (self->mRefreshTransport)
handle = refreshTransport_allocateSubscInfo (self->mRefreshTransport);
+ else
+ handle = (SubscriptionInfo*)list_allocate_element (self->mListeners);

if (handle == NULL) return MAMA_STATUS_NOMEM;

@@ -1558,6 +1560,8 @@ mamaTransport_addSubscription (mamaTransport transport,

if (self->mRefreshTransport)
refreshTransport_addSubscription (self->mRefreshTransport, handle);
+ else
+ list_push_back (self->mListeners, handle);

return MAMA_STATUS_OK;
}
@@ -1572,6 +1576,11 @@ mamaTransport_removeListener (mamaTransport transport, void* handle)
{
refreshTransport_removeListener (self->mRefreshTransport, handle, 1);
}
+ else
+ {
+ list_remove_element (self->mListeners, handle);
+ list_free_element (self->mListeners, handle);
+ }

return MAMA_STATUS_OK;
}
@@ -1689,6 +1698,10 @@ setPossiblyStaleForListeners (transportImpl* transport)
refreshTransport_iterateListeners (self->mRefreshTransport,
setStaleListenerIterator, NULL);
}
+ else
+ {
+ list_for_each( self->mListeners, setStaleListenerIterator, NULL );
+ }
}

preInitialScheme
@@ -1831,6 +1844,9 @@ mamaTransportImpl_getTopicsAndTypesForSource (mamaTransport transport,
*/
if (self->mRefreshTransport)
size = refreshTransport_numListeners (self->mRefreshTransport);
+ else
+ size = list_size (self->mListeners);
+

closure.topics =
(const char**) calloc (sizeof (char*), size);
@@ -1847,6 +1863,10 @@ mamaTransportImpl_getTopicsAndTypesForSource (mamaTransport transport,
refreshTransport_iterateListeners (self->mRefreshTransport,
topicsForSourceIterator, &closure);
}
+ else
+ {
+ list_for_each (self->mListeners, topicsForSourceIterator, &closure);
+ }

*topics = closure.topics;
*types = closure.types;
@@ -2489,6 +2509,10 @@ void mamaTransportImpl_clearTransportWithListeners (transportImpl *impl)
refreshTransport_iterateListeners (impl->mRefreshTransport,
mamaTransportImpl_clearTransportCallback, NULL);
}
+ else
+ {
+ list_for_each(impl->mListeners, mamaTransportImpl_clearTransportCallback, NULL);
+ }
}

void mamaTransportImpl_clearTransportWithPublishers (transportImpl *impl)
--
1.7.7.6


[RFC] Continuous Integration Proposal

mschonberg <mschonberg@...>
 

Mike Ritchie from J.P. Morgan was kind enough to draft this very thorough
proposal and roadmap to establish continuous integration (CI) for OpenMAMA. The
proposal addresses many of the challenges around testing applications
written in many programming languages and specifically the limited tools
available for C/C++.

The document also breaks adoption of CI into multiple stages:
1. Provision a server with Jenkins to automate build and existing tests.
2. Add code coverage for Java and C/C++
3. Memory safety (using Valgrind) for C/C++
4. Static code analysis
5. Use Robot Framework for new regression tests and ATDD (Acceptance Test
Driven Development).
6. Use CI to generate current documentation
7. Create a summary dashboard
8. Use Coverity or a similar tool to manage code structure

If there are others on this mailing list experienced with CI, any suggestions
and feedback would be very useful.

Regards,
-Mike


Re: [RFC] Continuous Integration Proposal

Raph Cohn
 

Jenkins is a good choice as a CI server. Ideally, we'd want to run a small build farm targeting the main CPU / OS combos (Windows, Linux, 32-bit & 64-bit x86), but that can be for the future. Some existing open source efforts have farms we might be able to share. Useful if coverage needs to extend to combos not commonly available as virtual server services, eg Solaris.

If we're going down this route it'd be nice to add in package builds as well, especially RPMs and DEBs, and host these in simple repositories (going the full hog, one can then test deployment too using CI into a conditioned virtual environment that's built each time). Still, there's a lot to do just getting something simple up and running as a first pass.

Personally, I don't really place a high value on most code metrics, but others do. I've always felt a good developer is much more the sculptor who can feel the imperfections, than the scientist who measures every angle with lasers...

Raph

Raphael Cohn
Chief Architect, StormMQ
Secretary, OASIS AMQP Standard
raphael.cohn@...
StormMQ Limited

UK Office:
Gateshead int'l Business Centre, Mulgrave Terrace, Gateshead, NE8 1AN, United Kingdom
Telephone: +44 845 3712 567

Registered office:
16 Anchor Street, Chelmsford, Essex, CM2 0JY, United Kingdom
StormMQ Limited is Registered in England and Wales under Company Number 07175657
StormMQ.com



On 18 July 2012 02:10, mschonberg <mschonberg@...> wrote:
Mike Ritchie from J.P. Morgan was kind enough to draft this very thorough
proposal and roadmap to establish continuous integration (CI) for OpenMAMA. The
proposal addresses many of the challenges around testing applications
written in many programming languages and specifically the limited tools
available for C/C++.

The document also breaks adoption of CI into multiple stages:
    1. Provision a server with Jenkins to automate build and existing tests.
    2. Add code coverage for Java and C/C++
    3. Memory safety (using Valgrind) for C/C++
    4. Static code analysis
    5. Use Robot Framework for new regression tests and ATDD (Acceptance Test
       Driven Development).
    6. Use CI to generate current documentation
    7. Create a summary dashboard
    8. Use Coverity or a similar tool to manage code structure

If there are others on this mailing list experienced with CI, any suggestions
and feedback would be very useful.

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



MamdaSubscription question - no updates for MAMA_MSG_TYPE_UPDATE

Russell Aidan (Ext. - UniCredit Business Integrated Solutions) <aidan.russell.extern@...>
 

Hi,
 
I wonder if anyone has come across this MAMDA publisher/listener behaviour ?
 
I wrote a simple test MAMDA listener and publisher. In the listener I create a simple MamdaSubscription, using defaults for subscription-type and service (NORMAL & REAL_TIME).
 
In my test publisher I send an update message for the subscribed symbol from a timer. However the client listener receives only messages with msgType MAMA_MSG_TYPE_INITIAL; messages with msgType MAMA_MSG_TYPE_UPDATE do not invoke the onMsg callback. I set the msgType in the send message using fid 1.
 
regards,
 
Aidan Russell
Quoting Systems Development
Unicredit
 
0049 89 378 12843
 
 
 


Re: MamdaSubscription question - no updates for MAMA_MSG_TYPE_UPDATE

Mark O'Callaghan
 

Russell,

Take a look at mamda/c_cpp/src/examples/mamdapublisher.cpp
(specifically MamdaPublisher::addMamaHeaderFields).

I think your issue is that you need to add more header fields, afaik
at a minimum you need the message type and the message status
(although it could be more).

Mark

On 18 July 2012 17:51, Russell Aidan (Ext. - UniCredit Business
Integrated Solutions) <aidan.russell.extern@unicreditgroup.de> wrote:
Hi,

I wonder if anyone has come across this MAMDA publisher/listener behaviour ?

I wrote a simple test MAMDA listener and publisher. In the listener I create
a simple MamdaSubscription, using defaults for subscription-type and service
(NORMAL & REAL_TIME).

In my test publisher I send an update message for the subscribed symbol from
a timer. However the client listener receives only messages with msgType
MAMA_MSG_TYPE_INITIAL; messages with msgType MAMA_MSG_TYPE_UPDATE do not
invoke the onMsg callback. I set the msgType in the send message using fid
1.

regards,

Aidan Russell
Quoting Systems Development
Unicredit

0049 89 378 12843




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


Re: MamdaSubscription question - no updates for MAMA_MSG_TYPE_UPDATE

Russell Aidan (Ext. - UniCredit Business Integrated Solutions) <aidan.russell.extern@...>
 

Hi Mark,

Thanks for the response. My programs are actually the mamdapublisher and mamdalistener from the examples. I found I had to make some small changes to get these working.

So I use the addMamaHeaderFields method (unchanged) in the publisher - however I found changing the msgType in the addMamaHeaderFields to INITIAL causes the client MamdaMsgListener::onMsg callback to be invoked for each message, but UPDATE msgType do not invoke the client callback.

//addMamaHeaderFields (mPublishMsg, MAMA_MSG_TYPE_QUOTE, MAMA_MD_MSG_TYPE_QUOTE, MAMA_MSG_STATUS_OK); // fails !!!
//addMamaHeaderFields( mPublishMsg, MAMA_MSG_TYPE_UPDATE, MAMA_MD_MSG_TYPE_GENERAL, MAMA_MSG_STATUS_OK ); // fails !!!
addMamaHeaderFields( mPublishMsg, MAMA_MSG_TYPE_INITIAL, MAMA_MD_MSG_TYPE_GENERAL, MAMA_MSG_STATUS_OK ); // works !!!

The only difference in the msg content sent is the msgType above.

regards,
Aidan

-----Original Message-----
From: Mark O'Callaghan [mailto:mjocalla@gmail.com]
Sent: Wednesday, July 18, 2012 10:44 PM
To: Russell Aidan (Ext. - UniCredit Business Integrated Solutions)
Cc: openmama-dev@lists.openmama.org
Subject: Re: [Openmama-dev] MamdaSubscription question - no updates for MAMA_MSG_TYPE_UPDATE

Russell,

Take a look at mamda/c_cpp/src/examples/mamdapublisher.cpp
(specifically MamdaPublisher::addMamaHeaderFields).

I think your issue is that you need to add more header fields, afaik at a minimum you need the message type and the message status (although it could be more).

Mark

On 18 July 2012 17:51, Russell Aidan (Ext. - UniCredit Business Integrated Solutions) <aidan.russell.extern@unicreditgroup.de> wrote:
Hi,

I wonder if anyone has come across this MAMDA publisher/listener behaviour ?

I wrote a simple test MAMDA listener and publisher. In the listener I
create a simple MamdaSubscription, using defaults for
subscription-type and service (NORMAL & REAL_TIME).

In my test publisher I send an update message for the subscribed
symbol from a timer. However the client listener receives only
messages with msgType MAMA_MSG_TYPE_INITIAL; messages with msgType
MAMA_MSG_TYPE_UPDATE do not invoke the onMsg callback. I set the
msgType in the send message using fid 1.

regards,

Aidan Russell
Quoting Systems Development
Unicredit

0049 89 378 12843




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


Adding new bridges

Tom Doust
 

I just want to throw some thoughts into the air here about simplifying the process of adding new bridges.

 

As things stand, with OM 2.1.1.2,  if I want to run a new middleware bridge I have to add a value to the enum mamaMiddleware

in middleware.h and a case to the switch statement in middleware.c, effectively forcing a new release of OM if anyone else wants to work with the new bridge

 

Further, I’m constrained to the name of my shared lib though the code in mama_loadBridgeWithPathInternal and the stuff in platform.c - openSharedLib

that builds the library name. From a development perspective this makes is difficult to run multiple variants.

 

I don’t see any problem with moving the work that is done by the enum/switch on the middleware name to an external config and also passing the library name as an optional parameter somewhere, again, possibly read from external config.

 

There may be some good reasons for things being the way they are, so I’m interested in any feedback, comments etc, before we (Tick42) consider contributing some enhancements in this area.

 

 

 

TOM DOUST | Head of Consultancy                                                                                                         


TICK42

P: +44 (0) 1628 477444 | M: +44 (0) 7710 479924 | E: tom.doust@... | http://www.tick42.com  


 

 


Re: Adding new bridges

mschonberg <mschonberg@...>
 

On Wed, 25 Jul 2012, Tom Doust wrote:


I just want to throw some thoughts into the air here about simplifying the
process of adding new bridges.

 

As things stand, with OM 2.1.1.2,  if I want to run a new middleware bridge
I have to add a value to the enum mamaMiddleware

in middleware.h and a case to the switch statement in middleware.c,
effectively forcing a new release of OM if anyone else wants to work with
the new bridge
I agree that this becomes much more cumbersome as we begin to support bridges
from multiple organizations. Requiring new software just to load a new bridge
that is otherwise compatible with your existing version will be frustrating for
many people.

A better solution is for bridges to be self-identifying with required methods
like "getBridgeName", "getBridgeVersion" and maybe "getMinSupportedMamaVersion".


 

Further, I’m constrained to the name of my shared lib though the code in
mama_loadBridgeWithPathInternal and the stuff in platform.c - openSharedLib

that builds the library name. From a development perspective this makes is
difficult to run multiple variants.
If we remove the enums, you can always incorporate a version into the middleware
name like (tick42_dev, tick42_1_0, etc.), and load different versions of the
same bridge.

 

I don’t see any problem with moving the work that is done by the enum/switch
on the middleware name to an external config and also passing the library
name as an optional parameter somewhere, again, possibly read from external
config.

 

There may be some good reasons for things being the way they are, so I’m
interested in any feedback, comments etc, before we (Tick42) consider
contributing some enhancements in this area.

One approach is to get rid of enums and make the bridges self-identifying. The
middleware name simply maps to the library name as it does now, but the new
bridge methods discussed above identify the bridge internally.

We should definitely discuss any proposals in detail before implementing them as
this impacts a lot of bridge developers. Also, we should try very hard to ensure
that existing bridges still load as well.

Regards,
-Mike

 

 

 

TOM DOUST | Head ofConsultancy                                                               
Description: tick42_footer

____________________________________________________________________________

TICK42

P: +44 (0) 1628 477444 | M: +44 (0) 7710 479924 | E: tom.doust@Tick42.com |
http://www.tick42.com  Description: cid:78978EB3-0AAD-4F5A-AD70-E3FE7BA558A5
Description: cid:298E41C4-FA7A-4004-ACAC-439C8094EA5A

____________________________________________________________________________

 

 



Re: Issues with make clean

Mark Spielman
 

Mike,

 

I’ve finally had a chance to return to this issue. Yes, my java build appears to be succeeding.

 

ls openmama-install/lib/libmamajni.*

libmamajni.a         libmamajni.la        libmamajni.so        libmamajni.so.0      libmamajni.so.0.0.0 

 

Anyone else seeing this issue?

 

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.


OpenMAMA 2.1 - Building in windows

Mark Spielman
 

I’m trying to build an unmodified clone of the latest git repository in windows. I’m using VS 2010. After resolving dependencies on avis and gtest, I’m still getting errors in the build. They have the signature of:

 

“Error    229         error FTK1011: could not create the new file tracking log file: K:\mspielman\gitdir\openmama_wintest\mama\c_cpp\src\examples\c\Debug\CL.read.1.tlog. The file exists.                K:\mspielman\gitdir\openmama_wintest\mama\c_cpp\src\examples\c\FileTracker      mamasubscriberc”

 

Or

 

“Error    235         error MSB6003: The specified task executable "CL.exe" could not be run. The process cannot access the file 'K:\mspielman\gitdir\openmama_wintest\mama\c_cpp\src\examples\c\Debug\cl.read.1.tlog' because it is being used by another process.              C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Platforms\Win32\Microsoft.Cpp.Win32.Targets        153         6                mamamultisubscriberc”

 

I have tried clean buids but nothing resolves these errors. Wondering if there is some newbie mistake I’m making.

 

Thanks

Mark

 

 

Mark Spielman

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

mark.spielman@...

www.solacesystems.com

 

 


Re: OpenMAMA 2.1 - Building in windows

Mike Schonberg <mschonberg@...>
 

Mark,

 

Are you building from a visual studio command prompt?

 

Regards,

-Mike

 

From: openmama-dev-bounces@... [mailto:openmama-dev-bounces@...] On Behalf Of Mark Spielman
Sent: Monday, July 30, 2012 9:41 AM
To: openmama-dev@...
Subject: [Openmama-dev] OpenMAMA 2.1 - Building in windows

 

I’m trying to build an unmodified clone of the latest git repository in windows. I’m using VS 2010. After resolving dependencies on avis and gtest, I’m still getting errors in the build. They have the signature of:

 

“Error    229         error FTK1011: could not create the new file tracking log file: K:\mspielman\gitdir\openmama_wintest\mama\c_cpp\src\examples\c\Debug\CL.read.1.tlog. The file exists.                K:\mspielman\gitdir\openmama_wintest\mama\c_cpp\src\examples\c\FileTracker      mamasubscriberc”

 

Or

 

“Error    235         error MSB6003: The specified task executable "CL.exe" could not be run. The process cannot access the file 'K:\mspielman\gitdir\openmama_wintest\mama\c_cpp\src\examples\c\Debug\cl.read.1.tlog' because it is being used by another process.              C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Platforms\Win32\Microsoft.Cpp.Win32.Targets        153         6                mamamultisubscriberc”

 

I have tried clean buids but nothing resolves these errors. Wondering if there is some newbie mistake I’m making.

 

Thanks

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: OpenMAMA 2.1 - Building in windows

Mark Spielman
 

No from within the IDE.

 

From: Mike Schonberg [mailto:mschonberg@...]
Sent: Monday, July 30, 2012 12:45 PM
To: Mark Spielman; openmama-dev@...
Subject: RE: OpenMAMA 2.1 - Building in windows

 

Mark,

 

Are you building from a visual studio command prompt?

 

Regards,

-Mike

 

From: openmama-dev-bounces@... [mailto:openmama-dev-bounces@...] On Behalf Of Mark Spielman
Sent: Monday, July 30, 2012 9:41 AM
To: openmama-dev@...
Subject: [Openmama-dev] OpenMAMA 2.1 - Building in windows

 

I’m trying to build an unmodified clone of the latest git repository in windows. I’m using VS 2010. After resolving dependencies on avis and gtest, I’m still getting errors in the build. They have the signature of:

 

“Error    229         error FTK1011: could not create the new file tracking log file: K:\mspielman\gitdir\openmama_wintest\mama\c_cpp\src\examples\c\Debug\CL.read.1.tlog. The file exists.                K:\mspielman\gitdir\openmama_wintest\mama\c_cpp\src\examples\c\FileTracker      mamasubscriberc”

 

Or

 

“Error    235         error MSB6003: The specified task executable "CL.exe" could not be run. The process cannot access the file 'K:\mspielman\gitdir\openmama_wintest\mama\c_cpp\src\examples\c\Debug\cl.read.1.tlog' because it is being used by another process.              C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Platforms\Win32\Microsoft.Cpp.Win32.Targets        153         6                mamamultisubscriberc”

 

I have tried clean buids but nothing resolves these errors. Wondering if there is some newbie mistake I’m making.

 

Thanks

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: OpenMAMA 2.1 - Building in windows

Slavomir Kundrik
 

Mark,

 

see my previous post in here

 

http://lists.openmama.org/pipermail/openmama-users/2012-July/000036.html

 

I had the same issue.

 

Regards,

 

Slavo

 

From: openmama-dev-bounces@... [mailto:openmama-dev-bounces@...] On Behalf Of Mark Spielman
Sent: 30 July 2012 17:45
To: Mike Schonberg; openmama-dev@...
Subject: Re: [Openmama-dev] OpenMAMA 2.1 - Building in windows

 

No from within the IDE.

 

From: Mike Schonberg [mailto:mschonberg@...]
Sent: Monday, July 30, 2012 12:45 PM
To: Mark Spielman; openmama-dev@...
Subject: RE: OpenMAMA 2.1 - Building in windows

 

Mark,

 

Are you building from a visual studio command prompt?

 

Regards,

-Mike

 

From: openmama-dev-bounces@... [mailto:openmama-dev-bounces@...] On Behalf Of Mark Spielman
Sent: Monday, July 30, 2012 9:41 AM
To: openmama-dev@...
Subject: [Openmama-dev] OpenMAMA 2.1 - Building in windows

 

I’m trying to build an unmodified clone of the latest git repository in windows. I’m using VS 2010. After resolving dependencies on avis and gtest, I’m still getting errors in the build. They have the signature of:

 

“Error    229         error FTK1011: could not create the new file tracking log file: K:\mspielman\gitdir\openmama_wintest\mama\c_cpp\src\examples\c\Debug\CL.read.1.tlog. The file exists.                K:\mspielman\gitdir\openmama_wintest\mama\c_cpp\src\examples\c\FileTracker      mamasubscriberc”

 

Or

 

“Error    235         error MSB6003: The specified task executable "CL.exe" could not be run. The process cannot access the file 'K:\mspielman\gitdir\openmama_wintest\mama\c_cpp\src\examples\c\Debug\cl.read.1.tlog' because it is being used by another process.              C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Platforms\Win32\Microsoft.Cpp.Win32.Targets        153         6                mamamultisubscriberc”

 

I have tried clean buids but nothing resolves these errors. Wondering if there is some newbie mistake I’m making.

 

Thanks

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.



This e-mail (including any attachments) is confidential, may contain
proprietary or privileged information and is intended for the named
recipient(s) only. Unintended recipients are prohibited from taking action
on the basis of information in this e-mail and must delete all copies.
Nomura will not accept responsibility or liability for the accuracy or
completeness of, or the presence of any virus or disabling code in, this
e-mail. If verification is sought please request a hard copy. Any reference
to the terms of executed transactions should be treated as preliminary only
and subject to formal written confirmation by Nomura. Nomura reserves the
right to monitor e-mail communications through its networks (in accordance
with applicable laws). No confidentiality or privilege is waived or lost by
Nomura by any mistransmission of this e-mail. Any reference to "Nomura" is
a reference to any entity in the Nomura Holdings, Inc. group. Please read
our Electronic Communications Legal Notice which forms part of this e-mail:
http://www.Nomura.com/email_disclaimer.htm


Re: OpenMAMA 2.1 - Building in windows

Mark Spielman
 

Thanks Slavo. That indeed helped me resolve the issue.

 

From: openmama-dev-bounces@... [mailto:openmama-dev-bounces@...] On Behalf Of slavomir.kundrik@...
Sent: Monday, July 30, 2012 3:43 PM
To: openmama-dev@...
Subject: Re: [Openmama-dev] OpenMAMA 2.1 - Building in windows

 

Mark,

 

see my previous post in here

 

http://lists.openmama.org/pipermail/openmama-users/2012-July/000036.html

 

I had the same issue.

 

Regards,

 

Slavo

 

From: openmama-dev-bounces@... [mailto:openmama-dev-bounces@...] On Behalf Of Mark Spielman
Sent: 30 July 2012 17:45
To: Mike Schonberg; openmama-dev@...
Subject: Re: [Openmama-dev] OpenMAMA 2.1 - Building in windows

 

No from within the IDE.

 

From: Mike Schonberg [mailto:mschonberg@...]
Sent: Monday, July 30, 2012 12:45 PM
To: Mark Spielman; openmama-dev@...
Subject: RE: OpenMAMA 2.1 - Building in windows

 

Mark,

 

Are you building from a visual studio command prompt?

 

Regards,

-Mike

 

From: openmama-dev-bounces@... [mailto:openmama-dev-bounces@...] On Behalf Of Mark Spielman
Sent: Monday, July 30, 2012 9:41 AM
To: openmama-dev@...
Subject: [Openmama-dev] OpenMAMA 2.1 - Building in windows

 

I’m trying to build an unmodified clone of the latest git repository in windows. I’m using VS 2010. After resolving dependencies on avis and gtest, I’m still getting errors in the build. They have the signature of:

 

“Error    229         error FTK1011: could not create the new file tracking log file: K:\mspielman\gitdir\openmama_wintest\mama\c_cpp\src\examples\c\Debug\CL.read.1.tlog. The file exists.                K:\mspielman\gitdir\openmama_wintest\mama\c_cpp\src\examples\c\FileTracker      mamasubscriberc”

 

Or

 

“Error    235         error MSB6003: The specified task executable "CL.exe" could not be run. The process cannot access the file 'K:\mspielman\gitdir\openmama_wintest\mama\c_cpp\src\examples\c\Debug\cl.read.1.tlog' because it is being used by another process.              C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Platforms\Win32\Microsoft.Cpp.Win32.Targets        153         6                mamamultisubscriberc”

 

I have tried clean buids but nothing resolves these errors. Wondering if there is some newbie mistake I’m making.

 

Thanks

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.

 

This e-mail (including any attachments) is confidential, may contain

proprietary or privileged information and is intended for the named

recipient(s) only. Unintended recipients are prohibited from taking action

on the basis of information in this e-mail and must delete all copies.

Nomura will not accept responsibility or liability for the accuracy or

completeness of, or the presence of any virus or disabling code in, this

e-mail. If verification is sought please request a hard copy. Any reference

to the terms of executed transactions should be treated as preliminary only

and subject to formal written confirmation by Nomura. Nomura reserves the

right to monitor e-mail communications through its networks (in accordance

with applicable laws). No confidentiality or privilege is waived or lost by

Nomura by any mistransmission of this e-mail. Any reference to "Nomura" is

a reference to any entity in the Nomura Holdings, Inc. group. Please read

our Electronic Communications Legal Notice which forms part of this e-mail:


{Patch 1.1 1/1] mamac: add new middleware enumerator

Tom Doust
 

This patch adds a new middleware type "tick42blp" to the current set of middleware names enumerated in middleware.c

This has no impact other than to allow the tick42 blp middleware bridge to load and run.

Signed-off-by: Tom Doust <tom.doust@tick42.com>

---

diff --git a/mama/c_cpp/src/c/mama/middleware.h b/mama/c_cpp/src/c/mama/middleware.h
index 1ae80b7..acf5f9e 100644
--- a/mama/c_cpp/src/c/mama/middleware.h
+++ b/mama/c_cpp/src/c/mama/middleware.h
@@ -37,7 +37,8 @@ typedef enum mamaMiddleware_
MAMA_MIDDLEWARE_LBM = 1,
MAMA_MIDDLEWARE_TIBRV = 2,
MAMA_MIDDLEWARE_AVIS = 3,
- MAMA_MIDDLEWARE_MAX = 4,
+ MAMA_MIDDLEWARE_TICK42BLP = 4,
+ MAMA_MIDDLEWARE_MAX = 5,
MAMA_MIDDLEWARE_UNKNOWN = 99
} mamaMiddleware;

diff --git a/mama/c_cpp/src/c/middleware.c b/mama/c_cpp/src/c/middleware.c
index 2353309..c2b5db0 100644
--- a/mama/c_cpp/src/c/middleware.c
+++ b/mama/c_cpp/src/c/middleware.c
@@ -38,8 +38,12 @@ mamaMiddleware_convertFromString (const char* str)
if (strcasecmp (str, "tibrv") == 0)
return MAMA_MIDDLEWARE_TIBRV;

- if (strcasecmp (str, "avis") == 0)
- return MAMA_MIDDLEWARE_AVIS;
+ if (strcasecmp (str, "avis") == 0)
+ return MAMA_MIDDLEWARE_AVIS;
+
+ if (strcasecmp (str, "tick42blp") == 0)
+ return MAMA_MIDDLEWARE_TICK42BLP;
+


return MAMA_MIDDLEWARE_UNKNOWN;
@@ -57,8 +61,11 @@ mamaMiddleware_convertToString (mamaMiddleware middleware)
return "lbm";
case MAMA_MIDDLEWARE_TIBRV:
return "tibrv";
- case MAMA_MIDDLEWARE_AVIS:
- return "AVIS";
+ case MAMA_MIDDLEWARE_AVIS:
+ return "AVIS";
+ case MAMA_MIDDLEWARE_TICK42BLP:
+ return "tick42blp";
+
default:
return "unknown";
}


Making examples

William Henry <whenry@...>
 

Hi Mike,

Can you change the build so that if the bridge library changes the examples will get relinked?

William


Re: Making examples

Michael Schonberg
 

On Mon, 27 Aug 2012, William Henry wrote:

Hi Mike,
Can you change the build so that if the bridge library changes the examples will get relinked?
I will take a look and try to figure out why the dependencies are not correct for the examples.

Regards,
-Mike

William


{Patch 1.1 1/1] mamac: add new payload enumerator

Tom Doust
 

This patch adds a new payload type MAMA_PAYLOAD_TICK42BLP to the current set of payload types enumerated in msg.c

This has no impact other than to allow the tick42 blp middleware bridge to load and run.

Signed-off-by: Tom Doust <tom.doust@tick42.com>

---

diff --git a/mama/c_cpp/src/c/mama/msg.h b/mama/c_cpp/src/c/mama/msg.h
index 5094ac9..708f301 100644
--- a/mama/c_cpp/src/c/mama/msg.h
+++ b/mama/c_cpp/src/c/mama/msg.h
@@ -47,6 +47,7 @@ typedef enum mamaPayloadType_
MAMA_PAYLOAD_FAST = 'F',
MAMA_PAYLOAD_V5 = '5',
MAMA_PAYLOAD_AVIS = 'A',
+ MAMA_PAYLOAD_TICK42BLP = 'B',
MAMA_PAYLOAD_UNKNOWN = 'U'
} mamaPayloadType;

diff --git a/mama/c_cpp/src/c/msg.c b/mama/c_cpp/src/c/msg.c
index 1daf82f..895472f 100644
--- a/mama/c_cpp/src/c/msg.c
+++ b/mama/c_cpp/src/c/msg.c
@@ -371,6 +371,9 @@ mamaPayload_convertToString (mamaPayloadType payloadType)
return "V5";
case MAMA_PAYLOAD_AVIS:
return "AVIS";
+ case MAMA_PAYLOAD_TICK42BLP:
+ return "TICK42BLP";
+
default:
return "unknown";
}


AMQP/Qpid bridge status update

William Henry <whenry@...>
 

Just FYI. The first phase of a AMQP bridge for OpenMAMA using Qpid was completed yesterday.  Still plenty to do.

For more information you can see my blog post: 

I'll continue to provide updates.

Best regards,

William Henry

221 - 240 of 2305