[jpos-dev] Connectivity Issue found for MUXPool mux strategy

['[e-mail]' [e-mail] [jpos-dev]]

Hi,


I am facing connectivity issues(taking more than 14 seconds) when am sending
ISO request to Q2 server for some transactions.
I have a MUXPool consist of two muxes(primary and secondary).
Last time I was using "round-robin" strategy ,but i had faced same problems
more than 1000 transactions per day.
Now I have changed it to "primary-secondary", but still 200 transactions are
taking more than 12 sec for sending request to Q2 Server.


Could you please help me on this if any one have an idea.


Below are the config files,


*07_mux_channel_primary.xml*


<channel-adaptor name='mux-channel-primary-adaptor'
class="org.jpos.q2.iso.ChannelAdaptor" logger="Q2-Mux">
<channel class="org.jpos.iso.channel.XMLChannel" logger="Q2-Mux"
packager="org.jpos.iso.packager.XMLPackager">
<property name="host" value="127.0.0.1" />
<property name="port" value="8081" />
<property name="debug" value="false" />
</channel>
<in>mux-channel-primary-send</in>
<out>mux-channel-primary-receive</out>
<reconnect-delay>10000</reconnect-delay>
<ignore-iso-exceptions>yes</ignore-iso-exceptions>
</channel-adaptor>




*07_mux_channel_secondary.xml*


<channel-adaptor name='mux-channel-secondary-adaptor'
class="org.jpos.q2.iso.ChannelAdaptor" logger="Q2-Mux">
<channel class="org.jpos.iso.channel.XMLChannel" logger="Q2-Mux"
packager="org.jpos.iso.packager.XMLPackager">
<property name="host" value="127.0.0.1" />
<property name="port" value="8081" />
<property name="debug" value="false" />
</channel>
<in>mux-channel-secondary-send</in>
<out>mux-channel-secondary-receive</out>
<reconnect-delay>10000</reconnect-delay>
<ignore-iso-exceptions>yes</ignore-iso-exceptions>
</channel-adaptor>


*08_client_mux_primary.xml*


<mux class="org.jpos.q2.iso.QMUX" logger="Q2" name="client-primary-mux">
<in>mux-channel-primary-receive</in>
<out>mux-channel-primary-send</out>
<key>11.1,11.2</key>
<unhandled>mux-channel-primary-unhandled</unhandled>
</mux>




*08_client_mux_secondary.xml*


<mux class="org.jpos.q2.iso.QMUX" logger="Q2" name="client-secondary-mux">
<in>mux-channel-secondary-receive</in>
<out>mux-channel-secondary-send</out>
<key>11.1,11.2</key>
<unhandled>mux-channel-secondary-unhandled</unhandled>
</mux>


*09_mux_pool.xml*


<mux class="org.jpos.q2.iso.MUXPool" logger="Q2" name="switch-mux-pool">
<muxes>client-primary-mux client-secondary-mux</muxes>
<strategy>primary-secondary</strategy>


</mux>


*10_switch_mux.xml*


<qbean name="switch-mux" logger="Q2" realm="switch-mux"
class="com.switch.context.SwitchISOMux">
<property name="mux" value="switch-mux-pool" />
<property name="timeout" value="180000" />
</qbean>


*SwitchISOMux.java*


public class SwitchISOMux extends org.jpos.q2.QBeanSupport {
private static MUXPool muxPool;
private static long timeOut;
private static String muxName;
private static final org.apache.log4j.Logger LOG =
org.apache.log4j.Logger.getLogger(SwitchISOMux.class);


public SwitchISOMux() {
super();
}


protected void initService() throws ISOException {
muxName = "mux." + cfg.get("mux");
timeOut = cfg.getLong("timeout");
}


protected void startService() {
try {
muxPool = (MUXPool) NameRegistrar.get(muxName);
} catch (NameRegistrar.NotFoundException e) {
LOG.error("NameRegistrar.NotFoundException in startService:",
e);
} catch (Exception e) {
LOG.error("Exception in startService:", e);
}
}


public ISOMsg sendMsg(ISOMsg isoMsg) throws ISOException {
return muxPool.request(isoMsg, timeOut);
}


}


Thanks,
Sridhar Jena






--
View this message in context: http://jpos.1045706.n5.nabble.com/Connectivity-Issue-found-for-MUXPool-mux-strategy-tp5715250.html
Sent from the jPOS - Dev mailing list archive at Nabble.com.

[Andy Orrock [e-mail] [jpos-dev]]

We run mux pool on interfaces processing over 5m transactions a day without
issue or delay.

--------
*ANDY ORROCK*

Post by '***@aurusinc.com' ***@aurusinc.com [jpos-dev]
Hi,
I am facing connectivity issues(taking more than 14 seconds) when am sending
ISO request to Q2 server for some transactions.
I have a MUXPool consist of two muxes(primary and secondary).
Last time I was using "round-robin" strategy ,but i had faced same problems
more than 1000 transactions per day.
Now I have changed it to "primary-secondary", but still 200 transactions are
taking more than 12 sec for sending request to Q2 Server.
Could you please help me on this if any one have an idea.
Below are the config files,
*07_mux_channel_primary.xml*
<channel-adaptor name='mux-channel-primary-adaptor'
class="org.jpos.q2.iso.ChannelAdaptor" logger="Q2-Mux">
<channel class="org.jpos.iso.channel.XMLChannel" logger="Q2-Mux"
packager="org.jpos.iso.packager.XMLPackager">
<property name="host" value="127.0.0.1" />
<property name="port" value="8081" />
<property name="debug" value="false" />
</channel>
<in>mux-channel-primary-send</in>
<out>mux-channel-primary-receive</out>
<reconnect-delay>10000</reconnect-delay>
<ignore-iso-exceptions>yes</ignore-iso-exceptions>
</channel-adaptor>
*07_mux_channel_secondary.xml*
<channel-adaptor name='mux-channel-secondary-adaptor'
class="org.jpos.q2.iso.ChannelAdaptor" logger="Q2-Mux">
<channel class="org.jpos.iso.channel.XMLChannel" logger="Q2-Mux"
packager="org.jpos.iso.packager.XMLPackager">
<property name="host" value="127.0.0.1" />
<property name="port" value="8081" />
<property name="debug" value="false" />
</channel>
<in>mux-channel-secondary-send</in>
<out>mux-channel-secondary-receive</out>
<reconnect-delay>10000</reconnect-delay>
<ignore-iso-exceptions>yes</ignore-iso-exceptions>
</channel-adaptor>
*08_client_mux_primary.xml*
<mux class="org.jpos.q2.iso.QMUX" logger="Q2" name="client-primary-mux">
<in>mux-channel-primary-receive</in>
<out>mux-channel-primary-send</out>
<key>11.1,11.2</key>
<unhandled>mux-channel-primary-unhandled</unhandled>
</mux>
*08_client_mux_secondary.xml*
<mux class="org.jpos.q2.iso.QMUX" logger="Q2" name="client-secondary-mux">
<in>mux-channel-secondary-receive</in>
<out>mux-channel-secondary-send</out>
<key>11.1,11.2</key>
<unhandled>mux-channel-secondary-unhandled</unhandled>
</mux>
*09_mux_pool.xml*
<mux class="org.jpos.q2.iso.MUXPool" logger="Q2" name="switch-mux-pool">
<muxes>client-primary-mux client-secondary-mux</muxes>
<strategy>primary-secondary</strategy>
</mux>
*10_switch_mux.xml*
<qbean name="switch-mux" logger="Q2" realm="switch-mux"
class="com.switch.context.SwitchISOMux">
<property name="mux" value="switch-mux-pool" />
<property name="timeout" value="180000" />
</qbean>
*SwitchISOMux.java*
public class SwitchISOMux extends org.jpos.q2.QBeanSupport {
private static MUXPool muxPool;
private static long timeOut;
private static String muxName;
private static final org.apache.log4j.Logger LOG =
org.apache.log4j.Logger.getLogger(SwitchISOMux.class);
public SwitchISOMux() {
super();
}
protected void initService() throws ISOException {
muxName = "mux." + cfg.get("mux");
timeOut = cfg.getLong("timeout");
}
protected void startService() {
try {
muxPool = (MUXPool) NameRegistrar.get(muxName);
} catch (NameRegistrar.NotFoundException e) {
LOG.error("NameRegistrar.NotFoundException in startService:",
e);
} catch (Exception e) {
LOG.error("Exception in startService:", e);
}
}
public ISOMsg sendMsg(ISOMsg isoMsg) throws ISOException {
return muxPool.request(isoMsg, timeOut);
}
}
Thanks,
Sridhar Jena
--
http://jpos.1045706.n5.nabble.com/Connectivity-Issue-found-for-MUXPool-mux-strategy-tp5715250.html
Sent from the jPOS - Dev mailing list archive at Nabble.com.
------------------------------------
------------------------------------
------------------------------------
Yahoo Groups Links

[chhil [e-mail] [jpos-dev]]

So sending a tran takes that long or receiving one takes that long?

How is the Qservers requestlistener processing transactions?
Are you processing them in the requestlistener or handing them off to a
transaction manager that processes them in a multithreaded way?

-chhil

[chhil [e-mail] [jpos-dev]]

​Your logging does not look familiar.
What does the Q2 logs show when the profiler dumps values of time take in
the participants?​

How is your QServer configured? Number of threads in the pool?

-chhil

p.s. Please refrain from sending direct emails.

