quickfix-developers — QuickFIX developers forum

Re: [Quickfix-developers] file descriptor/memory leak in ThreadedSocketInitiator

[Alex S. <al...@ya...>]

Oren,

I am using version 1.12.4

Alex

--- Oren Miller <or...@qu...> wrote:

> Alex, what version of QuickFIX are you using?
> 
> > Hi,
> >
> > We left our application running over the holidays
> > continuously trying to reconnect to a server and
> > failing. When we came back, the whole server
> seemed to
> > be broken. All applications were failing because
> they
> > could not allocate any file descriptors from the
> OS
> > (Windows Server 2003)
> 
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: [Quickfix-developers] file descriptor/memory leak in ThreadedSocketInitiator

[Oren M. <or...@qu...>]

Alex, what version of QuickFIX are you using?

> Hi,
>
> We left our application running over the holidays
> continuously trying to reconnect to a server and
> failing. When we came back, the whole server seemed to
> be broken. All applications were failing because they
> could not allocate any file descriptors from the OS
> (Windows Server 2003)

[Quickfix-developers] file descriptor/memory leak in ThreadedSocketInitiator

[Alex S. <al...@ya...>]

Hi,

We left our application running over the holidays
continuously trying to reconnect to a server and
failing. When we came back, the whole server seemed to
be broken. All applications were failing because they
could not allocate any file descriptors from the OS
(Windows Server 2003)

Windows has a limit on the number of open file
descriptors including open sockets.

It turned out that quickfix fails to clean up sockets
when connections fail. With 7 connections failing
every 30 seconds, the limit was reached over a few
days.

The open sockets also use up memory.

The problem is in here: 

bool ThreadedSocketInitiator::doConnect( const
SessionID& s, const Dictionary& d )
{ QF_STACK_PUSH(ThreadedSocketInitiator::doConnect)
  try
  {
    Session* session = Session::lookupSession( s );

    if( !session->isSessionTime() ) return false;
 
    std::string address;

    short port = 0;

    getHost( s, d, address, port );
 
    Log* log = session->getLog();
    log->onEvent( "Connecting to " + address + " on
port " + IntConvertor::convert((unsigned short)port)
);
    int socket = socket_createConnector();
 
    if( socket_connect(socket, address.c_str(), port)
< 0 )

    {

      log->onEvent( "Connection failed" );

//!!!! Socket never closed because it is closed in
ThreadedSocketConnection::disconnect

      return false;

    }

    log->onEvent( "Connection succeeded" );

    ThreadedSocketConnection* pConnection =

      new ThreadedSocketConnection( s, socket,
getApplication(), *this );

    ThreadPair* pair = new ThreadPair( this,
pConnection );
 
    {
      Locker l( m_mutex );
      unsigned thread;
      if ( !thread_spawn( &socketThread, pair, thread
) )
        delete pair;
      addThread( socket, thread );
    }
    return true;
  }
  catch ( std::exception& ) { return false; } 
  QF_STACK_POP
}

Alex

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: [Quickfix-developers] file descriptor/memory leak in ThreadedSocketInitiator

[Alex S. <al...@ya...>]

Hi, 

In addition to cleaning up the sockets when connection
fails, my application would also benefit from
receiving a callback when it happens as well.

That way, the app can keep track of failed attempts
and force itself to shutdown after a number of
attempts is reached. 

Not being able to establish a connection is different
from not being able to logon. I think that currently
when connections fail there is no indication of what
is going on apart from knowing that you haven't
connected yet. Is that true? When a logon fails,
onLogout is called.

Have you guys thought about adding an app callback
like 'onConnectionFailed' or something like that?

Thanks,

Alex

--- Alex Shterenberg <al...@ya...> wrote:

> Hi,
> 
>  
> 
> We left our application running over the holidays
> continuously trying to reconnect to a server and
> failing. When we came back, the whole server seemed
> to
> be broken. All applications were failing because
> they
> could not allocate any file descriptors from the OS
> (Windows Server 2003)
> 
>  
> 
> Windows has a limit on the number of open file
> descriptors including open sockets.
> 
>  
> 
> It turned out that quickfix fails to clean up
> sockets
> when connections fail. With 7 connections failing
> every 30 seconds, the limit was reached over a few
> days.
> 
> The open sockets also use up memory.
> 
>  
> 
> The problem is in here: 
> 
>  
> 
> bool ThreadedSocketInitiator::doConnect( const
> SessionID& s, const Dictionary& d )
> 
> { QF_STACK_PUSH(ThreadedSocketInitiator::doConnect)
> 
>  
> 
>   try
> 
>   {
> 
>     Session* session = Session::lookupSession( s );
> 
>     if( !session->isSessionTime() ) return false;
> 
>  
> 
>     std::string address;
> 
>     short port = 0;
> 
>     getHost( s, d, address, port );
> 
>  
> 
>     Log* log = session->getLog();
> 
>     log->onEvent( "Connecting to " + address + " on
> port " + IntConvertor::convert((unsigned short)port)
> );
> 
>     int socket = socket_createConnector();
> 
>  
> 
>     if( socket_connect(socket, address.c_str(),
> port)
> < 0 )
> 
>     {
> 
>       log->onEvent( "Connection failed" );
> 
> //!!!! Socket never closed because it is closed in
> ThreadedSocketConnection::disconnect
> 
>       return false;
> 
>     }
> 
>  
> 
>     log->onEvent( "Connection succeeded" );
> 
>  
> 
>     ThreadedSocketConnection* pConnection =
> 
>       new ThreadedSocketConnection( s, socket,
> getApplication(), *this );
> 
>  
> 
>     ThreadPair* pair = new ThreadPair( this,
> pConnection );
> 
>  
> 
>     {
> 
>       Locker l( m_mutex );
> 
>       unsigned thread;
> 
>       if ( !thread_spawn( &socketThread, pair,
> thread
> ) )
> 
>         delete pair;
> 
>       addThread( socket, thread );
> 
>     }
> 
>     return true;
> 
>   }
> 
>   catch ( std::exception& ) { return false; }
> 
>  
> 
>   QF_STACK_POP
> 
> }
> 
>  
> 
> Alex
> 
>  
> 
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam
> protection around 
> http://mail.yahoo.com 
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

[Quickfix-developers] Subscribe/Publish logic

[mjc2k <MJC...@ms...>]

I just started looking at QuickFix so I am trying to understand what's needed
by the developer


Does quickfix handle Subscribe/Publish logic or is this required by the
developer. 

Example:

Client 1 makes a request for Orders on account 10000 (Subscription). The
Server will then post updates back to the client anytime something changes
with out the client polling (Publish). Client then makes a Snapshot request
to backfill any missing orders. Client is now in sync. 

Client 2 makes a request for a Orders on account 10000. (Subscription). The
Server will then post updates back to the client anytime something changes.
(Publish). Client then makes a Snapshot request to backfill any missing
orders. Client is now in sync. 

Server: Server stores subscriptions for each client.  Now when an updated
Order is detected, it will post this to all subscribers. I'm trying to
understand where the logic is handled by the server. Any source code
examples would be greatly appreciated.

I want to be able to pubish realtime prices from our Feed to the clients
that subscribe. Not sure if I need my own message types or if one is already
supplied.

Thanks
Matt
MJCarlucci at msn.com

-- 
View this message in context: http://www.nabble.com/Subscribe-Publish-logic-tf2928739.html#a8188127
Sent from the QuickFIX - Dev mailing list archive at Nabble.com.

[Quickfix-developers] file descriptor/memory leak in ThreadedSocketInitiator

[Alex S. <al...@ya...>]

Hi,

 

We left our application running over the holidays
continuously trying to reconnect to a server and
failing. When we came back, the whole server seemed to
be broken. All applications were failing because they
could not allocate any file descriptors from the OS
(Windows Server 2003)

 

Windows has a limit on the number of open file
descriptors including open sockets.

 

It turned out that quickfix fails to clean up sockets
when connections fail. With 7 connections failing
every 30 seconds, the limit was reached over a few
days.

The open sockets also use up memory.

 

The problem is in here: 

 

bool ThreadedSocketInitiator::doConnect( const
SessionID& s, const Dictionary& d )

{ QF_STACK_PUSH(ThreadedSocketInitiator::doConnect)

 

  try

  {

    Session* session = Session::lookupSession( s );

    if( !session->isSessionTime() ) return false;

 

    std::string address;

    short port = 0;

    getHost( s, d, address, port );

 

    Log* log = session->getLog();

    log->onEvent( "Connecting to " + address + " on
port " + IntConvertor::convert((unsigned short)port)
);

    int socket = socket_createConnector();

 

    if( socket_connect(socket, address.c_str(), port)
< 0 )

    {

      log->onEvent( "Connection failed" );

//!!!! Socket never closed because it is closed in
ThreadedSocketConnection::disconnect

      return false;

    }

 

    log->onEvent( "Connection succeeded" );

 

    ThreadedSocketConnection* pConnection =

      new ThreadedSocketConnection( s, socket,
getApplication(), *this );

 

    ThreadPair* pair = new ThreadPair( this,
pConnection );

 

    {

      Locker l( m_mutex );

      unsigned thread;

      if ( !thread_spawn( &socketThread, pair, thread
) )

        delete pair;

      addThread( socket, thread );

    }

    return true;

  }

  catch ( std::exception& ) { return false; }

 

  QF_STACK_POP

}

 

Alex

 



__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: [Quickfix-developers] Semi OT : QF internal data hotbackup

[John G. <joh...@wa...>]

Hi,

Thanks for all answers, private and on list.

> Rather than complicating the FileStore, wouldn't a better solution be
> to use one of the more "transactional" message stores, like the
> MySQLStore, or the OdbcStore backed by <pick your database>?

I have done all I could the last 2 years to keep this binary out of
database need. It is a simple fix-to-proprietary-protocole translator and
we can't ask all our clients to have yet-another-database-server to
install, monitor, upgrade, patch, and... replicate: we just moved the
problem of losing data in case of crash to another more complex layer of
data storing.

