quickfix-developers — QuickFIX developers forum

[Quickfix-developers] [qfj] Hexdumps under Netty2 1.8.0, move to MINA?

[Chuck C. <chu...@gm...>]

Hello All,

I've been experiencing some performance issues using quickfixj (the
latest CVS checkout) and am curious how I should proceed.  

Typically, in my development code, sooner or later the acceptor side
produces buffer underflows originating in the netty library (tl-
netty2-1.8.0.jar) (I'm experiencing essentially the same hexdumps Barry
Kaplan was experiencing a few months back).

Barry, I noticed you had issues with netty 1.9.2, and I also noticed
some of your posts over in the MINA forum.  Should I follow in your
footsteps and move over to MINA (if this is what you did)?  Do you plan
on committing any of your changes?  More importantly, did you experience
improvements in performance?  

I'm not terribly familiar with Netty (nor the changes that went into
MINA), so I may be completely off-base.  Before pursuing this
(potentially long, dark) avenue, I'd love to hear anyone's advice.

I suppose this email is mostly directed at Barry (or Steve Bate), but I
figure everyone might benefit.  Thanks a ton!


Chuck

-------------------
Dual Athlon 1.2 GHz 
1 GB RAM
Fedora Core 3
Java 1.5

Re: [Quickfix-developers] help me

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

On 11/15/05, kishorekumar vutukuri <kis...@ya...> wrote:
>
> i am very new to quickfix protocol.how to write an
> application for initiator and acceptor.pls help me if
> possible provide the sample code.



There are several example applications in the QuickFIX distribution. Have
you looked at them?


--
Caleb Epstein
caleb dot epstein at gmail dot com

[Quickfix-developers] help me

[kishorekumar v. <kis...@ya...>]

hello,

i am very new to quickfix protocol.how to write an
application for initiator and acceptor.pls help me if
possible provide the sample code.

Thanks&Regards
kishore


	
		
__________________________________ 
Yahoo! Mail - PC Magazine Editors' Choice 2005 
http://mail.yahoo.com

RE: [Quickfix-developers] Quickfix/J: AbstractSocketInitiator issues

[Brad H. <Bra...@gb...>]

Hi Toby,

The issue with quickfixSessions never being populated is Bug #106 -
http://www.quickfixengine.org/bugtracker/bug.php?op=3Dshow&bugid=3D106&po=
s=3D2
.  As a workaround you can try something like this to get all the
sessions:

		Map sessions =3D new HashMap();
            // sessionSettings is the SessionSettings used to create the
initiator.
		for (Iterator iter =3D sessionSettings.sectionIterator();
iter.hasNext();) {
			SessionID sessionId =3D (SessionID) iter.next();
			Session session =3D
Session.lookupSession(sessionId);
			if (session !=3D null) {
				sessions.put(sessionId, session);
			}
		}

You can then check the status of each session.

I've actually run into a different issue with the initiator.  It doesn't
seem to logon properly after a failed connection attempt.  Reproducing
is fairly simple with Banzai and Order Matcher:

1. Start Banzai

It gets a connection refused and periodically retries the connection as
expected.

2. Start Order Matcher

Banzai then logs this:
<20051113-03:56:49, FIX.4.2:BANZAI->EXEC, event> (connection
established: net.gleamynode.netty2.Session@afae4a)

So it connects, but it doesn't seem to send a logon, and the order
matcher logs nothing.  The session doesn't show up in Banzai's drop down
list of sessions.

If I then restart Banzai it connects properly.=20

Regards,
Brad.
=20

-----Original Message-----
From: qui...@li...
[mailto:qui...@li...] On Behalf Of
Shepheard, Toby (London)
Sent: Friday, 11 November 2005 12:42 AM
To: qui...@li...
Subject: [Quickfix-developers] Quickfix/J: AbstractSocketInitiator
issues

QuickFIX Documentation:
http://www.quickfixengine.org/quickfix/doc/html/index.html
QuickFIX Support: http://www.quickfixengine.org/services.html

I'm using the latest version of Quickfix/J from CVS. I've just been
switching my applications from an Acceptor to an Initiator and came
across an issue with the Initiator code.

The isLoggedOn and getSessions methods both use the quickfixSessions
HashMap object. However, this HashMap is never populated - the
AbstractSocketAcceptor populates it's version in the initialize method
(first checking that the connectionType is an acceptor), but the
AbstractSocketInitiator never does. As a result isLoggedOn will always
return false, getSesssions an empty list, and there's no public way to
get the current session status from the socket initiator.

Is there some other way I can check to see the current login status from
the SocketInitiator object (e.g. loginSent, loginReceived etc) for any
active session? Should the quickfixSessions hashmap even exist in an
Initiator, or should there be a single Session object which should be
made avaialble via an accessor method? Or am I abusing all of this in
some way and should I take a different approach? :)

Many thanks,
Toby
--------------------------------------------------------

If you are not an intended recipient of this e-mail, please notify the
sender, delete it and do not read, act upon, print, disclose, copy,
retain or redistribute it. Click here for important additional terms
relating to this e-mail.     http://www.ml.com/email_terms/
--------------------------------------------------------


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server.
Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Quickfix-developers mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfix-developers

[Quickfix-developers] RE: Header tag in message area

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