Thanks Chhil for quick reply.
Time is taking only for sending, not for receiving.
After received the transactions through request listener,we are handing
them off to a transaction manager that processes them in a multithreaded
way.
*Below are the logs for 2 transactions:*
*11:30:26:749* AM EDT >> [AurusISOMux.sendMsg(77)] - Sending Request To
Q2 Server(b0f4beae-dc96-408d-9829-d0a672acbad6)...
*11:30:40:292* AM EDT >> ISOMsgRequestDispatcher >> Recieved ISO Request
at Q2 Server from : 204.63.160.197 by PooledThread-10-running [0.1/0.1]
*11:30:41:487* AM EDT >> IssuerResponseParticipant >> Response Sent to
Client in Prepare [0.0/1194.7]
*11:30:41:487* AM EDT >> Receiving Response From Q2
Server(b0f4beae-dc96-408d-9829-d0a672acbad6)...
*11:30:29,635* AM EDT >> [AurusISOMux.sendMsg(77)] - Sending Request To
Q2 Server(283d3724-6804-4615-97ad-ad00818557f4)...
*11:30:40:294* AM EDT >> ISOMsgRequestDispatcher >> Recieved ISO Request
at Q2 Server from : 204.63.160.197 by PooledThread-10-running [0.1/0.1]
*11:30:41:902* AM EDT >> IssuerResponseParticipant >> Response Sent to
Client in Prepare [0.0/1607.7]
*11:30:41,902* AM EDT >> [AurusISOMux.sendMsg(79)] - Receiving Response
From Q2 Server(283d3724-6804-4615-97ad-ad00818557f4)...
It is not the issue in Transaction manager, after listened the request
through RequestListener, It is processing immediately and sending the
response.
Time is taking between sending the Request and receiving the request at
Request Listener.
We are processing 1.5m transactions per day ,all transactions are being
processed in some milli seconds, But for some transactions we are getting
this issues.
--
*________________________________________________________________________________________________________________________________________________________________*
*Thanks and Regards,*
*Sridhar*
So sending a tran takes that long or receiving one takes that long?
How is the Qservers requestlistener processing transactions?
Are you processing them in the requestlistener or handing them off to a
transaction manager that processes them in a multithreaded way?
-chhil
--
*________________________________________________________________________________________________________________________________________________________________*
*Thanks and Regards,*
*Sridhar Jena,* Sr. System Analyst
*+ 91 - 20 - 27655062* | *+ 91 - 9226345267* | *www.aurusinc.com*
<http://www.aurusinc.com/>
*Plot G-2, Sector 26, Pradhikaran, Pune, Maharashtra-411044*
<http://www.aurusinc.com/>
<https://www.facebook.com/pages/Aurus-Inc-Solution-and-Services-Provider/168611626510639>
<https://www.facebook.com/pages/Aurus-Inc-Solution-and-Services-Provider/168611626510639>
<https://twitter.com/aurustech> <https://twitter.com/aurustech>
<http://linkedin.com/company/aurustech>
<http://linkedin.com/company/aurustech>
<https://plus.google.com/100924847781939597025>
*Please consider the environment before printing this e-mail *
Disclaimers: This message contains confidential information and is
intended only for the individual named. If you are not the named addressee
you should not disseminate, distribute or copy this e-mail. Please notify
the sender immediately by e-mail if you have received this e-mail by
mistake and delete this e-mail from your system. E-mail transmission cannot
be guaranteed to be secure or error-free as information could be
intercepted, corrupted, lost, destroyed, arrive late or incomplete, or
contain viruses. The sender therefore does not accept liability for any
errors or omissions in the contents of this message, which arise as a
result of e-mail transmission. If verification is required please request a
hard-copy version.

[Non-text portions of this message have been removed]

[chhil [e-mail] [jpos-dev]]

The min of 2 and max of 4 doesnt look correct, any reason why the jpos
defaults of min 1 max 100 are not being used?

I would remove the min max properties from the qserver config.

https://github.com/jpos/jPOS/blob/master/jpos/src/main/java/org/jpos/q2/iso/QServer.java#L57-L58

-chhil

Hi Chhil,
Below are the Q2 Server configuration and profiler details.
*01_serverconfigure.xml*
As we are using 2 muxes for connectivity to Q2 Server, we are configuring
*"2"* minSessions.
<server class="org.jpos.q2.iso.QServer" logger="Q2" name="Aurus-Q2">
<attr name="port" type="java.lang.Integer">&q2Port;</attr>
<attr name="minSessions" type="java.lang.Integer">2</attr>
<attr name="maxSessions" type="java.lang.Integer">4</attr>
<property name="allow" value="&q2Host;" />
<channel class="&q2Channel;" logger="Q2" packager="&q2Packager;">
</channel>
<request-listener
class="com.auruspay.isomsglistner.ISOMsgRequestDispatcher" logger="Q2">
<property name="queue" value="&managerQueue;"/>
<property name="timeout" value="60000"/>
</request-listener>
</server>
*Below are the bench mark log for entry points.*
*Step 1:* Sending Request to Q2 Server
ISOMsg responseISOMsg = aurusMuxPool.request(isoMsg, timeOut);
* 11:30:26:749* AM EDT >> [AurusISOMux.sendMsg(77)] - Sending
Request To Q2 Server(b0f4beae-dc96-408d-9829-d0a672acbad6)...
*Step 2:* Receiving Request at Q2 Server
*public boolean process(ISOSource isoSource, ISOMsg isoMsg)*
* 11:30:40:292* AM EDT >> ISOMsgRequestDispatcher >> Recieved ISO
Request at Q2 Server
*Step 3:* Sending Response from IssuerResponseParticipant
* 11:30:41:487* AM EDT >> IssuerResponseParticipant >> Response Sent
to Client in Prepare [0.0/1194.7]
*Step 4:* Receiving Response at MuxPool
* 11:30:41:487* AM EDT >> Receiving Response From Q2
Server(b0f4beae-dc96-408d-9829-d0a672acbad6)...
*11:30:40:292* AM EDT >> ISOMsgRequestDispatcher >> Recieved ISO Request
at Q2 Server from : 204.63.160.197 by PooledThread-10-running [0.1/0.1]
*Below is the profiler for transaction Manager.*
<log realm="TransactionManager" at="Mon Aug 17 11:30:41.501 EDT 2015"
lifespan="1208ms">
<debug>
txnmgr-87:idle:65763
com.auruspay.manager.acquirer.participants.validation.SchemaValidationParticipant
NO_JOIN
com.auruspay.manager.acquirer.group.TxnRequestTypeSelector NO_JOIN
selector: RequestValidation Infinispan RequestAuthorization
Transaction Processor Issuer_End
com.auruspay.manager.acquirer.participants.validation.ValidateTransactionParticipant
NO_JOIN
com.auruspay.manager.acquirer.participants.InfinispanParticipant NO_JOIN
com.auruspay.manager.acquirer.participants.validation.RequestAuthorizationParticipant
NO_JOIN
com.auruspay.manager.acquirer.group.TxnCardTypeSelector NO_JOIN
selector: BinValidation CreditSale
com.auruspay.manager.acquirer.participants.validation.BinValidationParticipant
NO_JOIN
com.auruspay.manager.acquirer.participants.FillOriginalTransParticipant
NO_JOIN
com.auruspay.manager.issuer.group.ProcessorTypeSelector READONLY NO_JOIN
selector: ElavonCredit
com.auruspay.manager.issuer.participants.ProcessorQueryParticipant NO_JOIN
com.auruspay.manager.issuer.participants.processor.elavon.ElavonCreditParticipant
NO_JOIN
com.auruspay.manager.issuer.participants.BuildISOResponseParticipant NO_JOIN
com.auruspay.manager.issuer.participants.IssuerResponseParticipant READONLY
NO_JOIN
com.auruspay.manager.issuer.participants.IssuerDirPollParticipant READONLY
NO_JOIN
com.auruspay.manager.issuer.participants.IssuerGrayLogParticipant READONLY
NO_JOIN
com.auruspay.manager.issuer.participants.IssuerNotifyParticipant READONLY
com.auruspay.manager.issuer.participants.IssuerProtectDebugInfo READONLY
com.auruspay.manager.issuer.participants.IssuerProfilerParticipant READONLY
com.auruspay.manager.issuer.participants.IssuerNotifyParticipant
com.auruspay.manager.issuer.participants.IssuerProtectDebugInfo
com.auruspay.manager.issuer.participants.IssuerProfilerParticipant
head=65768, tail=65764, outstanding=0, active-sessions=100/200, tps=2,
peak=7, avg=1.00, elapsed=1208ms
<profiler>
com.auruspay.manager.acquirer.participants.validation.SchemaValidationParticipant
[1.9/1.9]
prepare: com.auruspay.manager.acquirer.group.TxnRequestTypeSelector
[0.3/2.2]
com.auruspay.manager.acquirer.participants.validation.ValidateTransactionParticipant
[0.8/3.1]
com.auruspay.manager.acquirer.participants.InfinispanParticipant [2.2/5.3]
com.auruspay.manager.acquirer.participants.validation.RequestAuthorizationParticipant
[102.4/107.8]
prepare: com.auruspay.manager.acquirer.group.TxnCardTypeSelector
[0.2/108.0]
com.auruspay.manager.acquirer.participants.validation.BinValidationParticipant
[1.7/109.7]
com.auruspay.manager.acquirer.participants.FillOriginalTransParticipant
[0.0/109.8]
prepare: com.auruspay.manager.issuer.group.ProcessorTypeSelector
[0.3/110.1]
com.auruspay.manager.issuer.participants.ProcessorQueryParticipant
[1.4/111.5]
com.auruspay.manager.issuer.participants.processor.elavon.ElavonCreditParticipant
[1027.0/1138.5]
com.auruspay.manager.issuer.participants.BuildISOResponseParticipant
[55.6/1194.2]
com.auruspay.manager.issuer.participants.IssuerResponseParticipant
[0.8/1195.0]
com.auruspay.manager.issuer.participants.IssuerDirPollParticipant
[9.0/1204.1]
com.auruspay.manager.issuer.participants.IssuerGrayLogParticipant
[0.2/1204.4]
com.auruspay.manager.issuer.participants.IssuerNotifyParticipant
[0.0/1204.4]
com.auruspay.manager.issuer.participants.IssuerProtectDebugInfo [0.0/1204.4]
com.auruspay.manager.issuer.participants.IssuerProfilerParticipant
[0.0/1204.4]
com.auruspay.manager.issuer.participants.IssuerNotifyParticipant
[0.0/1204.5]
com.auruspay.manager.issuer.participants.IssuerProtectDebugInfo [2.9/1207.4]
com.auruspay.manager.issuer.participants.IssuerProfilerParticipant
[0.5/1208.0]
end [0.2/1208.2]
</profiler>
</debug>
</log>
Please let me know if you need more information.
--
*________________________________________________________________________________________________________________________________________________________________*
*Thanks and Regards,*
*Sridhar Jena,* Sr. System Analyst
*+ 91 - 20 - 27655062* | *+ 91 - 9226345267* | *www.aurusinc.com*
<http://www.aurusinc.com/>
*Plot G-2, Sector 26, Pradhikaran, Pune, Maharashtra-411044*
<http://www.aurusinc.com/>
<https://www.facebook.com/pages/Aurus-Inc-Solution-and-Services-Provider/168611626510639>
<https://www.facebook.com/pages/Aurus-Inc-Solution-and-Services-Provider/168611626510639>
<https://twitter.com/aurustech> <https://twitter.com/aurustech>
<http://linkedin.com/company/aurustech>
<http://linkedin.com/company/aurustech>
<https://plus.google.com/100924847781939597025>
*Please consider the environment before printing this e-mail *
Disclaimers: This message contains confidential information and is
intended only for the individual named. If you are not the named addressee
you should not disseminate, distribute or copy this e-mail. Please notify
the sender immediately by e-mail if you have received this e-mail by
mistake and delete this e-mail from your system. E-mail transmission cannot
be guaranteed to be secure or error-free as information could be
intercepted, corrupted, lost, destroyed, arrive late or incomplete, or
contain viruses. The sender therefore does not accept liability for any
errors or omissions in the contents of this message, which arise as a
result of e-mail transmission. If verification is required please request a
hard-copy version.
​Your logging does not look familiar.
What does the Q2 logs show when the profiler dumps values of time take in
the participants?​
How is your QServer configured? Number of threads in the pool?
-chhil
p.s. Please refrain from sending direct emails.