> Looking at 1.12.4, it seems like the BerkeleyDB-backed MessageStore I
> contributed has disappeared.  How come?  Wasn't this included with at
> least one release of QuickFIX?

There you got my attention, even if the replication issue has just 
moved from "how to safely hotbackup QF internal data ?" to "how to 
safely hotbackup a Berkeley DB ?" :-))

Sincerely,
JG

[Quickfix-developers] logon and ResetSeqNumFlag

[Alexey Z. <ale...@gm...>]

Hello,

I try to pass a certification where the server requests to send 
ResetSeqNumFlag=Y, but doesn't send it back.
As a result my initiator sends the second logon (as a response).
I found several postings regarding a similar issue but still don't 
understand if it's possible to solve it without QF code modifications:

http://sourceforge.net/mailarchive/message.php?msg_id=12360975

I'm using the last version from SVN: 1.12.4-1869.
I put the flag in the toAdmin().

Here are the logs:

8=FIX.4.2.9=77.35=A.34=1.49=******.52=20070104-20:59:34.290.56=******.98=0.108=30.141=Y.10=112.
8=FIX.4.2.9=67.35=A.49=******.56=******.34=1.52=20070104-20:59:34.98=0.108=30.10=121.
8=FIX.4.2.9=71.35=A.34=2.49=******.52=20070104-20:59:34.337.56=******.98=0.108=30.10=064.
8=FIX.4.2.9=67.35=A.49=******.56=******.34=2.52=20070104-20:59:34.98=0.108=30.10=122.


20070104-20:59:33 : Created session
20070104-20:59:33 : Connecting to ******** on port #####
20070104-20:59:34 : Connection succeeded
20070104-20:59:34 : Initiated logon request
20070104-20:59:34 : Received logon request
20070104-20:59:34 : Responding to logon request
20070104-20:59:34 : Logon state is not valid for message
20070104-20:59:34 : Disconnecting


-- 
Regards,
		Alexey Zubko

Re: [Quickfix-developers] Semi OT : QF internal data hotbackup

[Jain, A. <Ani...@rb...>]

Oren Miller wrote:
> QuickFIX does a write and flush with every message as it is stored.

On Soalris 8 with NFS, I'm not sure, how effective is std::flush which is d=
one with every message for it's FileLog files. I know of one instance where=
 all dozen or so instances of QF FileLog files lost their tail part, on fil=
e system full error. I did not look into FileStore files, as we do not use =
it for recovery/resend.
The sequence number file is flushed with std::fflush, still the sequence we=
 recovered was out of quie old.
Maybe NFS cache takes over here and does actual physical writes based on it=
's own cache usage configuration.

It would be interesting to know the effectiveness of fsync(3C)/fdatasync(3R=
T) in such situation.

Caleb Epstein wrote:
> Rather than complicating the FileStore, wouldn't a better solution be
> to use one of the more "transactional" message stores, like the
> MySQLStore, or the OdbcStore backed by <pick your database>?

Looks like an interesting solution, if not for real time, then atleast for =
subsequent quick availability of messages in non-NFS systems. Or maybe fssn=
ap will be sufficient, for situation not requiring all those lots of featur=
es that come with MySQL etc?

Anil Jain
_______________________________________________________________________

This E-Mail (including any attachments) may contain privileged or confident=
ial information.  It is intended only for the addressee(s) indicated above.
The sender does not waive any of its rights, privileges or other protection=
s respecting this information. =20
Any distribution, copying or other use of this E-Mail or the information it=
 contains, by other than an intended recipient, is not sanctioned and is pr=
ohibited.
If you received this E-Mail in error, please delete it and advise the sende=
r (by return E-Mail or otherwise) immediately.

This E-Mail (including any attachments) has been scanned for viruses.=20
It is believed to be free of any virus or other defect that might affect an=
y computer system into which it is received and opened.=20
However, it is the responsibility of the recipient to ensure that it is vir=
us free.=20
The sender accepts no responsibility for any loss or damage arising in any =
way from its use.

E-Mail received by or sent from RBC Capital Markets is subject to review by=
 Supervisory personnel.=20
Such communications are retained and may be produced to regulatory authorit=
ies or others with legal rights to the information.

Re: [Quickfix-developers] Semi OT : QF internal data hotbackup

[Caleb E. <cal...@gm...>]

On 1/4/07, Oren Miller <or...@qu...> wrote:

> QuickFIX does a write and flush with every message as it is stored.
> I'm not very well versed on how a hard drive or OS handles this
> scenario.  I assume that it is unlikely but possible that the file
> can be caught in mid flush giving you a corrupted file.  Modifying
> the FileStore to make regular backups might be a better solution
> since you're backup solution can coordinate with the rest of the store.

Rather than complicating the FileStore, wouldn't a better solution be
to use one of the more "transactional" message stores, like the
MySQLStore, or the OdbcStore backed by <pick your database>?

Looking at 1.12.4, it seems like the BerkeleyDB-backed MessageStore I
contributed has disappeared.  How come?  Wasn't this included with at
least one release of QuickFIX?

http://permalink.gmane.org/gmane.comp.finance.quickfix.devel/294

-- 
Caleb Epstein

Re: [Quickfix-developers] Semi OT : QF internal data hotbackup

[Oren M. <or...@qu...>]

> - if just backuping more regularly is considered enough, are there any
> risks of copying a corrupted/incomplete file ? I did not check but  
> I guess
> QF opens its file pointer when the session starts and closes it  
> when it
> stops.

QuickFIX does a write and flush with every message as it is stored.   
I'm not very well versed on how a hard drive or OS handles this  
scenario.  I assume that it is unlikely but possible that the file  
can be caught in mid flush giving you a corrupted file.  Modifying  
the FileStore to make regular backups might be a better solution  
since you're backup solution can coordinate with the rest of the store.

> - if we go for NFS, how does QF handle the FS access to what is  
> stored in
> FileStorePath ? Does it work in RAM and flushes to disk from time  
> to time
> (with explicit fflushes or the OS decides) or are the messages  
> reloaded
> from disk every so often ?

As I said above a flush goes out with every sent message.  If the  
message is particularly large, the OS could also force a flush in  
between.  Explicit flushes guarantee a message is stored before it is  
sent.  Once a message is sent, there is no need to ever read from the  
disk unless processing a resend request.  During normal operation,  
this should not happen.  Typically, resend requests are also not  
particularly performance intensive.  Messages you receive do not get  
stored and so their performance will be generally unaffected by  
whatever storage you choose.  The exception to this is to update the  
sequence number file.

[Quickfix-developers] FileDescriptor Handling

[<ste...@fp...>]

Hi all,
is there a way to create a own file descriptor and put them into the QF engine and the engine works with it as its own?

The base idea was to create a communication process which forks a connection
 


- stefan

[Quickfix-developers] Semi OT : QF internal data hotbackup

[John G. <joh...@wa...>]

Hi there,

Planning for disaster (happy new year 2007 all ;-)...) I need to (better)
plan what to do in case the QuickFix machine goes down. 

Environment is either linux RH or solaris 9, QF is C++.

So far I am backuping every so often the directories pointed by
FileStorePath i.e.  sequence number and session "queue".  We are
considering moving this data to an NFS partition, so of course my
"performance issues warning" goes off. I am also concerned, in both cases,
about concurrent file access / invalid files on backup.

Can anyone please tell me :

- if just backuping more regularly is considered enough, are there any
risks of copying a corrupted/incomplete file ? I did not check but I guess
QF opens its file pointer when the session starts and closes it when it
stops.

- if we go for NFS, how does QF handle the FS access to what is stored in 
FileStorePath ? Does it work in RAM and flushes to disk from time to time 
(with explicit fflushes or the OS decides) or are the messages reloaded 
from disk every so often ? 

TIA for any information.

JG

Re: [Quickfix-developers] Replace versus cancel and resubmit

[Brian E. <azz...@ya...>]

Depending on the exchange, "cancel/replace" semantics are preferred to "can=
cel/new" semantics in that you keep your position within the order book. Du=
e to the advantage this confers (you could enter a GTC order months back an=
d replace it to something useful later, leapfrogging other orders due to yo=
ur age), most exchanges have pretty firm limits as to what can be changed i=
n a cancel/replace. Many exchanges only allow quantity revisions (some, onl=
y downward revisions), or price (but not price type) revisions, but very fe=
w allow wholesale changes (like account or CTI information).=0A=0AA cancel/=
new (which has actually been a unique message type in some systems, such as=
 the CME's CUBS system) loses position in the order book, which means you g=
o back to the bottom of the queue. This is less of an issue in exchanges th=
at don't do FIFO allocation (options can have pro-rata and other allocation=
 schemes that privilege certain types of users, such as market makers).=0A=
=0A- Brian Erst=0AThynk Software, Inc.=0A=0A----- Original Message ----=0AF=
rom: Charles Stangor <cst...@ch...>=0ATo: quickfix-developer=
s...@li...=0ASent: Tuesday, January 2, 2007 11:39:55 AM=0ASubj=
ect: [Quickfix-developers] Replace versus cancel and resubmit=0A=0AQuickFIX=
 Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html=
=0AQuickFIX Support: http://www.quickfixengine.org/services.html=0A=0A=0A=
=0A=0A =0A =0A=0A=0AIs there a particular advantage (other perhaps =0Athan =
commission fees) to replacing an order in QF rather than cancelling and =0A=
resubmitting a new order?  It seems that the replace sequence is basically =
=0Adoing a cancel/resubmit anyway.=0A=0A =0A=0Athanks=0A=0A =0A=0A =0A-----=
--------------------------------------------------------------------=0ATake=
 Surveys. Earn Cash. Influence the Future of IT=0AJoin SourceForge.net's Te=