Sorry, I must apologize for this incorrect assertion, the code quoted is in=
correct.
I used message.setField() and not message.getHeader().setField()
=20
The CME Certification Server did not check for header placing and allowed l=
ogin while testing start and mid-week logons and checked for header placing=
 during logons for testing Order Management!=20
=20
Sorry for using your time.
=20
Thanks.
=20
Anil
=20
=20

-----Original Message-----
From: Jain, Anil=20
Sent: Friday, November 11, 2005 1:02 PM
To: qui...@li...
Subject: Header tag in message area


Hi,
=20
I'll appreciate if someone has some resolution to this problem.
I'm getting an error during my certification tests thus:
TagOrder Error:=20
Tag 142(SenderLocationID) does not appear in the expected order. Expected t=
o appear in the 'header'=20

Fix Message:=20
BeginString(8)=3DFIX.4.2|BodyLength(9)=3D129|MsgType(35)=3DA|MsgSeqNum(34)=
=3D78|SenderCompID(49)=3DC00000N|SendingTime(52)=3D20051111-17:45:15.500|Ta=
rgetCompID(56)=3DCCC|SenderSubID(50)=3DC00000N|TargetSubID(57)=3DG|RawDataL=
ength(95)=3D6|RawData(96)=3Dxxxxxx|EncryptMethod(98)=3D0|HeartBtInt(108)=3D=
30|SenderLocationID(142)=3DC00000N|LastMsgSeqNumProcessed(369)=3D81|LoginRo=
uteID(9716)=3DC00000N|CheckSum(10)=3D100|=20


Although, in my application, this is what I do:
fix_order->getHeader().set(FIX::SenderLocationID ("C00000N"));=20
=20
How can I force the header tag within header region?
=20
I find QuickFix a wonderful product. Thanks to Oren and all those who contr=
ibute to it's development and support.
=20
Anil
=20

_______________________________________________________________________

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.

[Quickfix-developers] Header tag in message area

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

Hi,
=20
I'll appreciate if someone has some resolution to this problem.
I'm getting an error during my certification tests thus:
TagOrder Error:=20
Tag 142(SenderLocationID) does not appear in the expected order. Expected t=
o appear in the 'header'=20

Fix Message:=20
BeginString(8)=3DFIX.4.2|BodyLength(9)=3D129|MsgType(35)=3DA|MsgSeqNum(34)=
=3D78|SenderCompID(49)=3DC00000N|SendingTime(52)=3D20051111-17:45:15.500|Ta=
rgetCompID(56)=3DCCC|SenderSubID(50)=3DC00000N|TargetSubID(57)=3DG|RawDataL=
ength(95)=3D6|RawData(96)=3Dxxxxxx|EncryptMethod(98)=3D0|HeartBtInt(108)=3D=
30|SenderLocationID(142)=3DC00000N|LastMsgSeqNumProcessed(369)=3D81|LoginRo=
uteID(9716)=3DC00000N|CheckSum(10)=3D100|=20

Although, in my application, this is what I do:
fix_order->getHeader().set(FIX::SenderLocationID ("C00000N"));=20
=20
How can I force the header tag within header region?
=20
I find QuickFix a wonderful product. Thanks to Oren and all those who contr=
ibute to it's development and support.
=20
Anil
=20
_______________________________________________________________________

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.

[Quickfix-developers] Quickfix/J: AbstractSocketInitiator issues

[Shepheard, T. (London) <Tob...@ml...>]

I'm using the latest version of Quickfix/J from CVS. I've just been
switching my applications from an Acceptor to an Initiator and came
across an issue with the Initiator code.

The isLoggedOn and getSessions methods both use the quickfixSessions
HashMap object. However, this HashMap is never populated - the
AbstractSocketAcceptor populates it's version in the initialize method
(first checking that the connectionType is an acceptor), but the
AbstractSocketInitiator never does. As a result isLoggedOn will always
return false, getSesssions an empty list, and there's no public way to
get the current session status from the socket initiator.

Is there some other way I can check to see the current login status from
the SocketInitiator object (e.g. loginSent, loginReceived etc) for any
active session? Should the quickfixSessions hashmap even exist in an
Initiator, or should there be a single Session object which should be
made avaialble via an accessor method? Or am I abusing all of this in
some way and should I take a different approach? :)

Many thanks,
Toby
--------------------------------------------------------

If you are not an intended recipient of this e-mail, please notify the =
sender, delete it and do not read, act upon, print, disclose, copy, =
retain or redistribute it. Click here for important additional terms =
relating to this e-mail.     http://www.ml.com/email_terms/
--------------------------------------------------------

[Quickfix-developers] FAST - FIX Adapted For STreaming

[Daniel M. <da...@sp...>]

For those of you interested in FIX and the recent work being by the
Market Data Optimization Group (MDOWG), there will be a presentation in
Chicago at the FIA show on Thursday, November 10th.  The topic will be
FAST - FIX Adapted For Streaming
=20
The Link below will give you the details:
http://www.futuresindustry.org/expo2005-2576.asp?t=3D2005+Futures+%26+Opt=
i
ons+Expo&i=3D817&r=3DTwo
=20
=20
If you are interested in learning more about FAST and how it may impact
your future use of FIX:
http://www.fixprotocol.org/documents/1785/Initial%20Proof%20of%20Concept
%20Successful%20in%20Optimizing%20FIX%20for%20Streaming%20Market%20Data.
pdf
http://www.fixprotocol.org/documents/1780/POC%20Results_Phase1A.pdf
=20
=20
Daniel May
da...@sp...
www.spryware.com
=20
=20
=20
=20