Thanks Chhil for quick reply.
Time is taking only for sending, not for receiving.
After received the transactions through request listener,we are handing
them off to a transaction manager that processes them in a multithreaded
way.
*Below are the logs for 2 transactions:*
*11:30:26:749* AM EDT >> [AurusISOMux.sendMsg(77)] - Sending Request To
Q2 Server(b0f4beae-dc96-408d-9829-d0a672acbad6)...
*11:30:40:292* AM EDT >> ISOMsgRequestDispatcher >> Recieved ISO Request
at Q2 Server from : 204.63.160.197 by PooledThread-10-running [0.1/0.1]
*11:30:41:487* AM EDT >> IssuerResponseParticipant >> Response Sent to
Client in Prepare [0.0/1194.7]
*11:30:41:487* AM EDT >> Receiving Response From Q2
Server(b0f4beae-dc96-408d-9829-d0a672acbad6)...
*11:30:29,635* AM EDT >> [AurusISOMux.sendMsg(77)] - Sending Request To
Q2 Server(283d3724-6804-4615-97ad-ad00818557f4)...
*11:30:40:294* AM EDT >> ISOMsgRequestDispatcher >> Recieved ISO Request
at Q2 Server from : 204.63.160.197 by PooledThread-10-running [0.1/0.1]
*11:30:41:902* AM EDT >> IssuerResponseParticipant >> Response Sent to
Client in Prepare [0.0/1607.7]
*11:30:41,902* AM EDT >> [AurusISOMux.sendMsg(79)] - Receiving Response
From Q2 Server(283d3724-6804-4615-97ad-ad00818557f4)...
It is not the issue in Transaction manager, after listened the request
through RequestListener, It is processing immediately and sending the
response.
Time is taking between sending the Request and receiving the request at
Request Listener.
We are processing 1.5m transactions per day ,all transactions are being
processed in some milli seconds, But for some transactions we are getting
this issues.
--
*________________________________________________________________________________________________________________________________________________________________*
*Thanks and Regards,*
*Sridhar*
So sending a tran takes that long or receiving one takes that long?
How is the Qservers requestlistener processing transactions?
Are you processing them in the requestlistener or handing them off to a
transaction manager that processes them in a multithreaded way?
-chhil
--
*________________________________________________________________________________________________________________________________________________________________*
*Thanks and Regards,*
*Sridhar Jena,* Sr. System Analyst
*+ 91 - 20 - 27655062* | *+ 91 - 9226345267* | *www.aurusinc.com*
<http://www.aurusinc.com/>
*Plot G-2, Sector 26, Pradhikaran, Pune, Maharashtra-411044*
<http://www.aurusinc.com/>
<https://www.facebook.com/pages/Aurus-Inc-Solution-and-Services-Provider/168611626510639>
<https://www.facebook.com/pages/Aurus-Inc-Solution-and-Services-Provider/168611626510639>
<https://twitter.com/aurustech> <https://twitter.com/aurustech>
<http://linkedin.com/company/aurustech>
<http://linkedin.com/company/aurustech>
<https://plus.google.com/100924847781939597025>
*Please consider the environment before printing this e-mail *
Disclaimers: This message contains confidential information and is
intended only for the individual named. If you are not the named addressee
you should not disseminate, distribute or copy this e-mail. Please notify
the sender immediately by e-mail if you have received this e-mail by
mistake and delete this e-mail from your system. E-mail transmission cannot
be guaranteed to be secure or error-free as information could be
intercepted, corrupted, lost, destroyed, arrive late or incomplete, or
contain viruses. The sender therefore does not accept liability for any
errors or omissions in the contents of this message, which arise as a
result of e-mail transmission. If verification is required please request a
hard-copy version.

[Non-text portions of this message have been removed]

[chhil [e-mail] [jpos-dev]]

With 2 and 4 you probably should have seen "pool exhausted " events logged
in the servers Q2 log.

https://github.com/jpos/jPOS/blob/master/jpos/src/main/java/org/jpos/iso/ISOServer.java#L346-L347

-chhil

Post by chhil ***@gmail.com [jpos-dev]
The min of 2 and max of 4 doesnt look correct, any reason why the jpos
defaults of min 1 max 100 are not being used?
I would remove the min max properties from the qserver config.
https://github.com/jpos/jPOS/blob/master/jpos/src/main/java/org/jpos/q2/iso/QServer.java#L57-L58
-chhil

