RE: [Quickfix-developers] [qfj] Queueing messages before Logged on?

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

Thanks for that Oren - I thought it should but it wasn't working.  Turns
out our modifications to quickfix.Session broke the sending of queued
messages.  So, any suggestions on how to send a BE User Request after a
logon but before any queued messages without modifying quickfix.Session
are very welcome!

-----Original Message-----
From: Oren Miller [mailto:or...@qu...]=20
Sent: Friday, 17 March 2006 2:05 AM
To: Brad Harvey
Cc: qui...@li...
Subject: Re: [Quickfix-developers] [qfj] Queueing messages before Logged
on?

You can send messages at any time.  There is no need to wait for a=20
succesful logon.  The messages will be queued sent automatically after=20
the next succesfull connection.

--oren

Brad Harvey wrote:

> Hi All,
>
> I would like to be able to send messages to quickfixj after a session=20
> has been created but while it is not logged on, and then have those=20
> messages sent automatically once the session is logged on.  Is this=20
> something that is currently possible?=20
>
> Some additional background info may be in order.  Our counterparty fix

> engine is really just a wrapper for another system, and before we=20
> start sending orders etc we have to login to the other system with a=20
> BE User request.  No, I'm not sure why they didn't just add some=20
> custom fields to the normal fix login message.=20
>
> We wanted to ensure that no "normal" messages could be sent before the

> BE User request.  To do this we have modified Session to only consider

> itself fully logged on after the BE User request, and to automatically

> send the BE after the normal fix logon.  Before our application sends=20
> any messages it waits for session.isLoggedOn() to be true.  I'm not=20
> really happy with this - I'd prefer it to be able to just send it and=20
> let quickfix take care of sending when it can, hence the original=20
> question.
>
> I'm also interested in hearing of better ways to do the BE User=20
> request thing - I'd really prefer not to maintain our own changes in=20
> Session.  We're quite happy to contribute the changes if they'd be=20
> useful to the quickfixj community, but at the moment it isn't optional

> so would require a little work.
>
> Regards,
> Brad.
>