I have a application used JNI as a linux's lib to finish the communication as a tuxedo client!
as a general transaction for tuxedo client programm,
1. figure out the WSNADDR
5. tpfree tpterm.....
when the tuxedo server running normally, nothing happend. but when the server have some exception, my tpinit block immediately and went on 3 minute till the tperron12 back. I have looked up a large of material about the timeout configuration for tuxedo client , and no hope arised.
My question is how to configure the tuxedo client timeout. that means ,when the configuration take effect, when the service exception happen or network down(can't ping server) , tpinit return -1 immediately according to the timeout configuration .
then I use the tpacall and tpgetrply instead, when I set the flag TPNOBLOCK in tpgetrply, when server blocking, Tperrno = 3 and return immediately. But when the server with no exception, running healthy, it's also Tperrno = 3 happens, and rcvbuf was null, In server's log, the messages for sending and accepting everything in order.
My Goddness, I have no idea what to do, anyone can help me,please~
if you are trying to accomplish a timeout on a client side with tpacall you can use it like this:
} while (lastcallerrno==TPEBLOCK && elapsedTime<MAX_TIME);
else if (timeout)
tpcancel(...) //please read manual page about transaction and tpcancel
While you can probably get a JNI based client to work, please note that Oracle won't support it. The supported options for using Java to access Tuxedo services are Jolt, WebLogic Tuxedo Connector (WTC), Tuxedo JCA Adapter, and SALT (SOAP/HTTP access).
Oracle Tuxedo Chief Architect
Thank you for your suggestion, using JNI is one way to access my system as a simple client used C. I think it is a standard logic to through a C client communicate with C server and so like my application, but it is enough to generate more question about tpinit()，I can't image that the client block will went on 3 minute by tpinit , when the client can't ping to the server, and there is no solution like some available configuration to limit the block time on the client side. It is also be consider that is that essential to make the tpinit work when the client can't touch the server anymore.
I hope someone can give me a specific explaination due to my finite technology in tuxedo. My tuxedo version is 8.1. Thanks!
so you have a Java program that uses JNI to do a single tpinit/tpcall/tpterm? as Todd suggested: there are other options to call tuxedo from
java but you might have to buy additional products. check if you have license and Jolt on the server installation. also tuxedo 8.1 is quite old and mostly unsupported version
anyway going back to the timeout problems: you might also try to do some socket testing: connect to the WSL using non-blocking technique and if
you will find that it succeded - disconnect and connect with tpinit (check that you don't have NAT between client and server).
it makes sense only if you have serious networking problems and you must not hang on sockets
also try to log precise timestamps before and after tpinit/tpcall and you will have data to analyse if something will go wrong
and remember that tpcancel means "I don't care about result" and not "interrupt and rollback this call"
Thank you for your replying. I quitly understand what you say.
at first, my situation is that , the server side lies on other company side, and what the server will happen ,how the server configuring and programming is not my business and hard to estimate, that means there will be more company's system to do the server job. and now my java system is strong enough to route the message to the right one even if a amount of concurrent processing arrived.
so we must do the NAT between client and server to touch the other companys network.
so everything will be called a problem focus on the tuxedo client's blocking,
"Because calling tpinit() is optional when in single-context mode, a single-context client may also join an application by calling many ATMI routines (for example, tpcall())"
please see:http://docs.oracle.com/cd/E13203_01/tuxedo/tux80/atmi/rf3c53.htm, I have used the sycnoized keyword add to the native method as the entry of JNI, and before that , I use the JAVA API to ping the server net.
I think that the exception of network and server process in all the server is not worth to be considered because the servers is not in my company's controll. so Because the WTC and JOLT need some essential conditions for the servers to play up to my client, i may not use them currently.
as your suggestion about tpacall and tpgetreply programming logic , I have made my client's timeout configuring without calling tpinit and through my test. I still have a question about the flag of the tpacall, it should be 0 or TPNOBLOCK.
You say: "when the tuxedo server running normally, nothing happend. but when the server have some exception, my tpinit block immediately and went on 3 minute till the tperron12 back."
What do you mean when the server have some exception? Do you mean the host machine is down? Do you mean the Tuxedo application is down? Do you mean the specific Tuxedo server you were trying to access was down? The timeout for tpinit() for a workstation client is going to be based upon the operating system TCP timeout values assuming it is a network connection issue.
You say: "My question is how to configure the tuxedo client timeout. that means ,when the configuration take effect, when the service exception happen or network down(can't ping server) , tpinit return -1 immediately according to the timeout configuration ."
When tpinit() returns -1, you need to look at the value of tperrno to determine the reason for the failure. As for timeouts, there can be many of them. There is a connection timeout as mentioned above that is determined by the TCP stack and the condition of the remote machine. Tuxedo has little control over this as it is simply performing a socket operation. There is a possible timeout from the authentication server if authentication has been enabled for the Tuxedo domain. This timeout is determined by the BLOCKTIME value. BLOCKTIME determines the amount of time Tuxedo will wait in a blocking call before returning TPETIME indicating the timeout occurred. There are transaction timeouts that are set during the tpbegin() call. There are timeouts (SVCTIMEOUT) the control how long Tuxedo will allow a server to attempt to process a service before deciding the server is hung or looking and kills the server.
When using tpacall() and tpgetrply(), if you set TPNOBLOCK in tpgetrply() and the reply hasn't yet arrived, you will get the TPEBLOCK error immediately as Tuxedo is indicating that it would have blocked your request, but you specified TPNOBLOCK so it didn't block and instead returned TPEBLOCK.
Oracle Tuxedo Chief Architect