Hi Chhil,
Below are the Q2 Server configuration and profiler details.
*01_serverconfigure.xml*
As we are using 2 muxes for connectivity to Q2 Server, we are configuring
*"2"* minSessions.
<server class="org.jpos.q2.iso.QServer" logger="Q2" name="Aurus-Q2">
<attr name="port" type="java.lang.Integer">&q2Port;</attr>
<attr name="minSessions" type="java.lang.Integer">2</attr>
<attr name="maxSessions" type="java.lang.Integer">4</attr>
<property name="allow" value="&q2Host;" />
<channel class="&q2Channel;" logger="Q2" packager="&q2Packager;">
</channel>
<request-listener
class="com.auruspay.isomsglistner.ISOMsgRequestDispatcher" logger="Q2">
<property name="queue" value="&managerQueue;"/>
<property name="timeout" value="60000"/>
</request-listener>
</server>
*Below are the bench mark log for entry points.*
*Step 1:* Sending Request to Q2 Server
ISOMsg responseISOMsg = aurusMuxPool.request(isoMsg, timeOut);
* 11:30:26:749* AM EDT >> [AurusISOMux.sendMsg(77)] - Sending
Request To Q2 Server(b0f4beae-dc96-408d-9829-d0a672acbad6)...
*Step 2:* Receiving Request at Q2 Server
*public boolean process(ISOSource isoSource, ISOMsg isoMsg)*
* 11:30:40:292* AM EDT >> ISOMsgRequestDispatcher >> Recieved ISO
Request at Q2 Server
*Step 3:* Sending Response from IssuerResponseParticipant
* 11:30:41:487* AM EDT >> IssuerResponseParticipant >> Response Sent
to Client in Prepare [0.0/1194.7]
*Step 4:* Receiving Response at MuxPool
* 11:30:41:487* AM EDT >> Receiving Response From Q2
Server(b0f4beae-dc96-408d-9829-d0a672acbad6)...
*11:30:40:292* AM EDT >> ISOMsgRequestDispatcher >> Recieved ISO Request
at Q2 Server from : 204.63.160.197 by PooledThread-10-running [0.1/0.1]
*Below is the profiler for transaction Manager.*
<log realm="TransactionManager" at="Mon Aug 17 11:30:41.501 EDT 2015"
lifespan="1208ms">
<debug>
txnmgr-87:idle:65763
com.auruspay.manager.acquirer.participants.validation.SchemaValidationParticipant
NO_JOIN
com.auruspay.manager.acquirer.group.TxnRequestTypeSelector NO_JOIN
selector: RequestValidation Infinispan RequestAuthorization
Transaction Processor Issuer_End
com.auruspay.manager.acquirer.participants.validation.ValidateTransactionParticipant
NO_JOIN
com.auruspay.manager.acquirer.participants.InfinispanParticipant NO_JOIN
com.auruspay.manager.acquirer.participants.validation.RequestAuthorizationParticipant
NO_JOIN
com.auruspay.manager.acquirer.group.TxnCardTypeSelector NO_JOIN
selector: BinValidation CreditSale
com.auruspay.manager.acquirer.participants.validation.BinValidationParticipant
NO_JOIN
com.auruspay.manager.acquirer.participants.FillOriginalTransParticipant
NO_JOIN
com.auruspay.manager.issuer.group.ProcessorTypeSelector READONLY NO_JOIN
selector: ElavonCredit
com.auruspay.manager.issuer.participants.ProcessorQueryParticipant NO_JOIN
com.auruspay.manager.issuer.participants.processor.elavon.ElavonCreditParticipant
NO_JOIN
com.auruspay.manager.issuer.participants.BuildISOResponseParticipant NO_JOIN
com.auruspay.manager.issuer.participants.IssuerResponseParticipant READONLY
NO_JOIN
com.auruspay.manager.issuer.participants.IssuerDirPollParticipant READONLY
NO_JOIN
com.auruspay.manager.issuer.participants.IssuerGrayLogParticipant READONLY
NO_JOIN
com.auruspay.manager.issuer.participants.IssuerNotifyParticipant READONLY
com.auruspay.manager.issuer.participants.IssuerProtectDebugInfo READONLY
com.auruspay.manager.issuer.participants.IssuerProfilerParticipant READONLY
com.auruspay.manager.issuer.participants.IssuerNotifyParticipant
com.auruspay.manager.issuer.participants.IssuerProtectDebugInfo
com.auruspay.manager.issuer.participants.IssuerProfilerParticipant
head=65768, tail=65764, outstanding=0, active-sessions=100/200,
tps=2, peak=7, avg=1.00, elapsed=1208ms
<profiler>
com.auruspay.manager.acquirer.participants.validation.SchemaValidationParticipant
[1.9/1.9]
prepare: com.auruspay.manager.acquirer.group.TxnRequestTypeSelector
[0.3/2.2]
com.auruspay.manager.acquirer.participants.validation.ValidateTransactionParticipant
[0.8/3.1]
com.auruspay.manager.acquirer.participants.InfinispanParticipant [2.2/5.3]
com.auruspay.manager.acquirer.participants.validation.RequestAuthorizationParticipant
[102.4/107.8]
prepare: com.auruspay.manager.acquirer.group.TxnCardTypeSelector
[0.2/108.0]
com.auruspay.manager.acquirer.participants.validation.BinValidationParticipant
[1.7/109.7]
com.auruspay.manager.acquirer.participants.FillOriginalTransParticipant
[0.0/109.8]
prepare: com.auruspay.manager.issuer.group.ProcessorTypeSelector
[0.3/110.1]
com.auruspay.manager.issuer.participants.ProcessorQueryParticipant
[1.4/111.5]
com.auruspay.manager.issuer.participants.processor.elavon.ElavonCreditParticipant
[1027.0/1138.5]
com.auruspay.manager.issuer.participants.BuildISOResponseParticipant
[55.6/1194.2]
com.auruspay.manager.issuer.participants.IssuerResponseParticipant
[0.8/1195.0]
com.auruspay.manager.issuer.participants.IssuerDirPollParticipant
[9.0/1204.1]
com.auruspay.manager.issuer.participants.IssuerGrayLogParticipant
[0.2/1204.4]
com.auruspay.manager.issuer.participants.IssuerNotifyParticipant
[0.0/1204.4]
com.auruspay.manager.issuer.participants.IssuerProtectDebugInfo [0.0/1204.4]
com.auruspay.manager.issuer.participants.IssuerProfilerParticipant
[0.0/1204.4]
com.auruspay.manager.issuer.participants.IssuerNotifyParticipant
[0.0/1204.5]
com.auruspay.manager.issuer.participants.IssuerProtectDebugInfo [2.9/1207.4]
com.auruspay.manager.issuer.participants.IssuerProfilerParticipant
[0.5/1208.0]
end [0.2/1208.2]
</profiler>
</debug>
</log>
Please let me know if you need more information.
--
*________________________________________________________________________________________________________________________________________________________________*
*Thanks and Regards,*
*Sridhar Jena,* Sr. System Analyst
*+ 91 - 20 - 27655062* | *+ 91 - 9226345267* | *www.aurusinc.com*
<http://www.aurusinc.com/>
*Plot G-2, Sector 26, Pradhikaran, Pune, Maharashtra-411044*
<http://www.aurusinc.com/>
<https://www.facebook.com/pages/Aurus-Inc-Solution-and-Services-Provider/168611626510639>
<https://www.facebook.com/pages/Aurus-Inc-Solution-and-Services-Provider/168611626510639>
<https://twitter.com/aurustech> <https://twitter.com/aurustech>
<http://linkedin.com/company/aurustech>
<http://linkedin.com/company/aurustech>
<https://plus.google.com/100924847781939597025>
*Please consider the environment before printing this e-mail *
Disclaimers: This message contains confidential information and is
intended only for the individual named. If you are not the named addressee
you should not disseminate, distribute or copy this e-mail. Please notify
the sender immediately by e-mail if you have received this e-mail by
mistake and delete this e-mail from your system. E-mail transmission cannot
be guaranteed to be secure or error-free as information could be
intercepted, corrupted, lost, destroyed, arrive late or incomplete, or
contain viruses. The sender therefore does not accept liability for any
errors or omissions in the contents of this message, which arise as a
result of e-mail transmission. If verification is required please request a
hard-copy version.
​Your logging does not look familiar.
What does the Q2 logs show when the profiler dumps values of time take in
the participants?​
How is your QServer configured? Number of threads in the pool?
-chhil
p.s. Please refrain from sending direct emails.

Thanks Chhil for quick reply.
Time is taking only for sending, not for receiving.
After received the transactions through request listener,we are handing
them off to a transaction manager that processes them in a multithreaded
way.
*Below are the logs for 2 transactions:*
*11:30:26:749* AM EDT >> [AurusISOMux.sendMsg(77)] - Sending Request
To Q2 Server(b0f4beae-dc96-408d-9829-d0a672acbad6)...
*11:30:40:292* AM EDT >> ISOMsgRequestDispatcher >> Recieved ISO
Request at Q2 Server from : 204.63.160.197 by PooledThread-10-running
[0.1/0.1]
*11:30:41:487* AM EDT >> IssuerResponseParticipant >> Response Sent to
Client in Prepare [0.0/1194.7]
*11:30:41:487* AM EDT >> Receiving Response From Q2
Server(b0f4beae-dc96-408d-9829-d0a672acbad6)...
*11:30:29,635* AM EDT >> [AurusISOMux.sendMsg(77)] - Sending Request To
Q2 Server(283d3724-6804-4615-97ad-ad00818557f4)...
*11:30:40:294* AM EDT >> ISOMsgRequestDispatcher >> Recieved ISO
Request at Q2 Server from : 204.63.160.197 by PooledThread-10-running
[0.1/0.1]
*11:30:41:902* AM EDT >> IssuerResponseParticipant >> Response Sent to
Client in Prepare [0.0/1607.7]
*11:30:41,902* AM EDT >> [AurusISOMux.sendMsg(79)] - Receiving
Response From Q2 Server(283d3724-6804-4615-97ad-ad00818557f4)...
It is not the issue in Transaction manager, after listened the request
through RequestListener, It is processing immediately and sending the
response.
Time is taking between sending the Request and receiving the request at
Request Listener.
We are processing 1.5m transactions per day ,all transactions are being
processed in some milli seconds, But for some transactions we are getting
this issues.
--
*________________________________________________________________________________________________________________________________________________________________*
*Thanks and Regards,*
*Sridhar*
So sending a tran takes that long or receiving one takes that long?
How is the Qservers requestlistener processing transactions?
Are you processing them in the requestlistener or handing them off to a
transaction manager that processes them in a multithreaded way?
-chhil
--
*________________________________________________________________________________________________________________________________________________________________*
*Thanks and Regards,*
*Sridhar Jena,* Sr. System Analyst
*+ 91 - 20 - 27655062* | *+ 91 - 9226345267* | *www.aurusinc.com*
<http://www.aurusinc.com/>
*Plot G-2, Sector 26, Pradhikaran, Pune, Maharashtra-411044*
<http://www.aurusinc.com/>
<https://www.facebook.com/pages/Aurus-Inc-Solution-and-Services-Provider/168611626510639>
<https://www.facebook.com/pages/Aurus-Inc-Solution-and-Services-Provider/168611626510639>
<https://twitter.com/aurustech> <https://twitter.com/aurustech>
<http://linkedin.com/company/aurustech>
<http://linkedin.com/company/aurustech>
<https://plus.google.com/100924847781939597025>
*Please consider the environment before printing this e-mail *
Disclaimers: This message contains confidential information and is
intended only for the individual named. If you are not the named addressee
you should not disseminate, distribute or copy this e-mail. Please notify
the sender immediately by e-mail if you have received this e-mail by
mistake and delete this e-mail from your system. E-mail transmission cannot
be guaranteed to be secure or error-free as information could be
intercepted, corrupted, lost, destroyed, arrive late or incomplete, or
contain viruses. The sender therefore does not accept liability for any
errors or omissions in the contents of this message, which arise as a
result of e-mail transmission. If verification is required please request a
hard-copy version.

[Non-text portions of this message have been removed]

[chhil [e-mail] [jpos-dev]]

I think a setting of 2 - 4 would be alright, BUT I am seeing a lot of
connect counts by the channel adaptors primary/secondary. I speculate here
but there may be stale connections lingering and having a larger pool count
may not be a bad idea, I repeat, I speculate.

-chhil

