My mistake again, the initiator was trying to connect to a windows
firewall and was getting a timout after 20sec.
So the poll() method seems to solve our problems, we will digg deeper
that way from inside a python thread.
small other question, at the end of my loop, should i call
acceptor.stop() ? (or clear() or del acceptor) to cleanup resources
maintained by it ?
Thanks a lot,
Fugazy
Xavier Pianet a écrit :
> QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> Result 1:
> Well I just made a small trial with poll() on a SocketInitiator and it
> seems to work OK, that is great.
> But if i try it on a SocketAcceptor it seems that it will disconnect the
> clients every 20sec (whatever the heartbeat
> is configured to). any idea ? I can post the sample if it can help
>
> Result 3:
> My mistake, it doesn't hog the cpu, just not realease the 'python
> thread' after a time.sleep() for example.
>
> Thanks,
> Fugazy
>
> or...@qu... a écrit :
>
>> Answer 1:
>> There are three ways to run the engine. These are done via the
>> start(), block(), and poll() calls. Poll will do what you are looking
>> for I think. It will process any waiting events and then return, so
>> you could run multiple message loops that way.
>>
>> Answer 2:
>> There is currently no way to feed outside sockets into the QuickFIX
>> event loop. This is something we can look into, you aren't the first
>> to ask about this.
>> Answer 3:
>> I'm not entirely sure, but I am really curious as to why calling start
>> is pegging your cpu. This should simply be blocking in another
>> thread. There really shouldn't be anything going on with the cpu
>> unless there are events to process. Any idea what is going on here?
>>
>> So question 1:
>> Is there a way to 'step' the fix engine, ie something in the path of
>> -----
>> acceptor = fix.SocketInitiator( application, storeFactory,
>> settings, logFactory )
>> acceptor.start()
>> while acceptor.isRunning():
>> acceptor.step()
>> acceptor.stop()
>> Question 2:
>> is it possible to 'feed' the fix engine, ie i take care of all the
>> socket work
>> (open/accept/read/write) and feed the SocketInitiator/SocketAcceptor
>> with the
>> the one thing i can see that gives problem would be a 'callback' for
>> it to
>> write data to the socket.
>> -----
>> acceptor = fix.SocketInitiator( application, storeFactory,
>> settings, logFactory )
>> acceptor.setWriteCallback(myWriteCallback)
>> acceptor.start()
>> -- manage my sockets and read data from it into socketData
>> if acceptor.isRunning():
>> acceptor.data(socketData)
>>
>> Question 3:
>> any other approach that will help me get the QuickFix event loop
>> coexist peacefully
>> with twisted or wxPython
>>
>> BTW we have developper resources to devote to this pb, and i think
>> it would
>> be more interesting to solve this pb in QuickFix, than to redevelop
>> (once more) our own
>> python version of it (we only have 8 messages to implement and
>> doing it from
>> what we h ave in pure python should be in the 10-15 days work)
>>
>>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
> Don't miss this year's exciting event. There's still time to save $100.
> Use priority code J8TL2D2.
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>
>
|