chsay panel and you'll get the chance to share your=0Aopinions on IT & busi=
ness topics through brief surveys - and earn cash=0Ahttp://www.techsay.com/=
default.php?page=3Djoin.php&p=3Dsourceforge&CID=3DDEVDEV=0A________________=
_______________________________=0AQuickfix-developers mailing list=0AQuickf=
ix-...@li...=0Ahttps://lists.sourceforge.net/lists/l=
istinfo/quickfix-developers=0A=0A=0A=0A

[Quickfix-developers] Replace versus cancel and resubmit

[Charles S. <cst...@ch...>]

Is there a particular advantage (other perhaps than commission fees) to =
replacing an order in QF rather than cancelling and resubmitting a new =
order?  It seems that the replace sequence is basically doing a =
cancel/resubmit anyway.

thanks

[Quickfix-developers] crash during initiator->stop()

[Alexey Z. <ale...@gm...>]

Hello,

I have a crash in my Initiator when I call the stop().
My platform is Win2K + VC6 + QF 1.12.2.
It happened if the initiator can't establish a connection.
Actually the problem is in Initiator.cpp in some places the result of 
Session::lookupSession is not checking for NULL.
Here is an example:

void Initiator::connect()
{ QF_STACK_PUSH(Initiator::connect)

  Locker l(m_mutex);

  SessionIDs disconnected = m_disconnected;
  SessionIDs::iterator i = disconnected.begin();
  for ( ; i != disconnected.end(); ++i )
  {
    Session* pSession = Session::lookupSession( *i );
    if ( pSession->isEnabled() && pSession->isSessionTime() )
// fix:   if (pSession && pSession->isEnabled() && 
pSession->isSessionTime() )
      doConnect( *i, m_settings.get( *i ));
  }

  QF_STACK_POP
}


-- 
Regards,
		Alexey Zubko

Re: [Quickfix-developers] Disconnect at 00:00:00 GMT problem

[Brian E. <azz...@ya...>]

Oren -=0A=0AI see those types of checks in the non-static calls to SessionT=
ime.h (for instance, sessionTime->isSameSession(utcTime1, utcTime2)) which =
call the static methods, but not in the static methods themselves (for inst=
ance, SessionTime::isSameSession(startTime, endTime, startDay, endDay, time=
)).=0A=0AIf the static methods are only helper methods for the instance met=
hods, this is fine (although, in that case, the static methods should be pr=
ivate or protected). But if the static methods can be called in code that d=
oes not already check that startDay/endDay !=3D -1, you'll have problems.=
=0A=0A- Brian Erst=0AThynk Software, Inc.=0A=0A----- Original Message ----=
=0AFrom: Oren Miller <or...@qu...>=0ATo: Brian Erst <azzipsderf=
-qui...@ya...>=0ACc: qui...@li...=0ASent=
: Tuesday, December 26, 2006 7:25:32 PM=0ASubject: Re: [Quickfix-developers=
] Disconnect at 00:00:00 GMT problem=0A=0AI believe we are accounting for t=
his now.  Week long and daily sessions are now explicitly differentiated.  =
Take a look at the method isInRange:=0A=0A bool isInRange()=0A{=0A  DateTim=
e now =3D m_useLocalTime ? DateTime::nowLocal() : DateTime::nowUtc();=0A=0A=
=0A  if( m_startDay < 0 && m_endDay < 0 )=0A    return isInRange( m_startTi=
me, m_endTime, now );=0A  else=0A    return isInRange=0A      ( m_startTime=
, m_endTime, m_startDay, m_endDay, now );=0A}=0A=0A=0AIf the start and end =
day are less than 0, then then a daily session is used, otherwise a weekly =
session is used.  If you look at the SessionFactory, you will notice that s=
tartDay and endDay default to -1 and do not get set to a value unless Start=
Day/EndDay is in the configuration file.  So as long as he does not set the=
m, his session should always be treated as daily.=0A=0A=0A--oren=0A=0AOn De=
c 26, 2006, at 11:01 PM, Brian Erst wrote:=0A=0AQuickFIX Documentation: htt=
p://www.quickfixengine.org/quickfix/doc/html/index.html=0AQuickFIX Support:=
 http://www.quickfixengine.org/services.html=0A=0A=0A Oleg -=0A=0AI believe=
 this was (partially) fixed in SVN. Looking at SessionTime.cpp, it looks li=
ke there was a change made on December 5, 2006 that would impact this issue=
.=0A=0AThe previous code checked to see if the session start date was the s=
ame as the end date and, if so, did a simple time check that, alas, doesn't=
 work if start time and end times are equal.=0A=0AOld code:=0A=0Aif (startD=
ay =3D=3D endDay)=0A{=0A  if (timeOnly < startTime && timeOnly > endTime)=
=0A    return false;=0A}=0A=0AThat code fails if start and end times overla=
p (start late in one UTC day and end early in the next) or if they are the =
same. "00:00" is less than the start time (22:30) but it isn't greater than=
 the end time (22:30).=0A=0ANew code:=0A=0Aif (startDay =3D=3D endDay)=0A{=
=0A  if (currentDay !=3D startDay)=0A    return true;=0A  return isSessionT=
ime(startTime, endTime, time);=0A}=0A=0AThis change does three things: it m=
akes an implicit assumption that if startDay=3D=3DendDay that it must be a =
"week-long" session, if the current day isn't the starting day, there is no=
 need to check the time (time only applies to that day of the week), and fi=
nally, calls isSessionTime, which has a better time checking algorithm that=
 tests for overlaps. This happily fixes a problem that I had two years ago =
(although I worked around the issue long ago).=0A=0AI don't know that it co=
mpletely solves your problem though. It definitely would fix the "getting d=
umped at midnight" problem, but unless something upstream of this code has =
changed, I think it might introduce a "your session never ends" problem. La=
st I checked (back in 1.11.x), QF had no way of distinguishing between a we=
eklong session (Friday late-Friday early) and a "daily" session (no start/e=
nd day). In both cases, the "start day" equaled the "end day" (Fri-Fri was =
5=3D=3D5, none was 1=3D=3D1). If this is still the case, the new code would=
 see your config as a weeklong session with identical start/end times - whi=
ch would mean nothing is EVER out of session. Hopefully, something has been=
 changed upstream and a "daily" session differs from a "weeklong" session.=
=0A=0A- Brian Erst=0AThynk Software, Inc.=0A=0A=0A----- Original Message --=
--=0AFrom: Oleg Pecker <ol...@st...>=0ATo: quickfix-developers=
@lists.sourceforge.net=0ASent: Tuesday, December 26, 2006 11:13:53 AM=0ASub=
ject: [Quickfix-developers] Disconnect at 00:00:00 GMT problem=0A=0AQuickFI=
X Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html=
=0AQuickFIX Support: http://www.quickfixengine.org/services.html=0A=0A=0A  =
 Hi,=0A =0A=0AI have a problem with disconnect. =0AI=A2ve implemented a FIX=
 client using quickfix v 1.12.4 which is actually defined as "initiator".=
=0A =0A=0AHere is my configuration file:=0A StartTime=3D22:30:00   (IST =3D=
  GMT + 22:30) =0A EndTime=3D22:30:00   (IST: GMT + 22:30) =0ASendResetSeqN=
umFlag=3DY=0AResetOnLogout=3DY=0AResetOnDisconnect=3DY=0AReconnectInterval=
=3D20=0AHeartBtInt=3D20=0A =0A The problem is that my client (the initiator=
) disconnects exactly at 00:00:00 GMT and does not reconnect. =0ADoes any o=
ne know what could be the problem? =0A =0A=0AThanks,=0AOleg =0A =0A=0A =0A =
-------------------------------------------------------------------------=
=0ATake Surveys. Earn Cash. Influence the Future of IT=0AJoin SourceForge.n=
et's Techsay panel and you'll get the chance to share your=0Aopinions on IT=
 & business topics through brief surveys - and earn cash=0Ahttp://www.techs=
ay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3DDEVDEV=0A_________=
______________________________________=0AQuickfix-developers mailing list=
=0AQ...@li...=0Ahttps://lists.sourceforge.ne=
t/lists/listinfo/quickfix-developers=0A=0A=0A=0A=0A------------------------=
-------------------------------------------------=0ATake Surveys. Earn Cash=
. Influence the Future of IT=0AJoin SourceForge.net's Techsay panel and you=
'll get the chance to share your=0Aopinions on IT & business topics through=
 brief surveys - and earn cash=0Ahttp://www.techsay.com/default.php?page=3D=
join.php&p=3Dsourceforge&CID=3DDEVDEV______________________________________=
_________=0AQuickfix-developers mailing lis...@li...=
urceforge.net=0Ahttps://lists.sourceforge.net/lists/listinfo/quickfix-devel=
opers=0A =0A=0A=0A=0A=0A=0A

Re: [Quickfix-developers] Disconnect at 00:00:00 GMT problem

[Oren M. <or...@qu...>]

I believe we are accounting for this now.  Week long and daily =20
sessions are now explicitly differentiated.  Take a look at the =20
method isInRange:

bool isInRange()
{
   DateTime now =3D m_useLocalTime ? DateTime::nowLocal() : =20
DateTime::nowUtc();

   if( m_startDay < 0 && m_endDay < 0 )
     return isInRange( m_startTime, m_endTime, now );
   else
     return isInRange
       ( m_startTime, m_endTime, m_startDay, m_endDay, now );
}

If the start and end day are less than 0, then then a daily session =20
is used, otherwise a weekly session is used.  If you look at the =20
SessionFactory, you will notice that startDay and endDay default to =20
-1 and do not get set to a value unless StartDay/EndDay is in the =20
configuration file.  So as long as he does not set them, his session =20
should always be treated as daily.

--oren

On Dec 26, 2006, at 11:01 PM, Brian Erst wrote:

> QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/=20
> html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> Oleg -
>
> I believe this was (partially) fixed in SVN. Looking at =20
> SessionTime.cpp, it looks like there was a change made on December =20
> 5, 2006 that would impact this issue.
>
> The previous code checked to see if the session start date was the =20
> same as the end date and, if so, did a simple time check that, =20
> alas, doesn't work if start time and end times are equal.
>
> Old code:
>
> if (startDay =3D=3D endDay)
> {
>   if (timeOnly < startTime && timeOnly > endTime)
>     return false;
> }
>
> That code fails if start and end times overlap (start late in one =20
> UTC day and end early in the next) or if they are the same. "00:00" =20=

> is less than the start time (22:30) but it isn't greater than the =20
> end time (22:30).
>
> New code:
>
> if (startDay =3D=3D endDay)
> {
>   if (currentDay !=3D startDay)
>     return true;
>   return isSessionTime(startTime, endTime, time);
> }
>
> This change does three things: it makes an implicit assumption that =20=

> if startDay=3D=3DendDay that it must be a "week-long" session, if the =20=

> current day isn't the starting day, there is no need to check the =20
> time (time only applies to that day of the week), and finally, =20
> calls isSessionTime, which has a better time checking algorithm =20
> that tests for overlaps. This happily fixes a problem that I had =20
> two years ago (although I worked around the issue long ago).
>
> I don't know that it completely solves your problem though. It =20
> definitely would fix the "getting dumped at midnight" problem, but =20
> unless something upstream of this code has changed, I think it =20
> might introduce a "your session never ends" problem. Last I checked =20=

> (back in 1.11.x), QF had no way of distinguishing between a =20
> weeklong session (Friday late-Friday early) and a "daily" session =20
> (no start/end day). In both cases, the "start day" equaled the "end =20=

> day" (Fri-Fri was 5=3D=3D5, none was 1=3D=3D1). If this is still the =
case, =20
> the new code would see your config as a weeklong session with =20
> identical start/end times - which would mean nothing is EVER out of =20=

> session. Hopefully, something has been changed upstream and a =20
> "daily" session differs from a "weeklong" session.
>
> - Brian Erst
> Thynk Software, Inc.
>
>
> ----- Original Message ----
> From: Oleg Pecker <ol...@st...>
> To: qui...@li...
> Sent: Tuesday, December 26, 2006 11:13:53 AM
> Subject: [Quickfix-developers] Disconnect at 00:00:00 GMT problem
>
> QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/=20
> html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> Hi,
>
>
> I have a problem with disconnect.
>
> I=92ve implemented a FIX client using quickfix v 1.12.4 which is =20
> actually defined as "initiator".
>
>
> Here is my configuration file:
> StartTime=3D22:30:00   (IST =3D  GMT + 22:30)
> EndTime=3D22:30:00   (IST: GMT + 22:30)
>
> SendResetSeqNumFlag=3DY
>
> ResetOnLogout=3DY
>
> ResetOnDisconnect=3DY
>
> ReconnectInterval=3D20
>
> HeartBtInt=3D20
>
>
> The problem is that my client (the initiator) disconnects exactly =20
> at 00:00:00 GMT and does not reconnect.
>
> Does any one know what could be the problem?
>
>
> Thanks,
>
> Oleg
>
>
> ----------------------------------------------------------------------=20=

> ---
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to =20
> share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?=20
> page=3Djoin.php&p=3Dsourceforge&CID=3DDEVDEV
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>
> ----------------------------------------------------------------------=20=

> ---
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to =20
> share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?=20
> page=3Djoin.php&p=3Dsourceforge&CID=3DDEVDEV____________________________=
____=20
> _______________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers

Re: [Quickfix-developers] Disconnect at 00:00:00 GMT problem

[Brian E. <azz...@ya...>]

Oleg -=0A=0AI believe this was (partially) fixed in SVN. Looking at=0ASessi=
onTime.cpp, it looks like there was a change made on December 5,=0A2006 tha=
t would impact this issue.=0A=0AThe previous code checked to=0Asee if the s=
ession start date was the same as the end date and, if so,=0Adid a simple t=
ime check that, alas, doesn't work if start time and end=0Atimes are equal.=
=0A=0AOld code:=0A=0Aif (startDay =3D=3D endDay)=0A{=0A  if (timeOnly < sta=
rtTime && timeOnly > endTime)=0A    return false;=0A}=0A=0AThat=0Acode fail=
s if start and end times overlap (start late in one UTC day=0Aand end early=
 in the next) or if they are the same. "00:00" is less=0Athan the start tim=
e (22:30) but it isn't greater than the end time=0A(22:30).=0A=0ANew code:=
=0A=0Aif (startDay =3D=3D endDay)=0A{=0A  if (currentDay !=3D startDay)=0A =
   return true;=0A  return isSessionTime(startTime, endTime, time);=0A}=0A=
=0AThis=0Achange does three things: it makes an implicit assumption that if=
=0AstartDay=3D=3DendDay that it must be a "week-long" session, if the curre=
nt=0Aday isn't the starting day, there is no need to check the time (time=
=0Aonly applies to that day of the week), and finally, calls=0AisSessionTim=
e, which has a better time checking algorithm that tests=0Afor overlaps. Th=
is happily fixes a problem that I had two years ago=0A(although I worked ar=
ound the issue long ago).=0A=0AI don't know that=0Ait completely solves you=
r problem though. It definitely would fix the=0A"getting dumped at midnight=
" problem, but unless something upstream of=0Athis code has changed, I thin=
k it might introduce a "your session never=0Aends" problem. Last I checked =
(back in 1.11.x), QF had no way of=0Adistinguishing between a weeklong sess=
ion (Friday late-Friday early)=0Aand a "daily" session (no start/end day). =
In both cases, the "start=0Aday" equaled the "end day" (Fri-Fri was 5=3D=3D=
5, none was 1=3D=3D1). If this=0Ais still the case, the new code would see =
your config as a weeklong=0Asession with identical start/end times - which =
would mean nothing is=0AEVER out of session. Hopefully, something has been =
changed upstream and=0Aa "daily" session differs from a "weeklong" session.=
=0A=0A- Brian Erst=0AThynk Software, Inc.=0A=0A=0A----- Original Message --=
--=0AFrom: Oleg Pecker <ol...@st...>=0ATo: quickfix-developers=
@lists.sourceforge.net=0ASent: Tuesday, December 26, 2006 11:13:53 AM=0ASub=
ject: [Quickfix-developers] Disconnect at 00:00:00 GMT problem=0A=0AQuickFI=
X Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html=
=0AQuickFIX Support: http://www.quickfixengine.org/services.html=0A=0A=0A=
=0A=0A=0A =0A=0A=0A =0A=0A=0A<!--=0A=0A /* Style Definitions */=0A p.MsoNor=
mal, li.MsoNormal, div.MsoNormal=0A=09{margin:0in;=0Amargin-bottom:.0001pt;=
=0Afont-size:12.0pt;=0Afont-family:"Times New Roman";}=0Ah1=0A=09{margin-to=
p:12.0pt;=0Amargin-right:0in;=0Amargin-bottom:3.0pt;=0Amargin-left:0in;=0A=
=0Afont-size:16.0pt;=0Afont-family:Arial;}=0Ah3=0A=09{margin-top:12.0pt;=0A=
margin-right:0in;=0Amargin-bottom:3.0pt;=0Amargin-left:0in;=0A=0Afont-size:=
13.0pt;=0Afont-family:Arial;}=0Aa:link, span.MsoHyperlink=0A=09{color:blue;=
=0Atext-decoration:underline;}=0Aa:visited, span.MsoHyperlinkFollowed=0A=09=
{color:purple;=0Atext-decoration:underline;}=0Aspan.EmailStyle17=0A=09{font=
-family:"Times New Roman";=0Acolor:windowtext;=0Afont-weight:normal;=0Afont=
-style:normal;=0Atext-decoration:none none;}=0Ap.NormalWeb1, li.NormalWeb1,=
 div.NormalWeb1=0A=09{margin-top:7.5pt;=0Amargin-right:0in;=0Amargin-left:2=
2.5pt;=0Afont-size:12.0pt;=0Afont-family:"Times New Roman";}=0A _filtered {=
=0Amargin:1.0in 1.25in 1.0in 1.25in;}=0Adiv.Section1=0A=09{}=0A-->=0A=0A=0A=
=0A=0A=0A=0AHi,=0A=0A=0A =0A=0A=0AI have a problem with disconnect. =0A=0A=
=0AI=A2ve implemented a FIX client using=0Aquickfix v 1.12.4 which is actua=
lly defined as "initiator".=0A=0A=0A =0A=0A=0AHere is my configuration file=
:=0A=0AStartTime=3D22:30:00   (IST =3D  GMT + 22:30) =0A=0AEndTime=3D22:30:=
00   (IST: GMT + 22:30) =0A=0A=0ASendResetSeqNumFlag=3DY=0A=0A=0AResetOnLog=
out=3DY=0A=0A=0AResetOnDisconnect=3DY=0A=0A=0AReconnectInterval=3D20=0A=0A=
=0AHeartBtInt=3D20=0A=0A=0A =0A=0AThe problem is that my client (the initia=
tor) disconnects exactly at 00:00:00 GMT and does not reconnect. =0A=0A=0AD=
oes any one know what could be the problem? =0A=0A=0A =0A=0A=0AThanks,=0A=
=0A=0AOleg =0A=0A=0A =0A=0A=0A=0A=0A=0A------------------------------------=
-------------------------------------=0ATake Surveys. Earn Cash. Influence =
the Future of IT=0AJoin SourceForge.net's Techsay panel and you'll get the =
chance to share your=0Aopinions on IT & business topics through brief surve=
ys - and earn cash=0Ahttp://www.techsay.com/default.php?page=3Djoin.php&p=
=3Dsourceforge&CID=3DDEVDEV=0A_____________________________________________=
__=0AQuickfix-developers mailing lis...@li...=
ge.net=0Ahttps://lists.sourceforge.net/lists/listinfo/quickfix-developers=
=0A=0A=0A=0A

[Quickfix-developers] Disconnect at 00:00:00 GMT problem

