I'm very new in quickfix.
I created a client that connects normally with server. On my fromApp() function I can print the message with a simple std::cout << message << std::endl; and all fields of the message are there, also they are there on log files. When I try to call crack() it throws Field not found exception. Looking at log files I saw that the exception is thrown because quickfix can't find field 35. Anyone knows something about this?
EDIT1:
void fromApp( const FIX::Message& message,
const FIX::SessionID& sessionID )
throw( FIX::FieldNotFound, FIX::IncorrectDataFormat, FIX::IncorrectTagValue, FIX::UnsupportedMessageType )
{
std::cout << "FromApp" << std::endl;
std::cout << message << std::endl;
try
{
crack( message, sessionID );
}
catch(std::exception& ex)
{
std::cout << "crack exception: " << ex.what() << std::endl;
}
}
void onMessage( const FIX44::MarketDataIncrementalRefresh& message, const FIX::SessionID& sessionID )
{
std::cout << "OnMessage" << std::endl;
}
On my terminal windows I get the following output:
FromApp
8=FIX.4.49=12335=W34=7249=servidor52=20150123-13:34:56.95756=cliente22=448=CERB001D55=CERB001D268=1269=0270=100271=1000290=110=239
crack exception: Field not found
On the the message.current.log I get:
20150123-13:29:03.618 : 8=FIX.4.49=7035=A34=149=cliente52=20150123-13:29:03.61856=servidor98=0108=2010=077
20150123-13:29:03.655 : 8=FIX.4.49=7035=A34=149=servidor52=20150123-13:29:03.65856=cliente98=0108=2010=081
20150123-13:29:06.629 : 8=FIX.4.49=12235=W34=249=servidor52=20150123-13:29:06.63556=cliente22=448=CERB001D55=CERB001D268=1269=0270=100271=1000290=110=175
EDIT2:
When I put the crack() function outside the try-catch block, in message.event.log I get:
20150123-15:49:11.204 : Message 2 Rejected: Conditionally Required Field Missing:35
20150123-15:49:16.221 : Message 3 Rejected: Conditionally Required Field Missing:35
Thank you in advance.
I finally found the source of the problem.
I had installed quickfix from source code and it seems that in newer versions of quickfix (1.14.0 and latest) something changed in DataDictionaryProvadider.h related with shared pointers and it seems that it was the cause of the problem. When I installed quickfix from apt-get, I got version 1.13.3 and everything worked fine.
Thanks to everybody who tried to help.
Related
I am learning from http://www.cochoy.fr/boost-property-tree/.
Instead of write_json to stdout, I tried to save it in a string.
std::stringstream ss;
boost::property_tree::json_parser::write_json(ss, oroot, false);
std::cout <<" begin json string" << std::endl;
std::cout << ss.str() << std::endl;
std::cout << "after json string" << std::endl;
output:
begin json string
{"height":"320","some":{"complex":{"path":"bonjour"}},"animals":{"rabbit":"white","dog":"brown","cat":"grey"},"fish":"blue","fish":"yellow","fruits":["apple","raspberry","orange"],"matrix":[["1","2","3"],["4","5","6"],["7","8","9"]]}
after json string
According to the output above, there is a new empty line at the end. How to get rid of the new line? Because with the new line it is not a valid JSON string.
The newline is not explicitly mentioned in the JSON RFC-7159 but it is defined as part of the POSIX standard for a line.
Incase you're interested in where the newline comes from you can take a look at the write_json_internal source code, we can see that there is an stream << std::endl; near the end of the method. Note that ...::write_json references write_json_internal.
// Write ptree to json stream
template<class Ptree>
void write_json_internal(std::basic_ostream<typename Ptree::key_type::value_type> &stream,
const Ptree &pt,
const std::string &filename,
bool pretty)
{
if (!verify_json(pt, 0))
BOOST_PROPERTY_TREE_THROW(json_parser_error("ptree contains data that cannot be represented in JSON format", filename, 0));
write_json_helper(stream, pt, 0, pretty);
stream << std::endl;
if (!stream.good())
BOOST_PROPERTY_TREE_THROW(json_parser_error("write error", filename, 0));
}
i got a strange probem with tesseract ocr. everything works fine, like the ocr part. characters are recognized correctly. but it crashes after it has done all calculations
this only happens when i run the code in a thread.
void server(boost::asio::io_service & io_service, unsigned short port)
{
tcp::acceptor a(io_service, tcp::endpoint(tcp::v4(), port));
for (;;)
{
a.accept(sock);
//boost::thread t(session, boost::ref(sock));
//t.detach();
std::thread(session, std::move(sock)).detach();
}
}
void session(tcp::socket & sock)
{
tesseract::TessBaseAPI api;
if (api.Init("", "eng"))
{
fprintf(stderr, "Could not initialize tesseract.\n");
exit(1);
}
for (int i = 0; i < 81; i++)
{
if (!sudokuDatainside[i].empty())
{
api.SetImage((uchar*)sudokuDatainside[i].data, sudokuDatainside[i].size().width, sudokuDatainside[i].size().height, sudokuDatainside[i].channels(), sudokuDatainside[i].step1());
// Get OCR result
outText = api.GetUTF8Text();
std::cout << outText << std::endl;
}
else
{
std::cout << "Nothing - " << i << std::endl;
}
}
api.End();
}
Edit: seems its not a problem with api.End(). even if i dont call this method the programm crashes when the thread ends... does tesseract support threads?
After some hours of trying to find a solution. I came across an error during building the debug libs.
So rebuilding the tesseract debug libs solved the problem.
Here are the instructions i used:
https://github.com/charlesw/tesseract-vs2012
I am having trouble understanding how clang throws exceptions when I try to allocate an object that would exceed its limit. For instance if I compile and run the following bit of code:
#include <limits>
#include <new>
#include <iostream>
int main(int argc, char** argv) {
typedef unsigned char byte;
byte*gb;
try{
gb=new byte[std::numeric_limits<std::size_t>::max()];
}
catch(const std::bad_alloc&){
std::cout<<"Normal"<<std::endl;
return 0;}
delete[]gb;
std::cout<<"Abnormal"<<std::endl;
return 1;
}
then when I compile using "clang++ -O0 -std=c++11 main.cpp" the result I get is "Normal" as expected, but as soon as I enable optimizations 1 through 3, the program unexpectedly returns "Abnormal".
I am saying unexpectedly, because according to the C++11 standard 5.3.4.7:
When the value of the expression in a noptr-new-declarator is zero, the allocation function is called to
allocate an array with no elements. If the value of that expression is less than zero or such that the size
of the allocated object would exceed the implementation-defined limit, or if the new-initializer is a braced-
init-list for which the number of initializer-clauses exceeds the number of elements to initialize, no storage
is obtained and the new-expression terminates by throwing an exception of a type that would match a
handler (15.3) of type std::bad_array_new_length (18.6.2.2).
[This behavior is observed with both clang 3.5 using libstd++ on linux and clang 3.3 using libc++ on Mac. The same behavior is also observed when the -std=c++11 flag is removed.]
The plot thickens when I compile the same program using gcc 4.8, using the exact same command line options. In that case, the program returns "Normal" for any chosen optimization level.
I cannot find any undefined behavior in the code posted above that would explain why clang would feel free not to throw an exception when code optimizations are enabled. As far as the bug database is concerned, the closest I can find is http://llvm.org/bugs/show_bug.cgi?id=11644 but it seems to be related to the type of exception being thrown rather than a behavior difference between debug and release code.
So it this a bug from Clang? Or am I missing something? Thanks,
It appears that clang eliminates the allocation as the array is unused:
#include <limits>
#include <new>
#include <iostream>
int main(int argc, char** argv)
{
typedef unsigned char byte;
bytes* gb;
const size_t max = std::numeric_limits<std::size_t>::max();
try
{
gb = new bytes[max];
}
catch(const std::bad_alloc&)
{
std::cout << "Normal" << std::endl;
return 0;
}
try
{
gb[0] = 1;
gb[max - 1] = 1;
std::cout << gb[0] << gb[max - 1] << "\n";
}
catch ( ... )
{
std::cout << "Exception on access\n";
}
delete [] gb;
std::cout << "Abnormal" << std::endl;
return 1;
}
This code prints "Normal" with -O0 and -O3, see this demo. That means that in this code, it is actually tried to allocate the memory and it indeed fails, hence we get the exception. Note that if we don't output, clang is still smart enough to even ignore the writes.
It appears that clang++ on Mac OSX does throw bad_alloc, but it also prints an error message from malloc.
Program:
// bad_alloc example
#include <iostream> // std::cout
#include <sstream>
#include <new> // std::bad_alloc
int main(int argc, char *argv[])
{
unsigned long long memSize = 10000;
if (argc < 2)
memSize = 10000;
else {
std::istringstream is(argv[1]); // C++ atoi
is >> memSize;
}
try
{
int* myarray= new int[memSize];
std::cout << "alloc of " << memSize << " succeeded" << std::endl;
}
catch (std::bad_alloc& ba)
{
std::cerr << "bad_alloc caught: " << ba.what() << '\n';
}
std::cerr << "Program exiting normally" << std::endl;
return 0;
}
Mac terminal output:
david#Godel:~/Dropbox/Projects/Miscellaneous$ badalloc
alloc of 10000 succeeded
Program exiting normally
david#Godel:~/Dropbox/Projects/Miscellaneous$ badalloc 1234567891234567890
badalloc(25154,0x7fff7622b310) malloc: *** mach_vm_map(size=4938271564938272768)
failed (error code=3)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
bad_alloc caught: std::bad_alloc
Program exiting normally
I also tried the same program using g++ on Windows 7:
C:\Users\David\Dropbox\Projects\Miscellaneous>g++ -o badallocw badalloc.cpp
C:\Users\David\Dropbox\Projects\Miscellaneous>badallocw
alloc of 10000 succeeded
C:\Users\David\Dropbox\Projects\Miscellaneous>badallocw 1234567890
bad_alloc caught: std::bad_alloc
Note: The program is a modified version of the example at
http://www.cplusplus.com/reference/new/bad_alloc/
In an XMLRPC server that I'm working on (based off xmlrpc-c) the threads may want to make a MySQL connection to retrieve some data, using the following function:
Distribution getEntitySetFromMysql( int id ) {
Distribution result;
try {
sql::Driver *driver = get_driver_instance();
sql::Connection *con = driver->connect( (std::string)DBHOST, (std::string)USER, (std::string)PASSWORD);
con->setSchema( (std::string)DATABASE );
sql::Statement *stmt = con->createStatement();
std::stringstream query;
query << "SELECT concept_id, weight FROM entity_set_lines WHERE entity_set_id = " << id;
sql::ResultSet *res = stmt->executeQuery ( query.str() );
while (res->next()) {
result[ res->getInt("concept_id") ] = res->getDouble("weight");
}
delete res;
delete stmt;
con->close();
delete con;
} catch (sql::SQLException &e) {
std::cout << "ERROR: SQLException in " << __FILE__;
std::cout << " (" << __func__<< ") on line " << __LINE__ << std::endl;
std::cout << "ERROR: " << e.what();
std::cout << " (MySQL error code: " << e.getErrorCode();
std::cout << ", SQLState: " << e.getSQLState() << ")" << std::endl;
if (e.getErrorCode() == 1047) {
std::cout << "\nYour server does not seem to support Prepared Statements at all. ";
std::cout << "Perhaps MYSQL < 4.1?" << std::endl;
}
} catch (std::runtime_error &e) {
std::cout << "ERROR: runtime_error in " << __FILE__;
std::cout << " (" << __func__ << ") on line " << __LINE__ << std::endl;
std::cout << "ERROR: " << e.what() << std::endl;
}
return result;
}
All works fine, but after a thread runs this code and successfully returns its result, the thread remains hanging and does not exit. What is wrong with this approach? How fundamentaly wrong is this? Is the MySQL connector thread safe?
While Googling around for a solutions, I came across mentions of sql::Driver::threadInit() and sql::Driver::threadEnd(). However, as I was on version 1.0.5 of the C++ Connector, these functions were not available to me. Adding a driver->threadInit(); after getting a driver instance and driver->threadEnd(); at the end of my function, this problem was resolved.
The following is the mention of this thread init and end functionality in MySQL's 1.1.0 change history:
Added Driver::threadInit() and Driver::threadEnd() methods. Every
thread of a threaded client must call Driver::threadInit() at the very
start of the thread before it does anything else with Connector/C++
and every thread must call Driver::threadEnd() when it finishes. You
can find an example demonstrating the use in examples/pthreads.cpp. It
is strongly discouraged to share connections between threads. It is
theoretically possible, if you set certain (undocumented) mutexes, but
it is not supported at all. Use one connection per thread. Do not have
two threads using the same connection at the same time. Please check
the C API notes on threading on the MySQL manual. Connector/C++ wraps
the C API. (Lawrin, Andrey, Ulf)
TL;DR: If you come across this problem, make sure that your version of the C++ MySQL Connector is >= 1.1.0 and use the sql::Driver::threadInit() and sql::Driver::threadEnd() methods to surround your connection code.
Two thoughts:
libmysql isn't fully thread safe.
the way your code is structured you will leak memory if an exception occurs. you might be better served by either declaring your variables outside the try/catch and using a finally (or local equivalent) to ensure proper cleanup or using smart pointers (if available).
Since you don't show any of the calling or surrounding code it's hard to tell what's actually going on. Do you check the exit code of the thread when it's supposedly done? Can you attach it in a debugger to see what it's doing instead of closing?
Actually :
DO NOT USE : sql::Driver::threadInit() nor sql::Driver::threadEnd()
BECAUSE : you are already using try()
YOU FORGOT :
res->close();
stmt->close();
con->close();
delete res;
delete stmt;
delete con;
EXAMPLE :
int connection_and_query_func()
{
/*connection and query variables*/
sql::Driver *driver;
sql::Connection *con;
sql::Statement *stmt;
sql::ResultSet *res;
int err_exception_getErrorCode=0;
/*results variables*/
int my_int_from_column_1 = 0;
double my_double_from_column_2 = 0;
....
std:string my_string_from_column_p = "";
try
{
/* Create a connection */
driver = get_driver_instance();
con = driver->connect("address_name", "user_name", "password");
/* Connect to the MySQL database */
con->setSchema("schema_name");
/* Execute MySQL Query*/
stmt = con->createStatement();
res = stmt->executeQuery("your query statement here");
/* Read MySQL Query results per column*/
my_int_from_column_1 = res->getInt(1);
my_double_from_column_2 = res->getDouble(2);
....
my_string_from_column_p = res->getString(p);
/* Close MySQL Connection*/
res->close();
stmt->close();
con->close();
delete res;
delete stmt;
delete con;
};
/* Get last error*/
catch (sql::SQLException &exception)
{
err_exception_getErrorCode = exception.getErrorCode();
};
return(0);
};
CONCLUSION : this can be executed as many times as you want. The function example (connection_and_query_func()) will close MySQL connection properly after it is done - without adding up processes to your MySQL server!!!
FURTHERMORE : read the official manual https://docs.oracle.com/cd/E17952_01/connector-cpp-en/connector-cpp-en.pdf
ALTERNATIVE : if you cannot close properly your connection and query from your program/function side (thus adding up processes to your MySQL server) consider the 2 following options:
1/ set all MySQL timeout parameters to 10 sec. or less (for instance);
2/ write a script that SHOW PROCESSLIST and delete processes that are in SLEEP for too long.
Cheers.
in my Qt (4.8.1) based application I need to retrieve the definition of a view stored in a MySql database.
The code I'm using is
QSqlQuery query;
query.prepare(QString("SHOW CREATE VIEW %1").arg(viewName));
qDebug() << "actually sending this query: " << query.lastQuery();
qDebug() << "exec retuned " << query.exec();
qDebug() << "last error reported as " << query.lastError();
qDebug() << "size = " << query.size();
qDebug() << "numRowsAffected" << query.numRowsAffected();
QString viewCreateString;
if (query.first()) {
viewCreateString = query.value(1).toString();
qDebug() << "got this create view record" << viewCreateString;
}
When I run the above code I get the following result:
actually sending this query: "SHOW CREATE VIEW AC_STATE_V"
exec retuned true
last error reported as QSqlError(-1, "", "")
size = -1
numRowsAffected -1
Note that:
if I run the very same (cut&paste) command from within a MySql Workbench SQLTab connected to the same DB using the same credentials I do get the expected results (i.e.view exists and user got sufficient rights to retrieve it)
all of the above is also valid for a TABLE