There is an alternative to all this:
1. Create an implementation of the Startup interface together with a
StartupFactory and StartupSerializer.
2. When the init method (defined by ManagedLifecycle) is called on the
Startup (at Synapse startup as the name implies), it gets the
SynapseEnvironment as parameter. From there you can get access to the
SynapseConfiguration and the Axis2 ConfigurationContext (provided that
SYNAPSE-382 is fixed).
3. SynapseConfiguration#getProxyServices gives you the list of defined
proxy services and ProxyService#getTargetEndpoint gives you the target
endpoint.
4. ConfigurationContext#getAxisConfiguration gives you the
AxisConfiguration and from there you can locate a transport sender by
using AxisConfiguration#getTransport(s)(In|Out) (call get(Reveiver|
Sender) on the Transport(In|Out)Description).
This should give you all the information you need to access the
transport and tell it to start the relevant sessions.
Andreas
On 30 juin 08, at 13:58, Hiranya Jayathilaka wrote:
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