RE: [Quickfix-developers] onMessage callback

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

Messages get delegated to the MessageCracker by calling the crack
method.  You generally make this call from the fromApp method.  fromApp
gives you a generic message type.  While you can do everything you need
with this class, the cracker will cast the message to a more specific
type.  This gives your messages type safety and provides and
alternative to using switch statements to segment your logic.

--oren

> -------- Original Message --------
> Subject: RE: [Quickfix-developers] onMessage callback
> From: Shankar Krishnan <skr...@jw...>
> Date: Tue, November 08, 2005 2:44 pm
> To: qui...@li...
> Cc: Shankar Krishnan <skr...@jw...>
> 
>         
>  Thanks,   I looked at the "executor" example program. If I understand correctly, then fromApp is the entry point into FIX client application, how do messages get delegated to Messagecracker and hence onMessage, Is this part of the quickfix design ?       
>  
>    From: Caleb Epstein [mailto:cal...@gm...] 
>  Sent: Tuesday, November 08, 2005 2:48 PM
>  To: Shankar Krishnan
>  Cc: qui...@li...
>  Subject: Re: [Quickfix-developers] onMessage callback      
>  On 11/8/05, Shankar Krishnan <skr...@jw...> wrote: 
>  
> 
> I only see references to onCreate,onLogon,onLogout,toAdmin etc in the documentation. 
> 
> However I see donot see any reference to onMessage. If we have fromApp which is what 
> 
> I should care about, what does onMessage do. I did look up the documentation, but see 
> 
> Any flow diagrams what will tell me how the message flows to and from the FIX engine.  
>  The onMessage callbacks live in the version-specific FIXxx::MessageCracker classes.  Take a look at the "executor" example program for sample usage.    
>  -- 
>  Caleb Epstein
>  caleb dot epstein at gmail dot com     

RE: [Quickfix-developers] onMessage callback

[Shankar K. <skr...@jw...>]

Thanks,

 

I looked at the "executor" example program. If I understand correctly, then
fromApp is the entry point into

FIX client application, how do messages get delegated to Messagecracker and
hence onMessage,

Is this part of the quickfix design ?

 

 

 

  _____  

From: Caleb Epstein [mailto:cal...@gm...] 
Sent: Tuesday, November 08, 2005 2:48 PM
To: Shankar Krishnan
Cc: qui...@li...
Subject: Re: [Quickfix-developers] onMessage callback

 

 

On 11/8/05, Shankar Krishnan <skr...@jw... <mailto:skr...@jw...> >
wrote:

I only see references to onCreate,onLogon,onLogout,toAdmin etc in the
documentation.

However I see donot see any reference to onMessage. If we have fromApp which
is what

I should care about, what does onMessage do. I did look up the
documentation, but see

Any flow diagrams what will tell me how the message flows to and from the
FIX engine.

The onMessage callbacks live in the version-specific FIXxx::MessageCracker
classes.  Take a look at the "executor" example program for sample usage. 


-- 
Caleb Epstein
caleb dot epstein at gmail dot com 

Re: [Quickfix-developers] onMessage callback

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

On 11/8/05, Shankar Krishnan <skr...@jw...> wrote:
>
>  I only see references to onCreate,onLogon,onLogout,toAdmin etc in the
> documentation.
>
> However I see donot see any reference to onMessage. If we have fromApp
> which is what
>
> I should care about, what does onMessage do. I did look up the
> documentation, but see
>
> Any flow diagrams what will tell me how the message flows to and from the
> FIX engine.
>
The onMessage callbacks live in the version-specific FIXxx::MessageCracker
classes. Take a look at the "executor" example program for sample usage.

--
Caleb Epstein
caleb dot epstein at gmail dot com

[Quickfix-developers] onMessage callback

[Shankar K. <skr...@jw...>]

 

I only see references to onCreate,onLogon,onLogout,toAdmin etc in the
documentation.

However I see donot see any reference to onMessage. If we have fromApp which
is what

I should care about, what does onMessage do. I did look up the
documentation, but see

Any flow diagrams what will tell me how the message flows to and from the
FIX engine.

 

Thanks

 

[Quickfix-developers] Session.isEnabled()

[Alvin W. <AW...@FF...>]

Hi When will Session.isEnabled() return false? 
Thanks
Alvin
                                                                                                                                                                                                                                                                                                    **********************************************************************
This e-mail message is intended solely for the use of the addressee.
The message may contain information that is privileged and confidential.  
Disclosure to anyone other than the intended recipient is
prohibited. If you are not the intended recipient, please do not
disseminate, distribute or copy this communication, by e-mail or
otherwise. Instead, please notify us immediately by return e-mail
(including the original message with your reply) and then delete
and discard all copies of the message. We have taken precautions to
minimize the risk of transmitting software viruses but nevertheless
advise you to carry out your own virus checks on any attachment to
this message.  We accept no liability for any loss or damage caused
by software viruses.
**********************************************************************

Re: [Quickfix-developers] Re: ThreadedSocketAcceptor Segmentation Faults

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

Actually, it looks to me like some fixes that were applied to the =
initiator have not been applied to the acceptor.  For instance, in the =
initiator the spawned thread adds and removes itself, while in the =
acceptor this is done by different threads which are not properly =
synchronized.