[Oleg P. <ol...@st...>]

Hi,

 

I have a problem with disconnect. 

I've implemented a FIX client using quickfix v 1.12.4 which is actually
defined as "initiator".

 

Here is my configuration file:
StartTime=22:30:00   (IST =  GMT + 22:30) 
EndTime=22:30:00   (IST: GMT + 22:30) 

SendResetSeqNumFlag=Y

ResetOnLogout=Y

ResetOnDisconnect=Y

ReconnectInterval=20

HeartBtInt=20

 
The problem is that my client (the initiator) disconnects exactly at
00:00:00 GMT and does not reconnect. 

Does any one know what could be the problem? 

 

Thanks,

Oleg 

 

Re: [Quickfix-developers] Invalid FIX messages

[Mike S. <MS...@rj...>]

I'll try that out.  Thanks!

-----Original Message-----
From: Oren Miller [mailto:or...@qu...]=20
Sent: Thursday, December 21, 2006 2:22 PM
To: Mike Smith
Cc: qui...@li...
Subject: Re: [Quickfix-developers] Invalid FIX messages

I think we were working on adding this capability, but currently you =20
will need to comment out the validation if you want this behavior.  =20
Look for the line:

m_dataDictionary.validate( message );

in Session.cpp and comment it out.  I think that should let your =20
messages through.

--oren

On Dec 20, 2006, at 5:54 PM, Mike Smith wrote:

> QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/=20
> html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> I've got sort of a messed up situation.  I've written a QF acceptor
> which was built to replace a legacy VB6 home-grown FIX application.
> I've found an issue where the legacy app accepts invalid FIX messages
> (tags repeated with different values).  I am trying to get our =20
> existing
> clients to correct this and send valid FIX messages, but wanted to =20
> know
> if there was any way I could trap these invalid messages and somehow
> process them in my QF Acceptor?  Fyi...the acceptor is written =20
> in .NET.
>
> Many thanks for your help.
>
> -Mike
>
> ----------------------------------------------------------------------

> ---
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to =20
> share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?=20
> page=3Djoin.php&p=3Dsourceforge&CID=3DDEVDEV
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>

Re: [Quickfix-developers] Invalid FIX messages

[Oren M. <or...@qu...>]

I think we were working on adding this capability, but currently you  
will need to comment out the validation if you want this behavior.   
Look for the line:

m_dataDictionary.validate( message );

in Session.cpp and comment it out.  I think that should let your  
messages through.

--oren

On Dec 20, 2006, at 5:54 PM, Mike Smith wrote:

> QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/ 
> html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> I've got sort of a messed up situation.  I've written a QF acceptor
> which was built to replace a legacy VB6 home-grown FIX application.
> I've found an issue where the legacy app accepts invalid FIX messages
> (tags repeated with different values).  I am trying to get our  
> existing
> clients to correct this and send valid FIX messages, but wanted to  
> know
> if there was any way I could trap these invalid messages and somehow
> process them in my QF Acceptor?  Fyi...the acceptor is written  
> in .NET.
>
> Many thanks for your help.
>
> -Mike
>
> ---------------------------------------------------------------------- 
> ---
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to  
> share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php? 
> page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>

Re: [Quickfix-developers] memory leak in quickfix 1.12.x

[Oren M. <or...@qu...>]

Yeah, I would check the latest, and failing that what is in svn.  I =20
recall this being reported and believe it has been fixed, though I =20
can't recall exactly when.

--oren

On Dec 21, 2006, at 5:14 PM, Abel Monroy wrote:

> QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/=20
> html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> Hello,
>
> I'd like to ask you about an issue, to see if someone has seen it too.
> I check an executable using 1.12.2 with valgrind and I found some =20
> memory
> leaks in quickfix. This is the valgrind output:
>
>  * When a session connects and send a log on message:
> =3D=3D7480=3D=3D
> =3D=3D7480=3D=3D Thread 3:
> =3D=3D7480=3D=3D Conditional jump or move depends on uninitialised =
value(s)
> =3D=3D7480=3D=3D    at 0x4174C6C: FIX::Session::nextLogon(FIX::Message =
const&)
> (Session.cpp:204)
> =3D=3D7480=3D=3D    by 0x418D7A1: FIX::Session::next(FIX::Message =
const&, =20
> bool)
> (Session.cpp:1270)
> =3D=3D7480=3D=3D    by 0x418C8D3: FIX::Session::next(std::string =
const&, bool)
> (Session.cpp:1228)
> =3D=3D7480=3D=3D    by 0x41CA1F1: =20
> FIX::ThreadedSocketConnection::processStream()
> (ThreadedSocketConnection.cpp:156)
> =3D=3D7480=3D=3D    by 0x41C9BB1: =
FIX::ThreadedSocketConnection::read()
> (ThreadedSocketConnection.cpp:105)
> =3D=3D7480=3D=3D    by 0x41C4C94:
> FIX::ThreadedSocketAcceptor::socketConnectionThread(void*)
> (ThreadedSocketAcceptor.cpp:252)
> =3D=3D7480=3D=3D    by 0x4368DE7: start_thread (in /lib/tls/=20
> libpthread-0.60.so)
> =3D=3D7480=3D=3D    by 0x4897939: clone (in /lib/tls/libc-2.3.2.so)
>
>  * When a session disconnects:
> =3D=3D7480=3D=3D
> =3D=3D7480=3D=3D Conditional jump or move depends on uninitialised =
value(s)
> =3D=3D7480=3D=3D    at 0x41C9EB7: =
FIX::ThreadedSocketConnection::read()
> (ThreadedSocketConnection.cpp:110)
> =3D=3D7480=3D=3D    by 0x41C4C94:
> FIX::ThreadedSocketAcceptor::socketConnectionThread(void*)
> (ThreadedSocketAcceptor.cpp:252)
> =3D=3D7480=3D=3D    by 0x4368DE7: start_thread (in /lib/tls/=20
> libpthread-0.60.so)
> =3D=3D7480=3D=3D    by 0x4897939: clone (in /lib/tls/libc-2.3.2.so)
>
> * And we get this one too when application is starting:
> =3D=3D7480=3D=3D Thread 4:
> =3D=3D7480=3D=3D Syscall param socketcall.getsockopt(optlen) points to
> uninitialised byte(s)
> =3D=3D7480=3D=3D    at 0x4898452: getsockopt (in =
/lib/tls/libc-2.3.2.so)
> =3D=3D7480=3D=3D    by 0x41C41C3:
> FIX::ThreadedSocketAcceptor::socketAcceptorThread(void*)
> (ThreadedSocketAcceptor.cpp:203)
> =3D=3D7480=3D=3D    by 0x4368DE7: start_thread (in /lib/tls/=20
> libpthread-0.60.so)
> =3D=3D7480=3D=3D    by 0x4897939: clone (in /lib/tls/libc-2.3.2.so)
> =3D=3D7480=3D=3D  Address 0x7692870 is on thread 4's stack
>
> Our application is using quickfix 1.12.2
>         libquickfix.so.8 =3D>
> /usr/local/quickfix-1.12.2/lib/libquickfix.so.8 (0x00111000)
>
> The same executable using 1.10 doesn't have this memory leaks. =20
> Maybe we
> should use last version, 1.12.4 to see if this is fixed?
>
> Last question is about using ACE library and quickfix
> (http://www.cs.wustl.edu/~schmidt/ACE.html)
> In order to compile an application using the ACE library and quickfix
> 1.12.2, we had to
> change some defines (just some change of names, eg. QUICKFIX_ALLOCATOR
> instead ALLOCATOR in FieldMap.h), maybe it could
> be added to the next version, in order to be able to compile with ACE
> library without modify any files?
> Someone else is using ACE and quickfix and has made this changes as =20=

> well?
>
> Thanks,
> Abel
>
> By the way, Merry Christmas :)
>
>
> Oren Miller wrote:
>> I would not recommend 1.12.3 over 1.12.4.  We just haven't yet =20
>> added a
>> tag for 1.12.4.  What exists in the repository is newer than both
>> those versions.  The warning isn't that troubling, what I'm wondering
>> is if their is still a crash with the latest from svn.  Is there?
>> If so can you put together a sample application and config that we
>> could use to replicate it?  I put together a basic acceptor that uses
>> the MySQLStore and was not able to duplicate the crash with the svn
>> version.
>>
>> --oren
> Oren, about the crash using 1.12.4, it happen as well using 1.12.2, we
> are going to try out using last svn version. We see that it doesn't
> happen always. Sometimes the application goes well, and some others we
> have this crash.
>>
>> On Dec 13, 2006, at 5:08 AM, Abel Monroy wrote:
>>
>>> Hi all,
>>>
>>> I just check in svn, and there this code is just the same. The last
>>> revision is 1641, Fri Jul 28 12:41:00 2006.
>>>
>>>
>>> 92  char* getValue( int row, int column )
>>> 93   {
>>> 94          if( m_rows.empty() )
>>> 95                {
>>> 96                  MYSQL_ROW row =3D 0;
>>> 97                  while( row =3D mysql_fetch_row( m_result ) )
>>> 98                    m_rows.push_back(row);
>>> 99                }
>>> 100                return m_rows[row][column];
>>> 101  }
>>>
>>> We just change line 97 by:
>>>
>>> while (( row =3D mysql_fetch_row( m_result ) ) !=3D 0)
>>>
>>> Our compiler is g++ (GCC) 3.2.3 20030502 (Red Hat Linux 3.2.3-52),
>>> but we suppose that this warning would
>>> raise with other versions.
>>>
>>> By the way, I saw in svn that the last version tagged is
>>> release_1_12_3. We are just going to upgrade
>>> our quickfix version in our production environment. I wonder if it
>>> would be better to upgrade to 1.12.3,
>>> or there are some critical bug that it's fixed in 1.12.4.
>>>
>>> Regards,
>>> Abel Monroy
>>>
>>>
>>> Oren Miller wrote:
>>>> I believe this has been resolved in svn.  Could you try checking =20=