I have not found any "pool exhausted " events logged from the servers Q2
log.
Simultaneously maximum/minimum 2 channels will be created/connected to Q2
ISOServer, as we are using two muxes(primary and secondary) overall the
session.
So Is to need to change the minSessions and maxSessions attribute values.
<attr name="minSessions" type="java.lang.Integer">2</attr>
<attr name="maxSessions" type="java.lang.Integer">4</attr>
We are not found the same issues on local environment with above
parameters , Ok we will do your suggested changes in non production hour
and will monitor the same in production environment tomorrow.
*Production Environment Q2 System Monitor*
mux-channel-secondary-adaptor: org.jpos.q2.iso.ChannelAdaptor
tx=0, rx=0, connects=1449, last=0
tspace:derby: org.jpos.space.TSpace
<keycount>-1</keycount>
<gcinfo>0,0</gcinfo>
channel.mux-channel-primary-adaptor: org.jpos.iso.channel.XMLChannel
tspace:oracle: org.jpos.space.TSpace
<key count='2676'>ORACLE_QUEUE</key>
<keycount>0</keycount>
<gcinfo>0,0</gcinfo>
logger.Q2: org.jpos.util.Logger
mux.aurus-mux-pool: org.jpos.q2.iso.MUXPool
Aurus-Q2: org.jpos.q2.iso.QServer
org.jpos.space.TSpace
<key count='1'>$HEAD</key>
<key count='1'>$TAIL</key>
<keycount>1</keycount>
<gcinfo>0,0</gcinfo>
channel.mux-channel-secondary-adaptor: org.jpos.iso.channel.XMLChannel
mux.client-secondary-mux: org.jpos.q2.iso.QMUX
tx=0, rx=0, tx_expired=0, tx_pending=0, rx_expired=0, rx_pending=0,
rx_unhandled=0, rx_forwarded=0, connected=true, last=0
mux-channel-primary-adaptor: org.jpos.q2.iso.ChannelAdaptor
tx=85598, rx=85598, connects=230, last=1439921188296, idle=684ms
mux.client-primary-mux: org.jpos.q2.iso.QMUX
tx=85598, rx=85598, tx_expired=0, tx_pending=0, rx_expired=0,
rx_pending=0, rx_unhandled=0, rx_forwarded=0, connected=true,
last=1439921188296, idle=684ms
tspace:default: org.jpos.space.TSpace
<key count='1'>mux-channel-primary-adaptor.ready</key>
<key count='1'>mux-channel-secondary-adaptor.ready</key>
<keycount>1</keycount>
<gcinfo>0,0</gcinfo>
txnmgr: org.jpos.transaction.TransactionManager
server.Aurus-Q2: org.jpos.iso.ISOServer
*connected=2,* rx=6201, tx=6201, last=1439921188227, idle=753ms
127.0.0.1:39607: rx=6201, tx=6201, last=1439921188227
127.0.0.1:56232: rx=0, tx=0, last=1439921188227
tspace:backoffice: org.jpos.space.TSpace
<keycount>-1</keycount>
<gcinfo>0,0</gcinfo>
--
*________________________________________________________________________________________________________________________________________________________________*
*Thanks and Regards,*
*Sridhar Jena,* Sr. System Analyst
*+ 91 - 20 - 27655062* | *+ 91 - 9226345267* | *www.aurusinc.com*
<http://www.aurusinc.com/>
*Plot G-2, Sector 26, Pradhikaran, Pune, Maharashtra-411044*
<http://www.aurusinc.com/>
<https://www.facebook.com/pages/Aurus-Inc-Solution-and-Services-Provider/168611626510639>
<https://www.facebook.com/pages/Aurus-Inc-Solution-and-Services-Provider/168611626510639>
<https://twitter.com/aurustech> <https://twitter.com/aurustech>
<http://linkedin.com/company/aurustech>
<http://linkedin.com/company/aurustech>
<https://plus.google.com/100924847781939597025>
*Please consider the environment before printing this e-mail *
Disclaimers: This message contains confidential information and is
intended only for the individual named. If you are not the named addressee
you should not disseminate, distribute or copy this e-mail. Please notify
the sender immediately by e-mail if you have received this e-mail by
mistake and delete this e-mail from your system. E-mail transmission cannot
be guaranteed to be secure or error-free as information could be
intercepted, corrupted, lost, destroyed, arrive late or incomplete, or
contain viruses. The sender therefore does not accept liability for any
errors or omissions in the contents of this message, which arise as a
result of e-mail transmission. If verification is required please request a
hard-copy version.
The min of 2 and max of 4 doesnt look correct, any reason why the jpos
defaults of min 1 max 100 are not being used?
I would remove the min max properties from the qserver config.
https://github.com/jpos/jPOS/blob/master/jpos/src/main/java/org/jpos/q2/iso/QServer.java#L57-L58
-chhil

Hi Chhil,
Below are the Q2 Server configuration and profiler details.
*01_serverconfigure.xml*
As we are using 2 muxes for connectivity to Q2 Server, we are configuring
*"2"* minSessions.
<server class="org.jpos.q2.iso.QServer" logger="Q2" name="Aurus-Q2">
<attr name="port" type="java.lang.Integer">&q2Port;</attr>
<attr name="minSessions" type="java.lang.Integer">2</attr>
<attr name="maxSessions" type="java.lang.Integer">4</attr>
<property name="allow" value="&q2Host;" />
<channel class="&q2Channel;" logger="Q2" packager="&q2Packager;">
</channel>
<request-listener
class="com.auruspay.isomsglistner.ISOMsgRequestDispatcher" logger="Q2">
<property name="queue" value="&managerQueue;"/>
<property name="timeout" value="60000"/>
</request-listener>
</server>
*Below are the bench mark log for entry points.*
*Step 1:* Sending Request to Q2 Server
ISOMsg responseISOMsg = aurusMuxPool.request(isoMsg, timeOut);
* 11:30:26:749* AM EDT >> [AurusISOMux.sendMsg(77)] - Sending
Request To Q2 Server(b0f4beae-dc96-408d-9829-d0a672acbad6)...
*Step 2:* Receiving Request at Q2 Server
*public boolean process(ISOSource isoSource, ISOMsg isoMsg)*
* 11:30:40:292* AM EDT >> ISOMsgRequestDispatcher >> Recieved ISO
Request at Q2 Server
*Step 3:* Sending Response from IssuerResponseParticipant
* 11:30:41:487* AM EDT >> IssuerResponseParticipant >> Response Sent
to Client in Prepare [0.0/1194.7]
*Step 4:* Receiving Response at MuxPool
* 11:30:41:487* AM EDT >> Receiving Response From Q2
Server(b0f4beae-dc96-408d-9829-d0a672acbad6)...
*11:30:40:292* AM EDT >> ISOMsgRequestDispatcher >> Recieved ISO Request
at Q2 Server from : 204.63.160.197 by PooledThread-10-running [0.1/0.1]
*Below is the profiler for transaction Manager.*
<log realm="TransactionManager" at="Mon Aug 17 11:30:41.501 EDT 2015"
lifespan="1208ms">
<debug>
txnmgr-87:idle:65763
com.auruspay.manager.acquirer.participants.validation.SchemaValidationParticipant
NO_JOIN
com.auruspay.manager.acquirer.group.TxnRequestTypeSelector NO_JOIN
selector: RequestValidation Infinispan RequestAuthorization
Transaction Processor Issuer_End
com.auruspay.manager.acquirer.participants.validation.ValidateTransactionParticipant
NO_JOIN
com.auruspay.manager.acquirer.participants.InfinispanParticipant NO_JOIN
com.auruspay.manager.acquirer.participants.validation.RequestAuthorizationParticipant
NO_JOIN
com.auruspay.manager.acquirer.group.TxnCardTypeSelector NO_JOIN
selector: BinValidation CreditSale
com.auruspay.manager.acquirer.participants.validation.BinValidationParticipant
NO_JOIN
com.auruspay.manager.acquirer.participants.FillOriginalTransParticipant
NO_JOIN
com.auruspay.manager.issuer.group.ProcessorTypeSelector READONLY NO_JOIN
selector: ElavonCredit
com.auruspay.manager.issuer.participants.ProcessorQueryParticipant NO_JOIN
com.auruspay.manager.issuer.participants.processor.elavon.ElavonCreditParticipant
NO_JOIN
com.auruspay.manager.issuer.participants.BuildISOResponseParticipant NO_JOIN
com.auruspay.manager.issuer.participants.IssuerResponseParticipant READONLY
NO_JOIN
com.auruspay.manager.issuer.participants.IssuerDirPollParticipant READONLY
NO_JOIN
com.auruspay.manager.issuer.participants.IssuerGrayLogParticipant READONLY
NO_JOIN
com.auruspay.manager.issuer.participants.IssuerNotifyParticipant READONLY
com.auruspay.manager.issuer.participants.IssuerProtectDebugInfo READONLY
com.auruspay.manager.issuer.participants.IssuerProfilerParticipant READONLY
com.auruspay.manager.issuer.participants.IssuerNotifyParticipant
com.auruspay.manager.issuer.participants.IssuerProtectDebugInfo
com.auruspay.manager.issuer.participants.IssuerProfilerParticipant
head=65768, tail=65764, outstanding=0, active-sessions=100/200,
tps=2, peak=7, avg=1.00, elapsed=1208ms
<profiler>
com.auruspay.manager.acquirer.participants.validation.SchemaValidationParticipant
[1.9/1.9]
prepare: com.auruspay.manager.acquirer.group.TxnRequestTypeSelector
[0.3/2.2]
com.auruspay.manager.acquirer.participants.validation.ValidateTransactionParticipant
[0.8/3.1]
com.auruspay.manager.acquirer.participants.InfinispanParticipant [2.2/5.3]
com.auruspay.manager.acquirer.participants.validation.RequestAuthorizationParticipant
[102.4/107.8]
prepare: com.auruspay.manager.acquirer.group.TxnCardTypeSelector
[0.2/108.0]
com.auruspay.manager.acquirer.participants.validation.BinValidationParticipant
[1.7/109.7]
com.auruspay.manager.acquirer.participants.FillOriginalTransParticipant
[0.0/109.8]
prepare: com.auruspay.manager.issuer.group.ProcessorTypeSelector
[0.3/110.1]
com.auruspay.manager.issuer.participants.ProcessorQueryParticipant
[1.4/111.5]
com.auruspay.manager.issuer.participants.processor.elavon.ElavonCreditParticipant
[1027.0/1138.5]
com.auruspay.manager.issuer.participants.BuildISOResponseParticipant
[55.6/1194.2]
com.auruspay.manager.issuer.participants.IssuerResponseParticipant
[0.8/1195.0]
com.auruspay.manager.issuer.participants.IssuerDirPollParticipant
[9.0/1204.1]
com.auruspay.manager.issuer.participants.IssuerGrayLogParticipant
[0.2/1204.4]
com.auruspay.manager.issuer.participants.IssuerNotifyParticipant
[0.0/1204.4]
com.auruspay.manager.issuer.participants.IssuerProtectDebugInfo [0.0/1204.4]
com.auruspay.manager.issuer.participants.IssuerProfilerParticipant
[0.0/1204.4]
com.auruspay.manager.issuer.participants.IssuerNotifyParticipant
[0.0/1204.5]
com.auruspay.manager.issuer.participants.IssuerProtectDebugInfo [2.9/1207.4]
com.auruspay.manager.issuer.participants.IssuerProfilerParticipant
[0.5/1208.0]
end [0.2/1208.2]
</profiler>
</debug>
</log>
Please let me know if you need more information.
--
*________________________________________________________________________________________________________________________________________________________________*
*Thanks and Regards,*
*Sridhar Jena,* Sr. System Analyst
*+ 91 - 20 - 27655062* | *+ 91 - 9226345267* | *www.aurusinc.com*
<http://www.aurusinc.com/>
*Plot G-2, Sector 26, Pradhikaran, Pune, Maharashtra-411044*
<http://www.aurusinc.com/>
<https://www.facebook.com/pages/Aurus-Inc-Solution-and-Services-Provider/168611626510639>
<https://www.facebook.com/pages/Aurus-Inc-Solution-and-Services-Provider/168611626510639>
<https://twitter.com/aurustech> <https://twitter.com/aurustech>
<http://linkedin.com/company/aurustech>
<http://linkedin.com/company/aurustech>
<https://plus.google.com/100924847781939597025>
*Please consider the environment before printing this e-mail *
Disclaimers: This message contains confidential information and is
intended only for the individual named. If you are not the named addressee
you should not disseminate, distribute or copy this e-mail. Please notify
the sender immediately by e-mail if you have received this e-mail by
mistake and delete this e-mail from your system. E-mail transmission cannot
be guaranteed to be secure or error-free as information could be
intercepted, corrupted, lost, destroyed, arrive late or incomplete, or
contain viruses. The sender therefore does not accept liability for any
errors or omissions in the contents of this message, which arise as a
result of e-mail transmission. If verification is required please request a
hard-copy version.
​Your logging does not look familiar.
What does the Q2 logs show when the profiler dumps values of time take in
the participants?​
How is your QServer configured? Number of threads in the pool?
-chhil
p.s. Please refrain from sending direct emails.