--oren
  ----- Original Message -----=20
  From: Caleb Epstein=20
  To: Alberto Bellido Rodr=EDguez=20
  Cc: qui...@li...=20
  Sent: Tuesday, November 08, 2005 7:13 AM
  Subject: Re: [Quickfix-developers] Re: ThreadedSocketAcceptor =
Segmentation Faults




  On 11/8/05, Alberto Bellido Rodr=EDguez <bellido@3.14financial.com> =
wrote:


    #0  0x4048318c in pthread_detach () from /lib/tls/libpthread.so.0
    #1  0x400d5edc in FIX::thread_detach (thread=3D0) at Utility.cpp:344
    #2  0x4009323f in FIX::ThreadedSocketAcceptor::removeThread
    (this=3D0xbffff500, s=3D57) at stl_map.h:332=20
    #3  0x40093335 in FIX::ThreadedSocketAcceptor::socketThread =
(p=3D0x3) at
    ThreadedSocketConnection.h:51
    #4  0x40482b3c in start_thread () from /lib/tls/libpthread.so.0
    #5  0x4032092a in clone () from /lib/tls/libc.so.6=20

  I really think this call should be changed to a thread_join, at least =
on UNIX systems.  Detaching a running thread seems like playing Russion =
Roulette to me.


  --=20
  Caleb Epstein
  caleb dot epstein at gmail dot com 

Re: [Quickfix-developers] Re: ThreadedSocketAcceptor Segmentation Faults

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

Well, my understanding of detach is not that it actually stops a running =
thread, but that it guarantees the resources of that thread will be =
release immiediately when the thread stops running on its own.  It =
essentially is an alternative to join when there isn't a need to =
synchronize with another thread.

Why 0 is being passed to this function is most interesting to me.  My =
best guess right now is that somehow removeThread is being called before =
addThread.  I think perhaps locking the mutex that guards m_threads =
before spawning the thread would do the trick.

--oren
  ----- Original Message -----=20
  From: Caleb Epstein=20
  To: Alberto Bellido Rodr=EDguez=20
  Cc: qui...@li...=20
  Sent: Tuesday, November 08, 2005 7:13 AM
  Subject: Re: [Quickfix-developers] Re: ThreadedSocketAcceptor =
Segmentation Faults




  On 11/8/05, Alberto Bellido Rodr=EDguez <bellido@3.14financial.com> =
wrote:


    #0  0x4048318c in pthread_detach () from /lib/tls/libpthread.so.0
    #1  0x400d5edc in FIX::thread_detach (thread=3D0) at Utility.cpp:344
    #2  0x4009323f in FIX::ThreadedSocketAcceptor::removeThread
    (this=3D0xbffff500, s=3D57) at stl_map.h:332=20
    #3  0x40093335 in FIX::ThreadedSocketAcceptor::socketThread =
(p=3D0x3) at
    ThreadedSocketConnection.h:51
    #4  0x40482b3c in start_thread () from /lib/tls/libpthread.so.0
    #5  0x4032092a in clone () from /lib/tls/libc.so.6=20

  I really think this call should be changed to a thread_join, at least =
on UNIX systems.  Detaching a running thread seems like playing Russion =
Roulette to me.


  --=20
  Caleb Epstein
  caleb dot epstein at gmail dot com 

AW: [Quickfix-developers] Re: ThreadedSocketAcceptor Segmentation Faults

[Bill R. Hr. <bil...@ra...>]

The strange behaviour ... you aren't alone, we experience on our test =
system
(SUSE Linux, MySQL, gcc 3.4.3) the same (random) failure. Only your =
analysis
of the problem is much better than ours!
=20
Thanks and regards,
Robert


-----Urspr=FCngliche Nachricht-----
Von: Guillermo Arbeiza Alameda [mailto:gar...@vi...]=20
Gesendet: Dienstag, 8. November 2005 15:04
An: 'Caleb Epstein'; 'Alberto Bellido Rodr=EDguez'
Cc: qui...@li...
Betreff: RE: [Quickfix-developers] Re: ThreadedSocketAcceptor =
Segmentation
Faults


Also note that the thread that FIX::thread_detach() receives is 0. I =
think
that's the segfault cause. Also i think the threads are joined =
previously,
when Acceptor::stop is called. The threads are detached when the
Socket->Read() loop ends and so the thread does.=20
=20
If this strange behaviour is happening only to Alberto and me we really
should start looking at dependencies and installed libraries to =
determine
where the incompatibility may lay on.
=20
Cheers for your work,=20
=20
Guillermo

-----Mensaje original-----
De: qui...@li...
[mailto:qui...@li...]En nombre de =
Caleb
Epstein
Enviado el: martes, 08 de noviembre de 2005 14:13
Para: Alberto Bellido Rodr=EDguez
CC: qui...@li...
Asunto: Re: [Quickfix-developers] Re: ThreadedSocketAcceptor =
Segmentation
Faults



On 11/8/05, Alberto Bellido Rodr=EDguez <bellido@3.14financial.com
<mailto:bellido@3.14financial.com> > wrote:



