Hi, On Mon, Jun 30, 2008 at 11:24 AM, Asanka Abeysinghe <[EMAIL PROTECTED]> wrote:
> I totally agree with Asankha to take a similar approach like JMS connection > pools. Even FIX transport does the same to create the ***Initiator*** > session(s) by starting the FIX engine inside 'startListerningForServices' > method in the FIX transport listener. So if we start the ***Acceptor** > *FIX Engine by providing the session(s) info at the same level we will > solving our problem. when message transports it will check the availability > of the session and if exists use the session and dispatch the message else > create a new session (as it is now) . Currently we read a service parameter (transport.fix.AccetorConfigURL) inside the startListeningForService method and create the acceptors as necessary. If we are to do the same for creating initiators we will have to introduce a new parameter and ask the user to specify the target URL in that parameter in addition to in the target element of the service definition. But this approach suffers the drawback I mentioned previously. That is with one parameter we can specify only one target URL. Then we will be able to create only one acceptor session at the start up. If there's a way we can specify multiple URL values with one parameter then implementing the rest is easy. Any Ideas? Thanks Best Regards, Hiranya > > Asanka A. > > Asankha C. Perera wrote: > >> Asanka >> >>> Primary reason is that and I can add few more use cases >>> 1. Acceptor can send messages for a specific session before sending >>> messages from the initiator (fills, corrections and acknowledgments for the >>> previously posted transactions). >>> 2. FIX recovery happens with the session creation, so with the current >>> implementation recovery has to wait till the first message sends. >>> >>> Around how many of these "sessions" will a typical usecase have? in the >> order of services deployed, or a small fixed number - like the JMS >> connection factories? If this is a small fixed number, you could define this >> similarly to the way the JMS sender defines connection pools >> >> > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