Thanks Chhil for quick reply.
Time is taking only for sending, not for receiving.
After received the transactions through request listener,we are handing
them off to a transaction manager that processes them in a multithreaded
way.
*Below are the logs for 2 transactions:*
*11:30:26:749* AM EDT >> [AurusISOMux.sendMsg(77)] - Sending Request
To Q2 Server(b0f4beae-dc96-408d-9829-d0a672acbad6)...
*11:30:40:292* AM EDT >> ISOMsgRequestDispatcher >> Recieved ISO
Request at Q2 Server from : 204.63.160.197 by PooledThread-10-running
[0.1/0.1]
*11:30:41:487* AM EDT >> IssuerResponseParticipant >> Response Sent to
Client in Prepare [0.0/1194.7]
*11:30:41:487* AM EDT >> Receiving Response From Q2
Server(b0f4beae-dc96-408d-9829-d0a672acbad6)...
*11:30:29,635* AM EDT >> [AurusISOMux.sendMsg(77)] - Sending Request To
Q2 Server(283d3724-6804-4615-97ad-ad00818557f4)...
*11:30:40:294* AM EDT >> ISOMsgRequestDispatcher >> Recieved ISO
Request at Q2 Server from : 204.63.160.197 by PooledThread-10-running
[0.1/0.1]
*11:30:41:902* AM EDT >> IssuerResponseParticipant >> Response Sent to
Client in Prepare [0.0/1607.7]
*11:30:41,902* AM EDT >> [AurusISOMux.sendMsg(79)] - Receiving
Response From Q2 Server(283d3724-6804-4615-97ad-ad00818557f4)...
It is not the issue in Transaction manager, after listened the request
through RequestListener, It is processing immediately and sending the
response.
Time is taking between sending the Request and receiving the request at
Request Listener.
We are processing 1.5m transactions per day ,all transactions are being
processed in some milli seconds, But for some transactions we are getting
this issues.
--
*________________________________________________________________________________________________________________________________________________________________*
*Thanks and Regards,*
*Sridhar*
So sending a tran takes that long or receiving one takes that long?
How is the Qservers requestlistener processing transactions?
Are you processing them in the requestlistener or handing them off to a
transaction manager that processes them in a multithreaded way?
-chhil
--
*________________________________________________________________________________________________________________________________________________________________*
*Thanks and Regards,*
*Sridhar Jena,* Sr. System Analyst
*+ 91 - 20 - 27655062* | *+ 91 - 9226345267* | *www.aurusinc.com*
<http://www.aurusinc.com/>
*Plot G-2, Sector 26, Pradhikaran, Pune, Maharashtra-411044*
<http://www.aurusinc.com/>
<https://www.facebook.com/pages/Aurus-Inc-Solution-and-Services-Provider/168611626510639>
<https://www.facebook.com/pages/Aurus-Inc-Solution-and-Services-Provider/168611626510639>
<https://twitter.com/aurustech> <https://twitter.com/aurustech>
<http://linkedin.com/company/aurustech>
<http://linkedin.com/company/aurustech>
<https://plus.google.com/100924847781939597025>
*Please consider the environment before printing this e-mail *
Disclaimers: This message contains confidential information and is
intended only for the individual named. If you are not the named addressee
you should not disseminate, distribute or copy this e-mail. Please notify
the sender immediately by e-mail if you have received this e-mail by
mistake and delete this e-mail from your system. E-mail transmission cannot
be guaranteed to be secure or error-free as information could be
intercepted, corrupted, lost, destroyed, arrive late or incomplete, or
contain viruses. The sender therefore does not accept liability for any
errors or omissions in the contents of this message, which arise as a
result of e-mail transmission. If verification is required please request a
hard-copy version.

[Non-text portions of this message have been removed]

[chhil [e-mail] [jpos-dev]]

See http://jpos.org/blog/2014/04/you-want-a-timeout/

Its a good idea to configure a timeout on the channel used by the server.

-chhil

Post by chhil ***@gmail.com [jpos-dev]
I think a setting of 2 - 4 would be alright, BUT I am seeing a lot of
connect counts by the channel adaptors primary/secondary. I speculate here
but there may be stale connections lingering and having a larger pool count
may not be a bad idea, I repeat, I speculate.
-chhil

I have not found any "pool exhausted " events logged from the servers Q2
log.
Simultaneously maximum/minimum 2 channels will be created/connected to Q2
ISOServer, as we are using two muxes(primary and secondary) overall the
session.
So Is to need to change the minSessions and maxSessions attribute values.
<attr name="minSessions" type="java.lang.Integer">2</attr>
<attr name="maxSessions" type="java.lang.Integer">4</attr>
We are not found the same issues on local environment with above
parameters , Ok we will do your suggested changes in non production hour
and will monitor the same in production environment tomorrow.
*Production Environment Q2 System Monitor*
mux-channel-secondary-adaptor: org.jpos.q2.iso.ChannelAdaptor
tx=0, rx=0, connects=1449, last=0
tspace:derby: org.jpos.space.TSpace
<keycount>-1</keycount>
<gcinfo>0,0</gcinfo>
channel.mux-channel-primary-adaptor: org.jpos.iso.channel.XMLChannel
tspace:oracle: org.jpos.space.TSpace
<key count='2676'>ORACLE_QUEUE</key>
<keycount>0</keycount>
<gcinfo>0,0</gcinfo>
logger.Q2: org.jpos.util.Logger
mux.aurus-mux-pool: org.jpos.q2.iso.MUXPool
Aurus-Q2: org.jpos.q2.iso.QServer
org.jpos.space.TSpace
<key count='1'>$HEAD</key>
<key count='1'>$TAIL</key>
<keycount>1</keycount>
<gcinfo>0,0</gcinfo>
channel.mux-channel-secondary-adaptor: org.jpos.iso.channel.XMLChannel
mux.client-secondary-mux: org.jpos.q2.iso.QMUX
tx=0, rx=0, tx_expired=0, tx_pending=0, rx_expired=0, rx_pending=0,
rx_unhandled=0, rx_forwarded=0, connected=true, last=0
mux-channel-primary-adaptor: org.jpos.q2.iso.ChannelAdaptor
tx=85598, rx=85598, connects=230, last=1439921188296, idle=684ms
mux.client-primary-mux: org.jpos.q2.iso.QMUX
tx=85598, rx=85598, tx_expired=0, tx_pending=0, rx_expired=0,
rx_pending=0, rx_unhandled=0, rx_forwarded=0, connected=true,
last=1439921188296, idle=684ms
tspace:default: org.jpos.space.TSpace
<key count='1'>mux-channel-primary-adaptor.ready</key>
<key count='1'>mux-channel-secondary-adaptor.ready</key>
<keycount>1</keycount>
<gcinfo>0,0</gcinfo>
txnmgr: org.jpos.transaction.TransactionManager
server.Aurus-Q2: org.jpos.iso.ISOServer
*connected=2,* rx=6201, tx=6201, last=1439921188227, idle=753ms
127.0.0.1:39607: rx=6201, tx=6201, last=1439921188227
127.0.0.1:56232: rx=0, tx=0, last=1439921188227
tspace:backoffice: org.jpos.space.TSpace
<keycount>-1</keycount>
<gcinfo>0,0</gcinfo>
--
*________________________________________________________________________________________________________________________________________________________________*
*Thanks and Regards,*
*Sridhar Jena,* Sr. System Analyst
*+ 91 - 20 - 27655062* | *+ 91 - 9226345267* | *www.aurusinc.com*
<http://www.aurusinc.com/>
*Plot G-2, Sector 26, Pradhikaran, Pune, Maharashtra-411044*
<http://www.aurusinc.com/>
<https://www.facebook.com/pages/Aurus-Inc-Solution-and-Services-Provider/168611626510639>
<https://www.facebook.com/pages/Aurus-Inc-Solution-and-Services-Provider/168611626510639>
<https://twitter.com/aurustech> <https://twitter.com/aurustech>
<http://linkedin.com/company/aurustech>
<http://linkedin.com/company/aurustech>
<https://plus.google.com/100924847781939597025>
*Please consider the environment before printing this e-mail *
Disclaimers: This message contains confidential information and is
intended only for the individual named. If you are not the named addressee
you should not disseminate, distribute or copy this e-mail. Please notify
the sender immediately by e-mail if you have received this e-mail by
mistake and delete this e-mail from your system. E-mail transmission cannot
be guaranteed to be secure or error-free as information could be
intercepted, corrupted, lost, destroyed, arrive late or incomplete, or
contain viruses. The sender therefore does not accept liability for any
errors or omissions in the contents of this message, which arise as a
result of e-mail transmission. If verification is required please request a
hard-copy version.
The min of 2 and max of 4 doesnt look correct, any reason why the jpos
defaults of min 1 max 100 are not being used?
I would remove the min max properties from the qserver config.
https://github.com/jpos/jPOS/blob/master/jpos/src/main/java/org/jpos/q2/iso/QServer.java#L57-L58
-chhil