#0  0x4048318c in pthread_detach () from /lib/tls/libpthread.so.0
#1  0x400d5edc in FIX::thread_detach (thread=3D0) at Utility.cpp:344
#2  0x4009323f in FIX::ThreadedSocketAcceptor::removeThread
(this=3D0xbffff500, s=3D57) at stl_map.h:332=20
#3  0x40093335 in FIX::ThreadedSocketAcceptor::socketThread (p=3D0x3) =
at
ThreadedSocketConnection.h:51
#4  0x40482b3c in start_thread () from /lib/tls/libpthread.so.0
#5  0x4032092a in clone () from /lib/tls/libc.so.6=20


I really think this call should be changed to a thread_join, at least =
on
UNIX systems.  Detaching a running thread seems like playing Russion
Roulette to me.


--=20
Caleb Epstein
caleb dot epstein at gmail dot com=20






****************************** 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 5892123 o a la
direcci=F3n de correo electr=F3nico remitente. Gracias.=20






****************************** 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.
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 5892123) or using the e- mail address of the =
sender.
Thank You.=20

RE: [Quickfix-developers] Re: ThreadedSocketAcceptor Segmentation Faults

[Guillermo A. A. <gar...@vi...>]

Also note that the thread that FIX::thread_detach() receives is 0. I =
think
that's the segfault cause. Also i think the threads are joined =
previously,
when Acceptor::stop is called. The threads are detached when the
Socket->Read() loop ends and so the thread does.

If this strange behaviour is happening only to Alberto and me we really
should start looking at dependencies and installed libraries to =
determine
where the incompatibility may lay on.

Cheers for your work,

Guillermo
  -----Mensaje original-----
  De: qui...@li...
[mailto:qui...@li...]En nombre de =
Caleb
Epstein
  Enviado el: martes, 08 de noviembre de 2005 14:13
  Para: Alberto Bellido Rodr=EDguez
  CC: qui...@li...
  Asunto: Re: [Quickfix-developers] Re: ThreadedSocketAcceptor =
Segmentation
Faults




  On 11/8/05, Alberto Bellido Rodr=EDguez <bellido@3.14financial.com> =
wrote:


    #0  0x4048318c in pthread_detach () from /lib/tls/libpthread.so.0
    #1  0x400d5edc in FIX::thread_detach (thread=3D0) at Utility.cpp:344
    #2  0x4009323f in FIX::ThreadedSocketAcceptor::removeThread
    (this=3D0xbffff500, s=3D57) at stl_map.h:332
    #3  0x40093335 in FIX::ThreadedSocketAcceptor::socketThread =
(p=3D0x3) at
    ThreadedSocketConnection.h:51
    #4  0x40482b3c in start_thread () from /lib/tls/libpthread.so.0
    #5  0x4032092a in clone () from /lib/tls/libc.so.6

  I really think this call should be changed to a thread_join, at least =
on
UNIX systems.  Detaching a running thread seems like playing Russion
Roulette to me.


  --
  Caleb Epstein
  caleb dot epstein at gmail dot com


****************************** 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 5892123 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 5892123) or using the e- mail =
address of the sender. Thank You.

Re: [Quickfix-developers] Re: ThreadedSocketAcceptor Segmentation Faults

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

On 11/8/05, Alberto Bellido Rodr=EDguez <bellido@3.14financial.com> wrote:

#0 0x4048318c in pthread_detach () from /lib/tls/libpthread.so.0
> #1 0x400d5edc in FIX::thread_detach (thread=3D0) at Utility.cpp:344
> #2 0x4009323f in FIX::ThreadedSocketAcceptor::removeThread
> (this=3D0xbffff500, s=3D57) at stl_map.h:332
> #3 0x40093335 in FIX::ThreadedSocketAcceptor::socketThread (p=3D0x3) at
> ThreadedSocketConnection.h:51
> #4 0x40482b3c in start_thread () from /lib/tls/libpthread.so.0
> #5 0x4032092a in clone () from /lib/tls/libc.so.6


I really think this call should be changed to a thread_join, at least on
UNIX systems. Detaching a running thread seems like playing Russion Roulett=
e
to me.

--
Caleb Epstein
caleb dot epstein at gmail dot com

[Quickfix-developers] Re: ThreadedSocketAcceptor Segmentation Faults

[Alberto B. <bellido@3.14financial.com>]

Hi

We're getting the same error on some testings.

#0  0x4048318c in pthread_detach () from /lib/tls/libpthread.so.0
#1  0x400d5edc in FIX::thread_detach (thread=0) at Utility.cpp:344
#2  0x4009323f in FIX::ThreadedSocketAcceptor::removeThread
(this=0xbffff500, s=57) at stl_map.h:332
#3  0x40093335 in FIX::ThreadedSocketAcceptor::socketThread (p=0x3) at
ThreadedSocketConnection.h:51
#4  0x40482b3c in start_thread () from /lib/tls/libpthread.so.0
#5  0x4032092a in clone () from /lib/tls/libc.so.6

We're running Mandrake Linux 10.1, Quickfix 1.10.2. As you said, there's
no way to find a pattern to reproduce it.

Have you find any clue?

Thanks 

Alberto





Since I upgraded to Quickfix 1.10.2 (prior we were using 1.9.4) i'm
getting
a random segmentation fault when sessions log off. I couldn't find a pattern
to reproduce it, or even a "more probable" scenario, it just happens from
time to time.

Before entering a bug report, i'd like to know if someone has faced this (or
similar) problem, or if someone thinks the problem is on my side.