>>>> out
>>>> the latest and trying it out?
>>>>
>>>> --oren
>>>>
>>>> On Dec 12, 2006, at 5:11 AM, Abel Monroy wrote:
>>>>
>>>>> QuickFIX Documentation:
>>>>> http://www.quickfixengine.org/quickfix/doc/html/index.html
>>>>> QuickFIX Support: http://www.quickfixengine.org/services.html
>>>>>
>>>>> Hi everyone,
>>>>>
>>>>> we're upgrading our quickfix applications to last version, =20
>>>>> 1.12.4, and
>>>>> we found some problems, so maybe someone could give us a hand.
>>>>> Compiling the version, we've seen this warning:
>>>>>
>>>>> C++/MySQLConnection.h:98: warning: suggest parentheses around
>>>>> assignment
>>>>> used,   as truth value
>>>>>
>>>>> which is this line:
>>>>> while ( row =3D mysql_fetch_row( m_result ) )
>>>>>
>>>>> We put the parentheses in order to avoid the warning, but now, we
>>>>> compile the application and it crashs with a core.
>>>>>
>>>>> #0  0x00c7fcdf in raise () from /lib/tls/libc.so.6
>>>>> #1  0x00c814e5 in abort () from /lib/tls/libc.so.6
>>>>> #2  0x08061b6b in Unexpected () at src/vtfix.cpp:25
>>>>> #3  0x00711567 in std::terminate () from /usr/lib/libstdc++.so.5
>>>>> #4  0x007113f5 in __cxa_call_unexpected () from
>>>>> /usr/lib/libstdc++.so.5
>>>>> #5  0x00e7e928 in Session (this=3D0x96ec7e0, application=3D@0x0,
>>>>> messageStoreFactory=3D@0x0, sessionID=3D@0x96f6198,
>>>>> dataDictionary=3D@0x118a2f0,
>>>>>     sessionTime=3D@0x118a290, pLogFactory=3D0x0) at Mutex.h:76
>>>>> #6  0x00ea8067 in FIX::SessionFactory::create (this=3D0x118a560,
>>>>> sessionID=3D@0x96b90a0, settings=3D@0x96e1474) at Field.h:308
>>>>> #7  0x00eb9e23 in FIX::Acceptor::initialize (this=3D0x96cc3b0) at
>>>>> stl_tree.h:199
>>>>> #8  0x00eb98a0 in FIX::Acceptor::Acceptor$base () at
>>>>> stl_function.h:197
>>>>> #9  0x00ecf0fe in
>>>>> FIX::ThreadedSocketAcceptor::ThreadedSocketAcceptor ()
>>>>> at new:89
>>>>>
>>>>> It happens when we are making the new to a ThreadadSocketAcceptor
>>>>> object.
>>>>>
>>>>>   _store_factory =3D new FIX::MySQLStoreFactory( *_settings );
>>>>>   _log_factory =3D new FIX::MySQLLogFactory( *_settings );
>>>>>
>>>>>   try {
>>>>>     _acceptor =3D new FIX::ThreadedSocketAcceptor (*_application,
>>>>> *_store_factory,
>>>>>                          *_settings, *_log_factory);
>>>>>   }
>>>>>
>>>>> quickfix is compile with ./configure --with-mysql=3D/usr in order =
to
>>>>> have
>>>>> mysql support. It seems that we're missing something, but we =20
>>>>> are stuck
>>>>> with this problem, so we'd appreciate your comments.
>>>>>
>>>>> Regards,
>>>>> Abel Monroy Ferrero
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ****************************** AVISO LEGAL
>>>>> ******************************
>>>>> La informaci=F3n contenida en este mensaje es para uso exclusivo =
de
>>>>> su destinatario. No debe copiarse, transmitirse a terceros ni
>>>>> guardarse por estos =FAltimos, salvo autorizaci=F3n del remitente.
>>>>> Puede contener informaci=F3n confidencial o legalmente protegida =20=

>>>>> cuyo
>>>>> r=E9gimen legal de utilizaci=F3n no se ve afectado por el hecho de =
que
>>>>> haya sido enviada por correo electr=F3nico.
>>>>> Su env=EDo por error a una persona distinta de su destinatario =
real
>>>>> no implica que se haya modificado tal destinatario ni supone
>>>>> renuncia a su eventual car=E1cter confidencial o al r=E9gimen =
legal =20
>>>>> que
>>>>> rija su utilizaci=F3n.
>>>>> Cualquier opini=F3n expresada en este mensaje vincular=E1
>>>>> exclusivamente a la persona que lo haya remitido, excepto =20
>>>>> cuando el
>>>>> mensaje establezca lo contrario y el remitente est=E9 autorizado =20=

>>>>> para
>>>>> establecer que dichas opiniones vincular=E1n a esta entidad.
>>>>> En el supuesto de que este correo se recibiera por error, rogamos
>>>>> procedan a borrarlo, sin reenviarlo a terceros ni conservarlo en
>>>>> cualquier soporte y nos informen inmediatamente llamando al
>>>>> tel=E9fono 34 91 7095401 o a la direcci=F3n de correo electr=F3nico
>>>>> remitente. Gracias.
>>>>> ****************************** DISCLAIMER
>>>>> ******************************
>>>>> The information contained in this message is for the exclusive use
>>>>> of the named person. It can not be copied, transmitted to third
>>>>> parties or stored by the latter, except if authorised by the =20
>>>>> sender.
>>>>> It may contain confidential or legally privileged information =20
>>>>> whose
>>>>> legal regime is not affected by the fact that this information has
>>>>> been sent by e-mail.
>>>>> Its erroneous transmission to a person other than the real named
>>>>> person neither implies any modification of this named person nor a
>>>>> renunciation of the eventual confidentiality or legal regime
>>>>> affecting the use of concerned message.
>>>>> Any views expressed in this message are binding exclusively upon
>>>>> the individual sender, except where the message states otherwise
>>>>> and the sender is authorised to bind this entity.
>>>>> If you receive this message in error, please delete it without
>>>>> transmitting it to any third party or keeping it in any form and
>>>>> notify us immediately either by phone (34 91 7095401) or using the
>>>>> e- mail address of the sender. Thank You.
>>>>>
>>>>> ------------------------------------------------------------------=20=

>>>>> -------
>>>>>
>>>>> Take Surveys. Earn Cash. Influence the Future of IT
>>>>> Join SourceForge.net's Techsay panel and you'll get the chance to
>>>>> share your
>>>>> opinions on IT & business topics through brief surveys - and =20
>>>>> earn cash
>>>>> http://www.techsay.com/default.php?=20
>>>>> page=3Djoin.php&p=3Dsourceforge&CID=3DDEVDEV
>>>>>
>>>>> _______________________________________________
>>>>> Quickfix-developers mailing list
>>>>> Qui...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>>>>>
>>>>
>>>>
>>>
>>>
>>>
>>> ****************************** AVISO LEGAL
>>> ******************************
>>> La informaci=F3n contenida en este mensaje es para uso exclusivo de =
su
>>> destinatario. No debe copiarse, transmitirse a terceros ni guardarse
>>> por estos =FAltimos, salvo autorizaci=F3n del remitente.
>>> Puede contener informaci=F3n confidencial o legalmente protegida =
cuyo
>>> r=E9gimen legal de utilizaci=F3n no se ve afectado por el hecho de =
que
>>> haya sido enviada por correo electr=F3nico.
>>> Su env=EDo por error a una persona distinta de su destinatario real =
no
>>> implica que se haya modificado tal destinatario ni supone renuncia a
>>> su eventual car=E1cter confidencial o al r=E9gimen legal que rija su
>>> utilizaci=F3n.
>>> Cualquier opini=F3n expresada en este mensaje vincular=E1 =
exclusivamente
>>> a la persona que lo haya remitido, excepto cuando el mensaje
>>> establezca lo contrario y el remitente est=E9 autorizado para
>>> establecer que dichas opiniones vincular=E1n a esta entidad.
>>> En el supuesto de que este correo se recibiera por error, rogamos
>>> procedan a borrarlo, sin reenviarlo a terceros ni conservarlo en
>>> cualquier soporte y nos informen inmediatamente llamando al tel=E9fono=

>>> 34 91 7095401 o a la direcci=F3n de correo electr=F3nico remitente. =20=

>>> Gracias.
>>> ****************************** DISCLAIMER =20
>>> ******************************
>>> The information contained in this message is for the exclusive =20
>>> use of
>>> the named person. It can not be copied, transmitted to third parties
>>> or stored by the latter, except if authorised by the sender.
>>> It may contain confidential or legally privileged information whose
>>> legal regime is not affected by the fact that this information has
>>> been sent by e-mail. Its erroneous transmission to a person other
>>> than the real named person neither implies any modification of this
>>> named person nor a renunciation of the eventual confidentiality or
>>> legal regime affecting the use of concerned message.
>>> Any views expressed in this message are binding exclusively upon the
>>> individual sender, except where the message states otherwise and the
>>> sender is authorised to bind this entity. If you receive this =20
>>> message
>>> in error, please delete it without transmitting it to any third =20
>>> party
>>> or keeping it in any form and notify us immediately either by phone
>>> (34 91 7095401) or using the e- mail address of the sender. Thank =20=

>>> You.
>>>
>>
>>
>
>
>
> ****************************** AVISO LEGAL =20
> ******************************
> La informaci=F3n contenida en este mensaje es para uso exclusivo de =20=

> su destinatario. No debe copiarse, transmitirse a terceros ni =20
> guardarse por estos =FAltimos, salvo autorizaci=F3n del remitente.
> Puede contener informaci=F3n confidencial o legalmente protegida cuyo =20=

> r=E9gimen legal de utilizaci=F3n no se ve afectado por el hecho de que =
=20
> haya sido enviada por correo electr=F3nico.
> Su env=EDo por error a una persona distinta de su destinatario real =20=

