TN Time Delay in service ececution

I am trying to process few 1 mb Flat files in TN with normal setting,
The problem i am facing…

What i noticed…

Routing rule selection and document persitence are happening almost same time.But the service invocation kicked off 6-8 minutes later.

Why so much of time delay ? I need to reduce the time delay . so what
kind of optinization can be done , if anybody can help me,

We are using synchonous type of service execution.
Though the service completion does not take much time,

Its the kicking of service thats been called lately
Pls help to reduce the time.

Hi Kpaul,
Pls. write to us what version of IS/TN your are using?

Check the TN config property file. There is a TN config property “I don’t recall for now”, which determines the no. of concurrent connections TN can have with the DB. If that property is at its default level or is set too low and you are trying to dump several documents to TN concurrently, then you will see this behaviour i.e. Even if TN stores the document in the DB, it will not call the execution service until the TN’s concurrent DB connections fall below that config property and hence the delay.

I had increased TN’s throughput this way by setting that TN config property higher in TN4.6 way back in 2002. Let us know your IS/TN version??

HTH,
Bhawesh Singh.

Hi Bhawesh,

Thanks for your promt reply ? Are you refering to JDBC TN_POOL
max conn setting [Max DB conn for TN from admin GUI] ? I had 1…10
If you are refering to any other property please let me know.I could
not find any other TN config file / property file relevant to DB conn.
I will go ahead and test with with max conn as 30.

We are using 6.5 version IS/TN.DB Oracle 9.0.2.

Thanks
Paul

May be he was referring to WmTN/config/properties.cnf settings??

HTH,
RMG

Hi RMG,

I tried to find out properties from WmTN\config\properties,default_properties & dblimits files…could not find
suitable attribute…IF anyone could help / show me a way…

I have only 1 related i guess …

tn.query.threshold= & not sure too

Thanks
Paul