All the dumped cores from this segmentation fault read the same:

#0  0x00cb8b60 in pthread_detach () from /lib/tls/libpthread.so.0
#1  0x00870b97 in FIX::thread_detach (thread=0) at Utility.cpp:344
#2  0x0081d4c8 in FIX::ThreadedSocketAcceptor::removeThread (this=0x8f596c8,
    s=19) at stl_map.h:221
#3  0x0081d5e7 in FIX::ThreadedSocketAcceptor::socketThread (p=0xf6a8a10)
    at ThreadedSocketConnection.h:51
#4  0x00cb7dec in start_thread () from /lib/tls/libpthread.so.0
#5  0x006f0a2a in clone () from /lib/tls/libc.so.6

At Level #2, the Acceptor member m_threads shows a suspicious "_M_node_count
= 0" which can lead to the thread=0 passed to thread_detach and causes the
segfault

I'm not sure if faulty code on my side can lead to that errors, but i've
found that problem in all my developments using a ThreadAcceptor, ranging
from a single FIX logger to a monstrous routing system.

I'm compiling QFix with mysql support (MySQL ver 4.14) on RedHat Enterprise
3 servers.
Some system libs:
glibc-devel-2.3.2.-95.3x (pthreads)
libstdc++-devel-3.2.3-52 (stl)

Thanks in advance and cheers (again) for your great work

Guillermo

Re: [Quickfix-developers] updating the memory and file <name.seqnums> with the currently expected sequence number programaticaly

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

If you want to change the sequence numbers in realtime, you will need to =
use Session::setNextSenderMsgSeqNum and Session::setNextTargetMsgSeqNum. =
 They will update the seqnums file when called.

--oren
  ----- Original Message -----=20
  From: arvkm=20
  To: qui...@li...=20
  Sent: Monday, November 07, 2005 11:09 AM
  Subject: [Quickfix-developers] updating the memory and file =
<name.seqnums> with the currently expected sequence number =
programaticaly


  Hi,

  I am facing problem that, I oftenly need to change the expected =
sequence number in the .seqnums file under the \seq directory manualy =
(after looking into the log file for expected sequence number).

  Does anyone know writing the file <name.seqnums> with the currently =
expected sequence number and also updating the memory without logging =
off and without being disconnected.

  Thanks in Advance,

  Regards,

  Arvind Maharana=20






-------------------------------------------------------------------------=
-----
  Indiatimes Email now powered by APIC Advantage. Help!=20

  Help

-------------------------------------------------------------------------=
-----

[Quickfix-developers] updating the memory and file <name.seqnums> with the currently expected sequence number programaticaly

[arvkm <ar...@in...>]

Hi,


I am facing problem that, I oftenly need to change the expected sequence number in the .seqnums file under the \seq directory manualy (after looking into the log file for expected sequence number).


Does anyone know writing the file <name.seqnums> with the currently expected sequence number and also updating the memory without logging off and without being disconnected.


Thanks in Advance,


Regards,


Arvind Maharana 


 


 Indiatimes Email now powered by APIC Advantage. Help! 
Help

[Quickfix-developers] Sample ordermatcher application automatically fills all the incoming orders

[Toli K. <tku...@de...>]

Hey,=20

Seems that the sample ordermatcher application is setup to fill all
incoming orders immediately.=20

In quickfix.examples.ordermatch.Application.acceptOrder() on line 131
you have this:
private void acceptOrder(Order order) {
  updateOrder(order, OrdStatus.FILLED);
}

So it fills all the orders automatically.=20

Changing this to OrdStatus.NEW fixes the problem and the ordermatcher
still works.

Hopefully someone can fix that in CVS.

Re: [Quickfix-developers] Re: monitor the FIX connection failure programmatically?

[Alvin W. <AW...@FF...>]