> no implica que se haya modificado tal destinatario ni supone =20
> renuncia a su eventual car=E1cter confidencial o al r=E9gimen legal =
que =20
> rija su utilizaci=F3n.
> Cualquier opini=F3n expresada en este mensaje vincular=E1 =20
> exclusivamente a la persona que lo haya remitido, excepto cuando el =20=

> mensaje establezca lo contrario y el remitente est=E9 autorizado para =20=

> establecer que dichas opiniones vincular=E1n a esta entidad.
> En el supuesto de que este correo se recibiera por error, rogamos =20
> procedan a borrarlo, sin reenviarlo a terceros ni conservarlo en =20
> cualquier soporte y nos informen inmediatamente llamando al =20
> tel=E9fono 34 91 7095401 o a la direcci=F3n de correo electr=F3nico =20=

> remitente. Gracias.
> ****************************** DISCLAIMER =20
> ******************************
> The information contained in this message is for the exclusive use =20
> of the named person. It can not be copied, transmitted to third =20
> parties or stored by the latter, except if authorised by the sender.
> It may contain confidential or legally privileged information whose =20=

> legal regime is not affected by the fact that this information has =20
> been sent by e-mail.
> Its erroneous transmission to a person other than the real named =20
> person neither implies any modification of this named person nor a =20
> renunciation of the eventual confidentiality or legal regime =20
> affecting the use of concerned message.
> Any views expressed in this message are binding exclusively upon =20
> the individual sender, except where the message states otherwise =20
> and the sender is authorised to bind this entity.
> If you receive this message in error, please delete it without =20
> transmitting it to any third party or keeping it in any form and =20
> notify us immediately either by phone (34 91 7095401) or using the =20
> e- mail address of the sender. Thank You.
>
> ----------------------------------------------------------------------=20=

> ---
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to =20
> share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?=20
> page=3Djoin.php&p=3Dsourceforge&CID=3DDEVDEV
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>

[Quickfix-developers] memory leak in quickfix 1.12.x

[Abel M. <am...@bo...>]

Hello,

I'd like to ask you about an issue, to see if someone has seen it too.
I check an executable using 1.12.2 with valgrind and I found some memory =

leaks in quickfix. This is the valgrind output:

 * When a session connects and send a log on message:
=3D=3D7480=3D=3D
=3D=3D7480=3D=3D Thread 3:
=3D=3D7480=3D=3D Conditional jump or move depends on uninitialised =
value(s)
=3D=3D7480=3D=3D    at 0x4174C6C: FIX::Session::nextLogon(FIX::Message =
const&)=20
(Session.cpp:204)
=3D=3D7480=3D=3D    by 0x418D7A1: FIX::Session::next(FIX::Message =
const&, bool)=20
(Session.cpp:1270)
=3D=3D7480=3D=3D    by 0x418C8D3: FIX::Session::next(std::string const&, =
bool)=20
(Session.cpp:1228)
=3D=3D7480=3D=3D    by 0x41CA1F1: =
FIX::ThreadedSocketConnection::processStream()=20
(ThreadedSocketConnection.cpp:156)
=3D=3D7480=3D=3D    by 0x41C9BB1: FIX::ThreadedSocketConnection::read()=20
(ThreadedSocketConnection.cpp:105)
=3D=3D7480=3D=3D    by 0x41C4C94:=20
FIX::ThreadedSocketAcceptor::socketConnectionThread(void*)=20
(ThreadedSocketAcceptor.cpp:252)
=3D=3D7480=3D=3D    by 0x4368DE7: start_thread (in =
/lib/tls/libpthread-0.60.so)
=3D=3D7480=3D=3D    by 0x4897939: clone (in /lib/tls/libc-2.3.2.so)

 * When a session disconnects:
=3D=3D7480=3D=3D
=3D=3D7480=3D=3D Conditional jump or move depends on uninitialised =
value(s)
=3D=3D7480=3D=3D    at 0x41C9EB7: FIX::ThreadedSocketConnection::read()=20
(ThreadedSocketConnection.cpp:110)
=3D=3D7480=3D=3D    by 0x41C4C94:=20
FIX::ThreadedSocketAcceptor::socketConnectionThread(void*)=20
(ThreadedSocketAcceptor.cpp:252)
=3D=3D7480=3D=3D    by 0x4368DE7: start_thread (in =
/lib/tls/libpthread-0.60.so)
=3D=3D7480=3D=3D    by 0x4897939: clone (in /lib/tls/libc-2.3.2.so)

* And we get this one too when application is starting:
=3D=3D7480=3D=3D Thread 4:
=3D=3D7480=3D=3D Syscall param socketcall.getsockopt(optlen) points to=20
uninitialised byte(s)
=3D=3D7480=3D=3D    at 0x4898452: getsockopt (in /lib/tls/libc-2.3.2.so)
=3D=3D7480=3D=3D    by 0x41C41C3:=20
FIX::ThreadedSocketAcceptor::socketAcceptorThread(void*)=20
(ThreadedSocketAcceptor.cpp:203)
=3D=3D7480=3D=3D    by 0x4368DE7: start_thread (in =
/lib/tls/libpthread-0.60.so)
=3D=3D7480=3D=3D    by 0x4897939: clone (in /lib/tls/libc-2.3.2.so)
=3D=3D7480=3D=3D  Address 0x7692870 is on thread 4's stack

Our application is using quickfix 1.12.2
        libquickfix.so.8 =3D>=20
/usr/local/quickfix-1.12.2/lib/libquickfix.so.8 (0x00111000)

The same executable using 1.10 doesn't have this memory leaks. Maybe we=20
should use last version, 1.12.4 to see if this is fixed?

Last question is about using ACE library and quickfix=20
(http://www.cs.wustl.edu/~schmidt/ACE.html)
In order to compile an application using the ACE library and quickfix=20
1.12.2, we had to
change some defines (just some change of names, eg. QUICKFIX_ALLOCATOR=20
instead ALLOCATOR in FieldMap.h), maybe it could
be added to the next version, in order to be able to compile with ACE=20
library without modify any files?
Someone else is using ACE and quickfix and has made this changes as =
well?

Thanks,
Abel

By the way, Merry Christmas :)


Oren Miller wrote:
> I would not recommend 1.12.3 over 1.12.4.  We just haven't yet added a =

> tag for 1.12.4.  What exists in the repository is newer than both=20
> those versions.  The warning isn't that troubling, what I'm wondering=20
> is if their is still a crash with the latest from svn.  Is there?
> If so can you put together a sample application and config that we=20
> could use to replicate it?  I put together a basic acceptor that uses=20
> the MySQLStore and was not able to duplicate the crash with the svn=20
> version.
>
> --oren
Oren, about the crash using 1.12.4, it happen as well using 1.12.2, we=20
are going to try out using last svn version. We see that it doesn't=20
happen always. Sometimes the application goes well, and some others we=20
have this crash.
>
> On Dec 13, 2006, at 5:08 AM, Abel Monroy wrote:
>
>> Hi all,
>>
>> I just check in svn, and there this code is just the same. The last=20
>> revision is 1641, Fri Jul 28 12:41:00 2006.
>>
>>
>> 92  char* getValue( int row, int column )
>> 93   {
>> 94          if( m_rows.empty() )
>> 95                {
>> 96                  MYSQL_ROW row =3D 0;
>> 97                  while( row =3D mysql_fetch_row( m_result ) )
>> 98                    m_rows.push_back(row);
>> 99                }
>> 100                return m_rows[row][column];
>> 101  }
>>
>> We just change line 97 by:
>>
>> while (( row =3D mysql_fetch_row( m_result ) ) !=3D 0)
>>
>> Our compiler is g++ (GCC) 3.2.3 20030502 (Red Hat Linux 3.2.3-52),=20
>> but we suppose that this warning would
>> raise with other versions.
>>
>> By the way, I saw in svn that the last version tagged is=20
>> release_1_12_3. We are just going to upgrade
>> our quickfix version in our production environment. I wonder if it=20
>> would be better to upgrade to 1.12.3,
>> or there are some critical bug that it's fixed in 1.12.4.
>>
>> Regards,
>> Abel Monroy
>>
>>
>> Oren Miller wrote:
>>> I believe this has been resolved in svn.  Could you try checking out =

>>> the latest and trying it out?
>>>
>>> --oren
>>>
>>> On Dec 12, 2006, at 5:11 AM, Abel Monroy wrote:
>>>
>>>> QuickFIX Documentation:=20
>>>> http://www.quickfixengine.org/quickfix/doc/html/index.html
>>>> QuickFIX Support: http://www.quickfixengine.org/services.html
>>>>
>>>> Hi everyone,
>>>>
>>>> we're upgrading our quickfix applications to last version, 1.12.4, =
and
>>>> we found some problems, so maybe someone could give us a hand.
>>>> Compiling the version, we've seen this warning:
>>>>
>>>> C++/MySQLConnection.h:98: warning: suggest parentheses around=20
>>>> assignment
>>>> used,   as truth value
>>>>
>>>> which is this line:
>>>> while ( row =3D mysql_fetch_row( m_result ) )
>>>>
>>>> We put the parentheses in order to avoid the warning, but now, we
>>>> compile the application and it crashs with a core.
>>>>
>>>> #0  0x00c7fcdf in raise () from /lib/tls/libc.so.6
>>>> #1  0x00c814e5 in abort () from /lib/tls/libc.so.6
>>>> #2  0x08061b6b in Unexpected () at src/vtfix.cpp:25
>>>> #3  0x00711567 in std::terminate () from /usr/lib/libstdc++.so.5
>>>> #4  0x007113f5 in __cxa_call_unexpected () from=20
>>>> /usr/lib/libstdc++.so.5
>>>> #5  0x00e7e928 in Session (this=3D0x96ec7e0, application=3D@0x0,
>>>> messageStoreFactory=3D@0x0, sessionID=3D@0x96f6198,=20
>>>> dataDictionary=3D@0x118a2f0,
>>>>     sessionTime=3D@0x118a290, pLogFactory=3D0x0) at Mutex.h:76
>>>> #6  0x00ea8067 in FIX::SessionFactory::create (this=3D0x118a560,
>>>> sessionID=3D@0x96b90a0, settings=3D@0x96e1474) at Field.h:308
>>>> #7  0x00eb9e23 in FIX::Acceptor::initialize (this=3D0x96cc3b0) at
>>>> stl_tree.h:199
>>>> #8  0x00eb98a0 in FIX::Acceptor::Acceptor$base () at=20
>>>> stl_function.h:197
>>>> #9  0x00ecf0fe in=20
>>>> FIX::ThreadedSocketAcceptor::ThreadedSocketAcceptor ()
>>>> at new:89
>>>>
>>>> It happens when we are making the new to a ThreadadSocketAcceptor=20
>>>> object.
>>>>
>>>>   _store_factory =3D new FIX::MySQLStoreFactory( *_settings );
>>>>   _log_factory =3D new FIX::MySQLLogFactory( *_settings );
>>>>
>>>>   try {
>>>>     _acceptor =3D new FIX::ThreadedSocketAcceptor (*_application,
>>>> *_store_factory,
>>>>                          *_settings, *_log_factory);
>>>>   }
>>>>
>>>> quickfix is compile with ./configure --with-mysql=3D/usr in order =
to=20
>>>> have
>>>> mysql support. It seems that we're missing something, but we are =
stuck
>>>> with this problem, so we'd appreciate your comments.
>>>>
>>>> Regards,
>>>> Abel Monroy Ferrero
>>>>
>>>>
>>>>
>>>>
>>>> ****************************** AVISO LEGAL=20
>>>> ******************************
>>>> La informaci=F3n contenida en este mensaje es para uso exclusivo de =