Hi Chhil,
Below are the Q2 Server configuration and profiler details.
*01_serverconfigure.xml*
As we are using 2 muxes for connectivity to Q2 Server, we are
configuring *"2"* minSessions.
<server class="org.jpos.q2.iso.QServer" logger="Q2" name="Aurus-Q2">
<attr name="port" type="java.lang.Integer">&q2Port;</attr>
<attr name="minSessions" type="java.lang.Integer">2</attr>
<attr name="maxSessions" type="java.lang.Integer">4</attr>
<property name="allow" value="&q2Host;" />
<channel class="&q2Channel;" logger="Q2" packager="&q2Packager;">
</channel>
<request-listener
class="com.auruspay.isomsglistner.ISOMsgRequestDispatcher" logger="Q2">
<property name="queue" value="&managerQueue;"/>
<property name="timeout" value="60000"/>
</request-listener>
</server>
*Below are the bench mark log for entry points.*
*Step 1:* Sending Request to Q2 Server
ISOMsg responseISOMsg = aurusMuxPool.request(isoMsg, timeOut);
* 11:30:26:749* AM EDT >> [AurusISOMux.sendMsg(77)] - Sending
Request To Q2 Server(b0f4beae-dc96-408d-9829-d0a672acbad6)...
*Step 2:* Receiving Request at Q2 Server
*public boolean process(ISOSource isoSource, ISOMsg isoMsg)*
* 11:30:40:292* AM EDT >> ISOMsgRequestDispatcher >> Recieved ISO
Request at Q2 Server
*Step 3:* Sending Response from IssuerResponseParticipant
* 11:30:41:487* AM EDT >> IssuerResponseParticipant >> Response
Sent to Client in Prepare [0.0/1194.7]
*Step 4:* Receiving Response at MuxPool
* 11:30:41:487* AM EDT >> Receiving Response From Q2
Server(b0f4beae-dc96-408d-9829-d0a672acbad6)...
*11:30:40:292* AM EDT >> ISOMsgRequestDispatcher >> Recieved ISO
Request at Q2 Server from : 204.63.160.197 by PooledThread-10-running
[0.1/0.1]
*Below is the profiler for transaction Manager.*
<log realm="TransactionManager" at="Mon Aug 17 11:30:41.501 EDT 2015"
lifespan="1208ms">
<debug>
txnmgr-87:idle:65763
com.auruspay.manager.acquirer.participants.validation.SchemaValidationParticipant
NO_JOIN
com.auruspay.manager.acquirer.group.TxnRequestTypeSelector NO_JOIN
selector: RequestValidation Infinispan RequestAuthorization
Transaction Processor Issuer_End
com.auruspay.manager.acquirer.participants.validation.ValidateTransactionParticipant
NO_JOIN
com.auruspay.manager.acquirer.participants.InfinispanParticipant NO_JOIN
com.auruspay.manager.acquirer.participants.validation.RequestAuthorizationParticipant
NO_JOIN
com.auruspay.manager.acquirer.group.TxnCardTypeSelector NO_JOIN
selector: BinValidation CreditSale
com.auruspay.manager.acquirer.participants.validation.BinValidationParticipant
NO_JOIN
com.auruspay.manager.acquirer.participants.FillOriginalTransParticipant
NO_JOIN
com.auruspay.manager.issuer.group.ProcessorTypeSelector READONLY NO_JOIN
selector: ElavonCredit
com.auruspay.manager.issuer.participants.ProcessorQueryParticipant NO_JOIN
com.auruspay.manager.issuer.participants.processor.elavon.ElavonCreditParticipant
NO_JOIN
com.auruspay.manager.issuer.participants.BuildISOResponseParticipant NO_JOIN
com.auruspay.manager.issuer.participants.IssuerResponseParticipant READONLY
NO_JOIN
com.auruspay.manager.issuer.participants.IssuerDirPollParticipant READONLY
NO_JOIN
com.auruspay.manager.issuer.participants.IssuerGrayLogParticipant READONLY
NO_JOIN
com.auruspay.manager.issuer.participants.IssuerNotifyParticipant READONLY
com.auruspay.manager.issuer.participants.IssuerProtectDebugInfo READONLY
com.auruspay.manager.issuer.participants.IssuerProfilerParticipant READONLY
com.auruspay.manager.issuer.participants.IssuerNotifyParticipant
com.auruspay.manager.issuer.participants.IssuerProtectDebugInfo
com.auruspay.manager.issuer.participants.IssuerProfilerParticipant
head=65768, tail=65764, outstanding=0, active-sessions=100/200,
tps=2, peak=7, avg=1.00, elapsed=1208ms
<profiler>
com.auruspay.manager.acquirer.participants.validation.SchemaValidationParticipant
[1.9/1.9]
com.auruspay.manager.acquirer.group.TxnRequestTypeSelector [0.3/2.2]
com.auruspay.manager.acquirer.participants.validation.ValidateTransactionParticipant
[0.8/3.1]
com.auruspay.manager.acquirer.participants.InfinispanParticipant [2.2/5.3]
com.auruspay.manager.acquirer.participants.validation.RequestAuthorizationParticipant
[102.4/107.8]
prepare: com.auruspay.manager.acquirer.group.TxnCardTypeSelector
[0.2/108.0]
com.auruspay.manager.acquirer.participants.validation.BinValidationParticipant
[1.7/109.7]
com.auruspay.manager.acquirer.participants.FillOriginalTransParticipant
[0.0/109.8]
prepare: com.auruspay.manager.issuer.group.ProcessorTypeSelector
[0.3/110.1]
com.auruspay.manager.issuer.participants.ProcessorQueryParticipant
[1.4/111.5]
com.auruspay.manager.issuer.participants.processor.elavon.ElavonCreditParticipant
[1027.0/1138.5]
com.auruspay.manager.issuer.participants.BuildISOResponseParticipant
[55.6/1194.2]
com.auruspay.manager.issuer.participants.IssuerResponseParticipant
[0.8/1195.0]
com.auruspay.manager.issuer.participants.IssuerDirPollParticipant
[9.0/1204.1]
com.auruspay.manager.issuer.participants.IssuerGrayLogParticipant
[0.2/1204.4]
com.auruspay.manager.issuer.participants.IssuerNotifyParticipant
[0.0/1204.4]
com.auruspay.manager.issuer.participants.IssuerProtectDebugInfo [0.0/1204.4]
com.auruspay.manager.issuer.participants.IssuerProfilerParticipant
[0.0/1204.4]
com.auruspay.manager.issuer.participants.IssuerNotifyParticipant
[0.0/1204.5]
com.auruspay.manager.issuer.participants.IssuerProtectDebugInfo [2.9/1207.4]
com.auruspay.manager.issuer.participants.IssuerProfilerParticipant
[0.5/1208.0]
end [0.2/1208.2]
</profiler>
</debug>
</log>
Please let me know if you need more information.
--
*________________________________________________________________________________________________________________________________________________________________*
*Thanks and Regards,*
*Sridhar Jena,* Sr. System Analyst
*+ 91 - 20 - 27655062* | *+ 91 - 9226345267* | *www.aurusinc.com*
<http://www.aurusinc.com/>
*Plot G-2, Sector 26, Pradhikaran, Pune, Maharashtra-411044*
<http://www.aurusinc.com/>
<https://www.facebook.com/pages/Aurus-Inc-Solution-and-Services-Provider/168611626510639>
<https://www.facebook.com/pages/Aurus-Inc-Solution-and-Services-Provider/168611626510639>
<https://twitter.com/aurustech> <https://twitter.com/aurustech>
<http://linkedin.com/company/aurustech>
<http://linkedin.com/company/aurustech>
<https://plus.google.com/100924847781939597025>
*Please consider the environment before printing this e-mail *
Disclaimers: This message contains confidential information and is
intended only for the individual named. If you are not the named addressee
you should not disseminate, distribute or copy this e-mail. Please notify
the sender immediately by e-mail if you have received this e-mail by
mistake and delete this e-mail from your system. E-mail transmission cannot
be guaranteed to be secure or error-free as information could be
intercepted, corrupted, lost, destroyed, arrive late or incomplete, or
contain viruses. The sender therefore does not accept liability for any
errors or omissions in the contents of this message, which arise as a
result of e-mail transmission. If verification is required please request a
hard-copy version.
​Your logging does not look familiar.
What does the Q2 logs show when the profiler dumps values of time take
in the participants?​
How is your QServer configured? Number of threads in the pool?
-chhil
p.s. Please refrain from sending direct emails.