The Session::isSessionTime() is not available in QF Java!! :(
Workaround?






"Oren Miller" <or...@qu...>
11/04/2005 02:53 PM

 
        To:     "Caleb Epstein" <cal...@gm...>, "Alvin Wang" <AW...@FF...>
        cc:     <qui...@li...>, 
<qui...@li...>
        bcc: 
        Subject:        Re: [Quickfix-developers] Re: monitor the FIX connection failure 
programmatically?


You can use Session::isSessionTime() to determine if you are within the 
start and end times.  The hearbeat interval has nothing to do with when 
the session disconnects.
 
--oren
----- Original Message ----- 
From: Alvin Wang 
To: Caleb Epstein 
Cc: Oren Miller ; qui...@li... ; qui...@li... 
Sent: Friday, November 04, 2005 1:48 PM
Subject: Re: [Quickfix-developers] Re: monitor the FIX connection failure 
programmatically?


Caleb, we want to differentiate the normal logout/disconnect at the end of 
day, and the abnormal logout/disconnect during the session. (is it safe to 
assume that onLogout will not be called between Endtime and StartTime?) So 
my question is, can we use isLoggedOn method inside onLogout to make above judgement? If isLoggedOn=true, it is abnormal. 

Or, what is the algorithm to decide exact when the initiator will 
disconnect at (around) the EndTime? For example, the EndTime is 22:00:00 
and heartbeat interval is 30 seconds. Now the initiator sends a heartbeat 
at 21:59:10.  will the initiator disconnect at 21:59:40 or 22:00:10? 

Many thanks 
Alvin 





Caleb Epstein <cal...@gm...> 
Sent by: qui...@li... 
11/04/2005 10:35 AM 
        
        To:        Alvin Wang <AW...@ff...> 
        cc:        Oren Miller <or...@qu...>, 
qui...@li..., 
qui...@li... 
        bcc:         
        Subject:        Re: [Quickfix-developers] Re: monitor the FIX 
connection failure    programmatically?



On 11/4/05, Alvin Wang <AW...@ff...> wrote: 

So does it mean even when the physics connection is down and we did not 
receive logout msg, onLogout will still be invoked? If so, how can we tell 
if it is an abnormal logout/disconnection? 

Not trying to argue, but what if the FIX session is not never setup from 
beginning due to network problem? Will onLogout be called? 


I wouldn't call asking questions being argumentative :) 

No, if a connection never comes up you'll never get an onLogout callback.

I have implemented some monitoring of QuickFIX connections by making use 
of the onLogon/onLogout callback (for immediate notification when a 
connection comes up or goes down) coupled with a thread that iterates 
through all known sessions and uses FIX::Session::lookupSession + 
Session::isLoggedOn to capture those connections that either never come up 
or are outside their StartTime/EndTime windows. 

Pseudocode:

foreach (SessionID as id)
{
  Session* sess = Session::lookupSession (id);
  if (!sess) continue;
  send_connection_status (id, sess->isLoggedOn () ? "UP" : "DOWN"); 
} 

-- 
Caleb Epstein
caleb dot epstein at gmail dot com 

********************************************************************** 
This e-mail message is intended solely for the use of the addressee. The 
message may contain information that is privileged and confidential. 
Disclosure to anyone other than the intended recipient is prohibited. If 
you are not the intended recipient, please do not disseminate, distribute 
or copy this communication, by e-mail or otherwise. Instead, please notify 
us immediately by return e-mail (including the original message with your 
reply) and then delete and discard all copies of the message. We have 
taken precautions to minimize the risk of transmitting software viruses 
but nevertheless advise you to carry out your own virus checks on any 
attachment to this message. We accept no liability for any loss or damage 
caused by software viruses. 
********************************************************************** 

Re: [Quickfix-developers] Re: monitor the FIX connection failure programmatically?

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

Yup.

--oren
  ----- Original Message -----=20
  From: Alvin Wang=20
  To: Oren Miller=20
  Cc: Caleb Epstein ; qui...@li... ; =
qui...@li...=20
  Sent: Friday, November 04, 2005 7:21 PM
  Subject: Re: [Quickfix-developers] Re: monitor the FIX connection =
failure programmatically?



  Oren, at around EndTime, the initiator will disconnect (the normal =
behavior). If I call Session::isSessionTime() inside onLogout(), will it =
return false?=20
  Thanks=20
  Alvin=20




       "Oren Miller" <or...@qu...>=20
        11/04/2005 02:53 PM=20

              =20
                To:        "Caleb Epstein" <cal...@gm...>, =
"Alvin Wang" <AW...@FF...>=20
                cc:        <qui...@li...>, =
<qui...@li...>=20
                bcc:        =20
                Subject:        Re: [Quickfix-developers] Re: monitor =
the FIX connection failure    programmatically?=20



  You can use Session::isSessionTime() to determine if you are within =
the start and end times.  The hearbeat interval has nothing to do with =
when the session disconnects.=20
   =20
  --oren=20
  ----- Original Message -----=20
  From: Alvin Wang=20
  To: Caleb Epstein=20
  Cc: Oren Miller ; qui...@li... ; =
qui...@li...=20
  Sent: Friday, November 04, 2005 1:48 PM=20
  Subject: Re: [Quickfix-developers] Re: monitor the FIX connection =
failure programmatically?=20


  Caleb, we want to differentiate the normal logout/disconnect at the =
end of day, and the abnormal logout/disconnect during the session. (is =
it safe to assume that onLogout will not be called between Endtime and =
StartTime?) So my question is, can we use isLoggedOn method inside =
onLogout to make above judgement? If isLoggedOn=3Dtrue, it is abnormal.=20

  Or, what is the algorithm to decide exact when the initiator will =
disconnect at (around) the EndTime? For example, the EndTime is 22:00:00 =
and heartbeat interval is 30 seconds. Now the initiator sends a =
heartbeat at 21:59:10.  will the initiator disconnect at 21:59:40 or =
22:00:10?=20

  Many thanks=20
  Alvin=20



       Caleb Epstein <cal...@gm...>=20
        Sent by: qui...@li...=20
        11/04/2005 10:35 AM=20
              =20
               To:        Alvin Wang <AW...@ff...>=20
               cc:        Oren Miller <or...@qu...>, =
qui...@li..., =
qui...@li...=20
               bcc:        =20
               Subject:        Re: [Quickfix-developers] Re: monitor the =
FIX connection failure    programmatically?=20




  On 11/4/05, Alvin Wang <AW...@ff...> wrote:=20

  So does it mean even when the physics connection is down and we did =
not receive logout msg, onLogout will still be invoked? If so, how can =
we tell if it is an abnormal logout/disconnection?=20

  Not trying to argue, but what if the FIX session is not never setup =
from beginning due to network problem? Will onLogout be called?=20


  I wouldn't call asking questions being argumentative :)=20

  No, if a connection never comes up you'll never get an onLogout =
callback.

  I have implemented some monitoring of QuickFIX connections by making =
use of the onLogon/onLogout callback (for immediate notification when a =
connection comes up or goes down) coupled with a thread that iterates =
through all known sessions and uses FIX::Session::lookupSession + =
Session::isLoggedOn to capture those connections that either never come =
up or are outside their StartTime/EndTime windows.=20

  Pseudocode:

  foreach (SessionID as id)
  {
   Session* sess =3D Session::lookupSession (id);
   if (!sess) continue;
   send_connection_status (id, sess->isLoggedOn () ? "UP" : "DOWN");=20
  }=20

  --=20
  Caleb Epstein
  caleb dot epstein at gmail dot com=20

  ********************************************************************** =
This e-mail message is intended solely for the use of the addressee. The =
message may contain information that is privileged and confidential. =
Disclosure to anyone other than the intended recipient is prohibited. If =
you are not the intended recipient, please do not disseminate, =
distribute or copy this communication, by e-mail or otherwise. Instead, =
please notify us immediately by return e-mail (including the original =
message with your reply) and then delete and discard all copies of the =
message. We have taken precautions to minimize the risk of transmitting =
software viruses but nevertheless advise you to carry out your own virus =
checks on any attachment to this message. We accept no liability for any =
loss or damage caused by software viruses. =
**********************************************************************=20

Re: [Quickfix-developers] Re: monitor the FIX connection failure programmatically?

[Alvin W. <AW...@FF...>]

Oren, at around EndTime, the initiator will disconnect (the normal 
behavior). If I call Session::isSessionTime() inside onLogout(), will it return false?
Thanks
Alvin






"Oren Miller" <or...@qu...>
11/04/2005 02:53 PM

 
        To:     "Caleb Epstein" <cal...@gm...>, "Alvin Wang" <AW...@FF...>
        cc:     <qui...@li...>, 
<qui...@li...>
        bcc: 
        Subject:        Re: [Quickfix-developers] Re: monitor the FIX connection failure 
programmatically?


You can use Session::isSessionTime() to determine if you are within the 
start and end times.  The hearbeat interval has nothing to do with when 
the session disconnects.
 
--oren
----- Original Message ----- 
From: Alvin Wang 
To: Caleb Epstein 
Cc: Oren Miller ; qui...@li... ; qui...@li... 
Sent: Friday, November 04, 2005 1:48 PM
Subject: Re: [Quickfix-developers] Re: monitor the FIX connection failure 
programmatically?


Caleb, we want to differentiate the normal logout/disconnect at the end of 
day, and the abnormal logout/disconnect during the session. (is it safe to 
assume that onLogout will not be called between Endtime and StartTime?) So 
my question is, can we use isLoggedOn method inside onLogout to make above judgement? If isLoggedOn=true, it is abnormal. 

Or, what is the algorithm to decide exact when the initiator will 
disconnect at (around) the EndTime? For example, the EndTime is 22:00:00 
and heartbeat interval is 30 seconds. Now the initiator sends a heartbeat 
at 21:59:10.  will the initiator disconnect at 21:59:40 or 22:00:10? 

Many thanks 
Alvin 





Caleb Epstein <cal...@gm...> 
Sent by: qui...@li... 
11/04/2005 10:35 AM 
        
        To:        Alvin Wang <AW...@ff...> 
        cc:        Oren Miller <or...@qu...>, 
qui...@li..., 
qui...@li... 
        bcc:         
        Subject:        Re: [Quickfix-developers] Re: monitor the FIX 
connection failure    programmatically?



On 11/4/05, Alvin Wang <AW...@ff...> wrote: 

So does it mean even when the physics connection is down and we did not 
receive logout msg, onLogout will still be invoked? If so, how can we tell 
if it is an abnormal logout/disconnection? 

Not trying to argue, but what if the FIX session is not never setup from 
beginning due to network problem? Will onLogout be called? 


I wouldn't call asking questions being argumentative :) 

No, if a connection never comes up you'll never get an onLogout callback.

I have implemented some monitoring of QuickFIX connections by making use 
of the onLogon/onLogout callback (for immediate notification when a 
connection comes up or goes down) coupled with a thread that iterates 
through all known sessions and uses FIX::Session::lookupSession + 
Session::isLoggedOn to capture those connections that either never come up 
or are outside their StartTime/EndTime windows. 

Pseudocode:

foreach (SessionID as id)
{
  Session* sess = Session::lookupSession (id);
  if (!sess) continue;
  send_connection_status (id, sess->isLoggedOn () ? "UP" : "DOWN"); 
} 

-- 
Caleb Epstein
caleb dot epstein at gmail dot com 

********************************************************************** 
This e-mail message is intended solely for the use of the addressee. The 
message may contain information that is privileged and confidential. 
Disclosure to anyone other than the intended recipient is prohibited. If 
you are not the intended recipient, please do not disseminate, distribute 
or copy this communication, by e-mail or otherwise. Instead, please notify 
us immediately by return e-mail (including the original message with your 
reply) and then delete and discard all copies of the message. We have 
taken precautions to minimize the risk of transmitting software viruses 
but nevertheless advise you to carry out your own virus checks on any 
attachment to this message. We accept no liability for any loss or damage 
caused by software viruses. 
**********************************************************************