>>>> su destinatario. No debe copiarse, transmitirse a terceros ni=20
>>>> guardarse por estos =FAltimos, salvo autorizaci=F3n del remitente.
>>>> Puede contener informaci=F3n confidencial o legalmente protegida =
cuyo=20
>>>> r=E9gimen legal de utilizaci=F3n no se ve afectado por el hecho de =
que=20
>>>> haya sido enviada por correo electr=F3nico.
>>>> Su env=EDo por error a una persona distinta de su destinatario real =

>>>> no implica que se haya modificado tal destinatario ni supone=20
>>>> renuncia a su eventual car=E1cter confidencial o al r=E9gimen legal =
que=20
>>>> rija su utilizaci=F3n.
>>>> Cualquier opini=F3n expresada en este mensaje vincular=E1=20
>>>> exclusivamente a la persona que lo haya remitido, excepto cuando el =

>>>> mensaje establezca lo contrario y el remitente est=E9 autorizado =
para=20
>>>> establecer que dichas opiniones vincular=E1n a esta entidad.
>>>> En el supuesto de que este correo se recibiera por error, rogamos=20
>>>> procedan a borrarlo, sin reenviarlo a terceros ni conservarlo en=20
>>>> cualquier soporte y nos informen inmediatamente llamando al=20
>>>> tel=E9fono 34 91 7095401 o a la direcci=F3n de correo electr=F3nico =

>>>> remitente. Gracias.
>>>> ****************************** DISCLAIMER=20
>>>> ******************************
>>>> The information contained in this message is for the exclusive use=20
>>>> of the named person. It can not be copied, transmitted to third=20
>>>> parties or stored by the latter, except if authorised by the =
sender.
>>>> It may contain confidential or legally privileged information whose =

>>>> legal regime is not affected by the fact that this information has=20
>>>> been sent by e-mail.
>>>> Its erroneous transmission to a person other than the real named=20
>>>> person neither implies any modification of this named person nor a=20
>>>> renunciation of the eventual confidentiality or legal regime=20
>>>> affecting the use of concerned message.
>>>> Any views expressed in this message are binding exclusively upon=20
>>>> the individual sender, except where the message states otherwise=20
>>>> and the sender is authorised to bind this entity.
>>>> If you receive this message in error, please delete it without=20
>>>> transmitting it to any third party or keeping it in any form and=20
>>>> notify us immediately either by phone (34 91 7095401) or using the=20
>>>> e- mail address of the sender. Thank You.
>>>>
>>>> =
-------------------------------------------------------------------------=
=20
>>>>
>>>> Take Surveys. Earn Cash. Influence the Future of IT
>>>> Join SourceForge.net's Techsay panel and you'll get the chance to=20
>>>> share your
>>>> opinions on IT & business topics through brief surveys - and earn =
cash
>>>> =
http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D=
DEVDEV=20
>>>>
>>>> _______________________________________________
>>>> Quickfix-developers mailing list
>>>> Qui...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>>>>
>>>
>>>
>>
>>
>>
>> ****************************** AVISO LEGAL=20
>> ******************************
>> La informaci=F3n contenida en este mensaje es para uso exclusivo de =
su=20
>> destinatario. No debe copiarse, transmitirse a terceros ni guardarse=20
>> por estos =FAltimos, salvo autorizaci=F3n del remitente.
>> Puede contener informaci=F3n confidencial o legalmente protegida cuyo =

>> r=E9gimen legal de utilizaci=F3n no se ve afectado por el hecho de =
que=20
>> haya sido enviada por correo electr=F3nico.
>> Su env=EDo por error a una persona distinta de su destinatario real =
no=20
>> implica que se haya modificado tal destinatario ni supone renuncia a=20
>> su eventual car=E1cter confidencial o al r=E9gimen legal que rija su=20
>> utilizaci=F3n.
>> Cualquier opini=F3n expresada en este mensaje vincular=E1 =
exclusivamente=20
>> a la persona que lo haya remitido, excepto cuando el mensaje=20
>> establezca lo contrario y el remitente est=E9 autorizado para=20
>> establecer que dichas opiniones vincular=E1n a esta entidad.
>> En el supuesto de que este correo se recibiera por error, rogamos=20
>> procedan a borrarlo, sin reenviarlo a terceros ni conservarlo en=20
>> cualquier soporte y nos informen inmediatamente llamando al =
tel=E9fono=20
>> 34 91 7095401 o a la direcci=F3n de correo electr=F3nico remitente. =
Gracias.
>> ****************************** DISCLAIMER =
******************************
>> The information contained in this message is for the exclusive use of =

>> the named person. It can not be copied, transmitted to third parties=20
>> or stored by the latter, except if authorised by the sender.
>> It may contain confidential or legally privileged information whose=20
>> legal regime is not affected by the fact that this information has=20
>> been sent by e-mail. Its erroneous transmission to a person other=20
>> than the real named person neither implies any modification of this=20
>> named person nor a renunciation of the eventual confidentiality or=20
>> legal regime affecting the use of concerned message.
>> Any views expressed in this message are binding exclusively upon the=20
>> individual sender, except where the message states otherwise and the=20
>> sender is authorised to bind this entity. If you receive this message =

>> in error, please delete it without transmitting it to any third party =

>> or keeping it in any form and notify us immediately either by phone=20
>> (34 91 7095401) or using the e- mail address of the sender. Thank =
You.
>>
>
>



****************************** AVISO LEGAL =
******************************
La informaci=F3n contenida en este mensaje es para uso exclusivo de su =
destinatario. No debe copiarse, transmitirse a terceros ni guardarse por =
estos =FAltimos, salvo autorizaci=F3n del remitente.
Puede contener informaci=F3n confidencial o legalmente protegida cuyo =
r=E9gimen legal de utilizaci=F3n no se ve afectado por el hecho de que =
haya sido enviada por correo electr=F3nico.
Su env=EDo por error a una persona distinta de su destinatario real no =
implica que se haya modificado tal destinatario ni supone renuncia a su =
eventual car=E1cter confidencial o al r=E9gimen legal que rija su =
utilizaci=F3n.
Cualquier opini=F3n expresada en este mensaje vincular=E1 exclusivamente =
a la persona que lo haya remitido, excepto cuando el mensaje establezca =
lo contrario y el remitente est=E9 autorizado para establecer que dichas =
opiniones vincular=E1n a esta entidad.
En el supuesto de que este correo se recibiera por error, rogamos =
procedan a borrarlo, sin reenviarlo a terceros ni conservarlo en =
cualquier soporte y nos informen inmediatamente llamando al tel=E9fono =
34 91 7095401 o a la direcci=F3n de correo electr=F3nico remitente. =
Gracias.
****************************** DISCLAIMER ******************************
The information contained in this message is for the exclusive use of =
the named person. It can not be copied, transmitted to third parties or =
stored by the latter, except if authorised by the sender.
It may contain confidential or legally privileged information whose =
legal regime is not affected by the fact that this information has been =
sent by e-mail.=20
Its erroneous transmission to a person other than the real named person =
neither implies any modification of this named person nor a renunciation =
of the eventual confidentiality or legal regime affecting the use of =
concerned message.
Any views expressed in this message are binding exclusively upon the =
individual sender, except where the message states otherwise and the =
sender is authorised to bind this entity.=20
If you receive this message in error, please delete it without =
transmitting it to any third party or keeping it in any form and notify =
us immediately either by phone (34 91 7095401) or using the e- mail =
address of the sender. Thank You.

[Quickfix-developers] Pending Connections..

[Mark R. <mr...@pr...>]

QF Version: 1.12.1

Platform: Windows

=20

Hi all,

=20

I am having a problem with pending connections on an initiator... if a
connection is dropped or lost then it is marked as disconnected and at
some point in the future, it is marked as "Pending" and an attempt is
made to kick off a reconnection attempt.  However, what I am seeing is
that if that attempt fails, it stays as pending and it is never set as
disconnected again meaning that it never tries again...  The
onDisconnect() function of Socketinitiator doesn't seem to get called
ever again!  I would have thought that after [LogonTimeout] seconds, the
connection would be marked as disconnected again ready for another
retry.

=20

Have I missed something here or is this a genuine problem?

=20

Regards,

Mark