Trouble migrating from boost 1.45 to 1.50

[GoogleCodeExporter]

Using quickfast_lnx_src_1_3.tar.gz I've found that I no longer get multicast 
data after upgrading from boost 1.45 to 1.50 on linux.  I don't see any 
compiler warnings/errors and everything starts up fine but no messages are 
received.  I've used 'strace' and the API calls look the same.  

I don't know if this is a quickfast issue yet but thought maybe someone has 
seen similar behavior.  I'm going to see if 
[http://code.google.com/p/quickfast/issues/detail?id=81 Issue 81] is related.  
I'll report back once I've figure it out.

Jason

Original issue reported on code.google.com by [email protected] on 6 Jul 2012 at 2:57

[GoogleCodeExporter]

Still no solution but more data:

I can reproduce my problem when I upgrade from boost 1.45 to 1.46.  I see a 
couple snapshot feed messages decoded and the corresponding 
startMessage/endMessage for each is called.  After this point startMessage is 
not called anymore and I haven't determined why yet.  It seems things get lost 
in the bowels of the decoding or related code.

Perhaps I'm not setting up the quickfast objects properly at start-up.  It's 
been awhile since I wrote this code (which works well in production for CME), 
but I notice that I'm using FIXED_HEADER instead of FAST_HEADER and I wonder if 
that could be causing trouble.  

Here's the code I find most suspect, maybe someone can point out a problem:

    m_decoderConfig->setTemplateFileName(m_templatesFile);
    m_decoderConfig->setReceiverType(DecoderConfiguration::MULTICAST_RECEIVER);
    m_decoderConfig->setMulticastGroupIP(m_multicastGroupIP);
    m_decoderConfig->setPortNumber(m_port);
    m_decoderConfig->setListenInterfaceIP(m_listenInterfaceIP);    
    m_decoderConfig->setHeaderType(DecoderConfiguration::FIXED_HEADER);
    const size_t fixFastHeaderSize = 5;
    m_decoderConfig->setMessageHeaderMessageSizeBytes(fixFastHeaderSize);
    m_decoderConfig->setMessageHeaderPrefixCount(0);
    m_decoderConfig->setMessageHeaderSuffixCount(0);
    //m_decoderConfig->setAssemblerType(DecoderConfiguration::MESSAGE_PER_PACKET_ASSEMBLER);

    m_decoderConn.reset(new DecoderConnection());
    m_decoderConn->configure(*m_messageBuilder, *m_decoderConfig);
    m_decoderConn->assembler().setReset(true);
    // The connection is configured but it's not activated until threads service the receiver

Jason

Original comment by [email protected] on 9 Jul 2012 at 10:31

[GoogleCodeExporter]

This is a task I've been working on as a low priority.  I think I've got it to 
work on 1 machine without trouble.  I don't know the cause but something 
environmental seems to be the issue.

Original comment by [email protected] on 31 Jul 2012 at 3:07