Thanks Chhil for quick reply.
Time is taking only for sending, not for receiving.
After received the transactions through request listener,we are handing
them off to a transaction manager that processes them in a multithreaded
way.
*Below are the logs for 2 transactions:*
*11:30:26:749* AM EDT >> [AurusISOMux.sendMsg(77)] - Sending Request
To Q2 Server(b0f4beae-dc96-408d-9829-d0a672acbad6)...
*11:30:40:292* AM EDT >> ISOMsgRequestDispatcher >> Recieved ISO
Request at Q2 Server from : 204.63.160.197 by PooledThread-10-running
[0.1/0.1]
*11:30:41:487* AM EDT >> IssuerResponseParticipant >> Response Sent to
Client in Prepare [0.0/1194.7]
*11:30:41:487* AM EDT >> Receiving Response From Q2
Server(b0f4beae-dc96-408d-9829-d0a672acbad6)...
*11:30:29,635* AM EDT >> [AurusISOMux.sendMsg(77)] - Sending Request
To Q2 Server(283d3724-6804-4615-97ad-ad00818557f4)...
*11:30:40:294* AM EDT >> ISOMsgRequestDispatcher >> Recieved ISO
Request at Q2 Server from : 204.63.160.197 by PooledThread-10-running
[0.1/0.1]
*11:30:41:902* AM EDT >> IssuerResponseParticipant >> Response Sent to
Client in Prepare [0.0/1607.7]
*11:30:41,902* AM EDT >> [AurusISOMux.sendMsg(79)] - Receiving
Response From Q2 Server(283d3724-6804-4615-97ad-ad00818557f4)...
It is not the issue in Transaction manager, after listened the request
through RequestListener, It is processing immediately and sending the
response.
Time is taking between sending the Request and receiving the request at
Request Listener.
We are processing 1.5m transactions per day ,all transactions are being
processed in some milli seconds, But for some transactions we are getting
this issues.
--
*________________________________________________________________________________________________________________________________________________________________*
*Thanks and Regards,*
*Sridhar*
So sending a tran takes that long or receiving one takes that long?
How is the Qservers requestlistener processing transactions?
Are you processing them in the requestlistener or handing them off to a
transaction manager that processes them in a multithreaded way?
-chhil
--
*________________________________________________________________________________________________________________________________________________________________*
*Thanks and Regards,*
*Sridhar Jena,* Sr. System Analyst
*+ 91 - 20 - 27655062* | *+ 91 - 9226345267* | *www.aurusinc.com*
<http://www.aurusinc.com/>
*Plot G-2, Sector 26, Pradhikaran, Pune, Maharashtra-411044*
<http://www.aurusinc.com/>
<https://www.facebook.com/pages/Aurus-Inc-Solution-and-Services-Provider/168611626510639>
<https://www.facebook.com/pages/Aurus-Inc-Solution-and-Services-Provider/168611626510639>
<https://twitter.com/aurustech> <https://twitter.com/aurustech>
<http://linkedin.com/company/aurustech>
<http://linkedin.com/company/aurustech>
<https://plus.google.com/100924847781939597025>
*Please consider the environment before printing this e-mail *
Disclaimers: This message contains confidential information and is
intended only for the individual named. If you are not the named addressee
you should not disseminate, distribute or copy this e-mail. Please notify
the sender immediately by e-mail if you have received this e-mail by
mistake and delete this e-mail from your system. E-mail transmission cannot
be guaranteed to be secure or error-free as information could be
intercepted, corrupted, lost, destroyed, arrive late or incomplete, or
contain viruses. The sender therefore does not accept liability for any
errors or omissions in the contents of this message, which arise as a
result of e-mail transmission. If verification is required please request a
hard-copy version.

[Non-text portions of this message have been removed]

[Sridhar Jena [e-mail] [jpos-dev]]

Thanks Chhil for quick reply.


Time is taking only for sending, not for receiving.
After received the transactions through request listener,we are handing
them off to a transaction manager that processes them in a multithreaded
way.


_Below are the logs for 2 transactions:_


*11:30:26:749* AM EDT >> [AurusISOMux.sendMsg(77)] - Sending Request To
Q2 Server(b0f4beae-dc96-408d-9829-d0a672acbad6)...
*11:30:40:292* AM EDT >> ISOMsgRequestDispatcher >> Recieved ISO Request
at Q2 Server from : 204.63.160.197 by PooledThread-10-running [0.1/0.1]
*11:30:41:487* AM EDT >> IssuerResponseParticipant >> Response Sent to
Client in Prepare [0.0/1194.7]
*11:30:41:487* AM EDT >> Receiving Response From Q2
Server(b0f4beae-dc96-408d-9829-d0a672acbad6)...




*11:30:29,635* AM EDT >> [AurusISOMux.sendMsg(77)] - Sending Request To
Q2 Server(283d3724-6804-4615-97ad-ad00818557f4)...
*11:30:40:294* AM EDT >> ISOMsgRequestDispatcher >> Recieved ISO Request
at Q2 Server from : 204.63.160.197 by PooledThread-10-running [0.1/0.1]
*11:30:41:902* AM EDT >> IssuerResponseParticipant >> Response Sent to
Client in Prepare [0.0/1607.7]
*11:30:41,902* AM EDT >> [AurusISOMux.sendMsg(79)] - Receiving Response
From Q2 Server(283d3724-6804-4615-97ad-ad00818557f4)...


It is not the issue in Transaction manager, after listened the request
through RequestListener, It is processing immediately and sending the
response.
Time is taking between sending the Request and receiving the request at
Request Listener.


We are processing 1.5m transactions per day ,all transactions are being
processed in some milli seconds, But for some transactions we are
getting this issues.
--
*________________________________________________________________________________________________________________________________________________________________*




*Thanks and Regards,*


*Sridhar Jena,* Sr. System Analyst


*+ 91 - 20 - 27655062* | *+ 91 - 9226345267* | *www.aurusinc.com*
<http://www.aurusinc.com/>
*Plot G-2, Sector 26, Pradhikaran, Pune, Maharashtra-411044*


<http://www.aurusinc.com/>


<https://www.facebook.com/pages/Aurus-Inc-Solution-and-Services-Provider/168611626510639><https://www.facebook.com/pages/Aurus-Inc-Solution-and-Services-Provider/168611626510639>
<https://twitter.com/aurustech><https://twitter.com/aurustech>
<http://linkedin.com/company/aurustech><http://linkedin.com/company/aurustech>
<https://plus.google.com/100924847781939597025>


/*Please consider the environment before printing this e-mail */


Disclaimers: This message contains confidential information and is
intended only for the individual named. If you are not the named
addressee you should not disseminate, distribute or copy this e-mail.
Please notify the sender immediately by e-mail if you have received this
e-mail by mistake and delete this e-mail from your system. E-mail
transmission cannot be guaranteed to be secure or error-free as
information could be intercepted, corrupted, lost, destroyed, arrive
late or incomplete, or contain viruses. The sender therefore does not
accept liability for any errors or omissions in the contents of this
message, which arise as a result of e-mail transmission. If verification
is required please request a hard-copy version.

Post by chhil ***@gmail.com [jpos-dev]
So sending a tran takes that long or receiving one takes that long?
How is the Qservers requestlistener processing transactions?
Are you processing them in the requestlistener or handing them off to
a transaction manager that processes them in a multithreaded way?
-chhil

[elijah Olanrewaju [e-mail] [jpos-dev]]

Jena
This article might be of help....
---------------------------------------------------------------------------------------------------------


http://jpos.org/blog/2007/01/parallel-processing/
_______________________________________________________________

Post by '***@aurusinc.com' ***@aurusinc.com [jpos-dev]
Hi,
I am facing connectivity issues(taking more than 14 seconds) when am sending
ISO request to Q2 server for some transactions.
I have a MUXPool consist of two muxes(primary and secondary).
Last time I was using "round-robin" strategy ,but i had faced same problems
more than 1000 transactions per day.
Now I have changed it to "primary-secondary", but still 200 transactions are
taking more than 12 sec for sending request to Q2 Server.
Could you please help me on this if any one have an idea.
Below are the config files,
*07_mux_channel_primary.xml*
<channel-adaptor name='mux-channel-primary-adaptor'
class="org.jpos.q2.iso.ChannelAdaptor" logger="Q2-Mux">
<channel class="org.jpos.iso.channel.XMLChannel" logger="Q2-Mux"
packager="org.jpos.iso.packager.XMLPackager">
<property name="host" value="127.0.0.1" />
<property name="port" value="8081" />
<property name="debug" value="false" />
</channel>
<in>mux-channel-primary-send</in>
<out>mux-channel-primary-receive</out>
<reconnect-delay>10000</reconnect-delay>
<ignore-iso-exceptions>yes</ignore-iso-exceptions>
</channel-adaptor>
*07_mux_channel_secondary.xml*
<channel-adaptor name='mux-channel-secondary-adaptor'
class="org.jpos.q2.iso.ChannelAdaptor" logger="Q2-Mux">
<channel class="org.jpos.iso.channel.XMLChannel" logger="Q2-Mux"
packager="org.jpos.iso.packager.XMLPackager">
<property name="host" value="127.0.0.1" />
<property name="port" value="8081" />
<property name="debug" value="false" />
</channel>
<in>mux-channel-secondary-send</in>
<out>mux-channel-secondary-receive</out>
<reconnect-delay>10000</reconnect-delay>
<ignore-iso-exceptions>yes</ignore-iso-exceptions>
</channel-adaptor>
*08_client_mux_primary.xml*
<mux class="org.jpos.q2.iso.QMUX" logger="Q2" name="client-primary-mux">
<in>mux-channel-primary-receive</in>
<out>mux-channel-primary-send</out>
<key>11.1,11.2</key>
<unhandled>mux-channel-primary-unhandled</unhandled>
</mux>
*08_client_mux_secondary.xml*
<mux class="org.jpos.q2.iso.QMUX" logger="Q2" name="client-secondary-mux">
<in>mux-channel-secondary-receive</in>
<out>mux-channel-secondary-send</out>
<key>11.1,11.2</key>
<unhandled>mux-channel-secondary-unhandled</unhandled>
</mux>
*09_mux_pool.xml*
<mux class="org.jpos.q2.iso.MUXPool" logger="Q2" name="switch-mux-pool">
<muxes>client-primary-mux client-secondary-mux</muxes>
<strategy>primary-secondary</strategy>
</mux>
*10_switch_mux.xml*
<qbean name="switch-mux" logger="Q2" realm="switch-mux"
class="com.switch.context.SwitchISOMux">
<property name="mux" value="switch-mux-pool" />
<property name="timeout" value="180000" />
</qbean>
*SwitchISOMux.java*
public class SwitchISOMux extends org.jpos.q2.QBeanSupport {
private static MUXPool muxPool;
private static long timeOut;
private static String muxName;
private static final org.apache.log4j.Logger LOG =
org.apache.log4j.Logger.getLogger(SwitchISOMux.class);
public SwitchISOMux() {
super();
}
protected void initService() throws ISOException {
muxName = "mux." + cfg.get("mux");
timeOut = cfg.getLong("timeout");
}
protected void startService() {
try {
muxPool = (MUXPool) NameRegistrar.get(muxName);
} catch (NameRegistrar.NotFoundException e) {
LOG.error("NameRegistrar.NotFoundException in startService:",
e);
} catch (Exception e) {
LOG.error("Exception in startService:", e);
}
}
public ISOMsg sendMsg(ISOMsg isoMsg) throws ISOException {
return muxPool.request(isoMsg, timeOut);
}
}
Thanks,
Sridhar Jena
--
http://jpos.1045706.n5.nabble.com/Connectivity-Issue-found-for-MUXPool-mux-strategy-tp5715250.html
Sent from the jPOS - Dev mailing list archive at Nabble.com.