① java通過WTC調用tuxedo服務,報錯:Could not get a Tuxedo session有人知道什麼原因嗎謝謝
在web.xml中增加session-timeout
<session-config>
<session-timeout>30</session-timeout>
</session-config>
試試～～～
② TUXEDO調服務時，客戶端返回tpcall錯誤：tpforward tpacall failure TPENOENT - no entry found。
Tuxedo介紹 原創
2016-04-02 21:23:02
11點贊
waterxcfg304
碼齡14年
關注
1、Tuxedo介紹
Tuxedo 是什麼？
Tuxedo是BEA公司（現已被Oracle公司收購）的一個客戶機/伺服器的「中間件」產品，它在客戶機和伺服器之間進行調節，以保證正確地處理事務。它用C語言技術開發的並且有很高性能。
TUXEDO是在、Internet 這樣的分布式運算環境中開發和管理三層結構的客戶/伺服器型關鍵任務應用系統的強有力工具。它具備分布式事務處理和應用通信功能，並提供完善的各種服務來建立、運行和管理關鍵任務應用系統。開發人員能夠用它建立跨多個硬體平台、資料庫和操作系統的可互操作的應用系統。
Tuxedo 的主要作用是：
屏蔽分布式環境中各種通信協議、硬體體系結構、操作系統、資料庫和其它應用服務等方面的差異，使分布於網路節點上的應用程序的各個單元部件之間能夠進行互操作，並協調操作的一致性和完整性，最大限度地節省系統資源，提高系統性能。
* Tuxedo 已經廣泛地應用於金融、電信、製造業等各行各業的核心業務系統。
三層架構
從左邊往右依次為：客戶端層（表現層），中間件服務層（業務邏輯層），資料庫伺服器層（數據層）。這種典型的三層架構應用非常廣泛。對於應用weblogic中間件的系統一般採用的B/S架構，絕大部分採用HTTP協議，少量的系統用java編寫的客戶端，使用的是RMI 協議，或J2EE里的其它協議。
對於tuxedo中間件使用的是tuxedo協議，前端開發工具可以是各式各樣，VC++ 、java 、Delphi 、VB 等。
Tuxedo 的通訊過程
Tuxedo 伺服器處理請求的方式與apache有本質的區別。
Apache伺服器處理請求，由客戶端發出請求到伺服器，由伺服器對請求進行處理後將數據返回給客戶端。
Tuxedo 伺服器一次請求需要兩次進行兩次交互，Tuxedo有兩個負責通訊的進程，一個為WSL，WSL的數量可以進行配置，典型的配置一般兩、三個；WSH可以有N多個。客戶端通過IP地址和埠號與WSL建立連接，由WSL認證請求是否合法，在WSL的響應中包含了另外一個IP地址和埠號；然後，客戶端通過拿到的新的IP地址和埠號去請求WSH 。
客戶端程序由GUI 與 Tuxeo通訊兩部分組成，GUI部分主要由開發人員關心如何設計，通訊部分可能設計成幾個函數供開發人員調用。對於性能測試人員可能更關心客戶端與伺服器之間的通訊過程。
2、tuxedo相關概念
IPC: Inter-Process Communication 進程間通信: 管道、信號量（semaphore）、共享內存（shared memory）、消息隊列（Message Queue）。
管道是UNIX系統IPC的最古老形式，數據只能單向流動。
Tuxedo在客戶機和伺服器通信中大量使用UNIX系統的消息隊列。
SSSO(Single Server Single Queue)模式：每個客戶機都有一個響應隊列來接受客戶端請求。
MSSO(Multiple Server Single Queue)模式：多個伺服器共享同一個請求隊列。
信號量包含一個計數器，表示某個資源正在被訪問和訪問的次數，用來控制多線程對共享數據的訪問。
Tuxedo使用共享內存存儲公告牌，用來公告進程狀態信息和需要在進程間共享或傳遞的數據。
-------------------------------------------------------------
Tuxedo的配置文件稱為UBBCONFIG或ubb，包含了域（Domain）、邏輯機器(Machine)、伺服器組(Group)、服務進程(Server)、服務(Service)的定義。運行前，需要把UBBCONFIG裝載成二進制文件，稱為TUXCONFIG。
Tuxedo服務啟動時，執行tpsvrinit()函數，可以打開一些如資料庫之類的資源供以後使用
Tuxedo服務停止時，執行tpsvrdown()函數，關閉資源
服務程序調用tpreturn()函數來結束服務請求，並返回一個緩沖區，必要時，將它傳給客戶程序。
--------------------------------------------------------
ATMI環境支持的C/S通信方式：請求/應答式通信、回話通信、隊列通信、事件代理通信、消息通知
請求/應答式通信：同步調用(tpcall)、非同步調用(tpacall)、嵌套調用、轉發調用(tpforward)
轉發調用和嵌套調用類似，不同的是最里層的嵌套服務可以直接給客戶程序一個響應，而不必按照調用棧 逐級返回。
回話方式：tpsend()/tprecv() 基於事件，分通告和代理
void (**p)(): 定義了一個指向函數指針的指針p
tpsetunsol(p) : 將p指向的函數func設置為客戶機的事件處理器。
tpchkunsol(): 檢查意外事件
事件代理： tppost()/tpsubscribe() 消息發布/訂閱
Tuxedo提供了兩個事件代理器(TMUSREVT TMSYSEVT)來處理訂閱請求。
隊列存儲： tpenqueue() / tpdequeue()
Tuxedo/Q用到了Tuxedo提供的兩個伺服器：消息隊列伺服器(TMQUEUE)和消息轉發伺服器(TMQFORWARD)
---------------------------
多系統多機之間通信需要每台機器上都有一個Bridge進程，通過TCP/IP通信，Bridge進程維持一個長連接，一旦建立不會斷掉。
TUXEDO應用系統的客戶端訪問TUXEDO伺服器上的服務的過程圖:
說明：
WS（Workstation Extension Proct）用於指TUXEDO產品的客戶端部分
WSC Workstation Client
WSL（Workstation Listener） TUXEDO系統自帶的一個SERVER，它偵聽一個指定的埠，WSC最初與該SERVER建立連接
WSH（Workstation Handler）TUXEDO系統自帶的一個SERVER，由它處理WSC與TUXEDO SERVER之間的通訊。
Bulletin Board（公告板）TUXEDO把系統的配置保存在一個共享內存中，該共享內存稱為公告板（BB）
BBL TUXEDO的管理進程，主要對公告板等進行管理
Workstation Client與TUXEDO SERVER建立連接的過程為：
1． WSC 調用tpinit()或tpchkauth()
2． WSC採用在WSNADDR中指定的IP地址與服務端的WSL建立連接
3． WSL為該WSC指定一個WSH，並把該WSH的偵聽埠返回給WSC
4． WSC採用返回的埠與指定的WSH建立連接，並與WSL斷開連接，這之後WSC與TUXEDO SERVER之間的通訊通過WSH進行處理，與WSL無關。
5． tpinit()或tpchkauth()調用返回。
----------------------------------------------------------
單域模式Single-Domain Model。單機模式 Single Host Model, 多機模式Multi-Processor Model
多域模式Multi-Domain Model
③ java通過WTC調用tuxedo服務,報錯:TPESYSTEM(12):0:0:TPED_MINVAL(0):QMNONE(0):0 有人知道什麼原因嗎謝謝
1、TPENOENT(6):0:0:TPED_MINVAL(0):QMNONE(0):0:No local or remote domain available xxx服務
服務沒有調到。
請檢查tuxedo domain 與 weblogic domain連通
請檢查xxx服務在tuxedo中時候存在
查看方式為：
tmadmin
psc -s +服務名
如果是剛注冊的xxx服務，請重現發布所在的WTC服務。如果沒有重新發布，也會報這個錯誤。
如果tuxedo 日誌顯示plicate server，表示有另外一個weblogic domain 配置相同的wtc配置。也就是說 一個Tuxedo domain 對應兩個相同的Weblogic domain，這種情況，也會出現這個錯誤，
請修改另外weblogic domain的wtc配置。（配置相同是指 遠程tuxedo訪問點與本地tuxedo相同）。
如果跨防火牆，請修改連接策略 都改為ON_STARTUP
2、TPESYSTEM(12):0:0:TPED_MINVAL(0):QMNONE(0):0
tuxedo服務有問題或輸入參數不正確。
3、TPESYSTEM(13):0:0:TPED_MINVAL(0):QMNONE(0):0
tuxedo服務返回超過了設置的時間。優化tuxedo服務或修改時間門限。
4、TPESYSTEM(10):0:0:TPED_MINVAL(0):QMNONE(0):0
tuxedo系統問題。報10看下服務，應該有core文件生成。
④ tuxedo 支持java語言開發服務端嗎
tuxedo12c的官方文檔上介紹時可以使用java開發服務的，具體如何開發可以看Programming an Oracle Tuxedo Application Using Java 這一章節。
⑤ C#編寫的tuxedo客戶端能不能訪問java編寫的tuxedo服務端服務
有沒有嘗試打開到伺服器的埠，telnet 192.168.123.84 6677，看看是不是網路問題
⑥ Jolt調用Tuxedo服務，該怎麼處理
對於BEA的中間價產品TUXEDO，常採用C/C++語言編寫後台服務程序，廣泛應用於電信、金融等領域，因項目的需要，我們經常面臨調TUXEDO服務的需求！
對於JAVA調TUXEDO服務，有三種方法：一是通過JNI，二是通過WTC，三是通過JOLT！這三種方式各有優劣，簡單的描述為：
JNI
優--無需購買License；發布TUXEDO服務無需做額外限制；無需藉助於任何J2EE容器
劣--JNI影響系統移植；防止過度JNI帶來性能問題
WTC（WEBLOGIC為TUXEDO定製）
優--因定製，存在一套和TUXEDO API相對應的JAVA API；發布TUXEDO服務無需做額外限制；雙向調用
劣--需要購買License；依賴於WEBLOGIC容器，不能移植到其它J2EE容器（如WEBSPHERE，JBOSS）
JOLT
優--可用於但不依賴於J2EE容器（如WEBLOGICWEBSPHERE，JBOSS）；提供的API用WTC類似但不同；
劣--需要購買License；發布TUXEDO服務有些額外的要求；不提供集成的 WebLogic Server-Tuxedo 事務的機制
由此可知，第一，在受限於License經濟壓力或無法要求UXEDO服務方發布服務的情況下，我們可以選擇JNI方式調TUXEDO服務；
第二，當需要一般 Java 客戶端或其他 Web 伺服器應用程序且 WebLogic Server 不是解決方案的一部分時，用戶應使用 Jolt（而不使用 WTC）作為解決方案。
對於jolt方式調TUXEDO服務，3個必須的JAR包：jolt.jar、joltjse.jar、joltwls.jar，下面信息也許對您有幫助：
[轉貼]不涉及wls的jolt客戶端實現
1、如果不使用wls，同樣可以使用jolt提供的pool功能，而這又分為兩種：一種是基於web容器的servlet jolt
pool，另一種則是普通java客戶端的jolt
pool。前者在$TUXDIR/udataobj/jolt/examples/servlet/simpapp下有示例，後者則未提供。
2、如果不使用jolt產品自帶的pool，也可以自己實現。套路為：創建Jolt Session >
基於此session構建JoltRemoteService對象並發起tuxedo調用 > 釋放jolt
session。這里有個要點就是在使用session前需要用session.isAlive()來判斷當前session是否可用，因為JSL的-T
參數及防火牆對idle連接的干擾都可能導致已有的session是無效的。
3、創建JoltRemoteSession時一定記得為三個超時屬性（IDLETIMEOUT/RECVTIMEOUT/SENDTIMEOUT）進行
顯式的設置。idle超時和tuxedo的JSL
-T屬性對應，該設置將保證session.isAlive()返回正確的布爾值。RECV超時則控制client端自發起call至收到tuxedo
return這一過程的預期時常。
5、tuxedo側在ubb里為相應的service配置了SVCTIMEOUT，所以service執行超時後會收到SIGKILL而被終止，這樣一
來，客戶端的call會收到TPESVCERR錯，對應的異常為bea.jolt.ServiceException。客戶端需要對此異常進行處理，此
外，客戶端捕獲此異常的時間點應當和ulog中該server被kill的時間點對應。
6、在客戶端，時不時會發現由於達到RECVTIMEOUT而導致的客戶端接收超時。客戶的疑問是：當前RECVTIMEOUT設置為25s，而ubb中
相應SVCTIMEOUT設置為10s且scanunit為默認的10s，所以理論上不應發生25s的客戶端RECVTIMEOUT超時。庹達人提出了一
種懷疑，即client端請求抵達tuxedo側時，server出現排隊情況，請求未被及時處理，這個排隊時長決定了20s以外的時間差。對於此，建議
客戶使用MSSQ，並監控pq的情況。
使用XMLink和Jolt實現IBM WebSphere與BEA Tuxedo的互連 第一部分
使用XMLink和Jolt實現IBM WebSphere與BEA Tuxedo的互連 第二部分
下面，我們重點關注下WTC，WebLogic Tuxedo Connector (WTC) 提供了 WebLogic Server 應用程序與
Tuxedo 服務之間的互操作性。WTC 允許 WebLogic Server 客戶端調用 Tuxedo 服務，Tuxedo 客戶端調用
WebLogic Server Enterprise Java Bean (EJB) 來響應服務請求，兩者之間的簡單關聯關系如下圖：
關於WTC的配置原則和最佳實踐可參考下面的鏈接：
配置准則
最佳實踐
為方便記，摘錄過來：
配置准則
在配置 WebLogic Tuxedo Connector 時請使用以下准則：
最佳實踐
以下部分提供了使用 WTC 時的最佳實踐：
請參閱「WebLogic Tuxedo Connector 編程人員指南」中的應用程序錯誤管理。
請參閱「WebLogic Tuxedo Connector 管理指南」中的系統級調試設置。
將 Security 的值設置為 DM_PW。請參閱「WebLogic
Tuxedo Connector 管理指南」中的遠程訪問點的身份驗證。
啟用鏈接級加密並將 min-encrypt-bits 參數設置為
40，將 max-encrypt-bits 設置為 128。請參閱「WebLogic Tuxedo Connector 管理指南」中的鏈接級加密。
在 WebLogic Server 群集的所有節點上配置 WTC 實例。
每個群集節點中的每個 WTC 實例都必須具有相同的配置。
請參閱「WebLogic Tuxedo Connector 管理指南」中的如何管理群集環境中的
WebLogic Tuxedo Connector。
在配置連接策略時，請使用 ON_STARTUP 和 INCOMING_ONLY。
ON_STARTUP 和 INCOMING_ONLY 總是成對出現。例如，如果使用 ON_STARTUP 配置了
WTC 遠程訪問點，則必須將遠程訪問點的 Tuxedo 域配置的 DM_TDOMAIN 部分配置為 INCOMING_ONLY。在此情況下，WTC
總是充當會話發起方。請參閱「WebLogic Tuxedo Connector 管理指南」中的配置訪問點之間的連接。
避免使用連接策略 ON_DEMAND。首選連接策略是 ON_STARTUP 和 INCOMING_ONLY。這樣會減少因路由ON_DEMAND 的語義而引起的服務請求失敗。請參閱「WebLogic
Tuxedo Connector 管理指南」中的配置訪問點之間的連接。
在設計應用程序時，請考慮使用以下 WTC 功能：鏈接級故障轉移、服務級故障轉移和負載平衡。請參閱「WebLogic Tuxedo Connector 管理指南」中的配置故障轉移和故障回復。
請考慮使用 WebLogic Server 群集提供額外的負載平衡和故障轉移。要在 WebLogic Server 群集中使用 WTC，請執行下列操作：
如果 WTC 到 Tuxedo 的連接使用了 Internet，則要使用以下安全設置：
應用程序邏輯應該提供機制來管理和解釋應用程序中的錯誤條件。
避免在 TypedFML32 緩沖區內使用嵌入的 TypedFML32 緩沖區。請參閱「WebLogic
Tuxedo Connector 編程人員指南」中的將 FML 用於 WebLogic Tuxedo
Connector。
如果應用程序處理重負載，請考慮配置更多的遠程 Tuxedo 訪問點並讓 WTC 平衡訪問點之間的工作負載。請參閱「WebLogic Tuxedo Connector 管理指南」中的配置故障轉移和故障回復。
在使用事務應用程序時，盡量讓同一事務中涉及的遠程服務能夠從同一遠程訪問點訪問。請參閱「WebLogic Tuxedo Connector 編程人員指南」中的 WebLogic
Tuxedo Connector JATMI 事務。
從網關調度服務時，可用的客戶端線程數可能會限制運行的並發服務數。沒有任何 WebLogic Tuxedo Connector 特性可以增加可用線程的數量。在調用服務時請使用合理的線程模型。請參閱「配置
WebLogic Server 環境」中的線程管理和使用工作管理器優化調度的工作。
WebLogic Server 9.2 及更高版本提供了改進的路由演算法，這增強了事務性能。具體說就是，當 2 階段提交 (2PC) 事務中具有不止一項 Tuxedo 服務請求時，性能就會相應提高。如果應用程序僅向
Tuxedo 域執行單個服務請求，則可以通過設置以下 WebLogic Server 命令行參數來禁用此功能：
通過在緩沖區中使用最大數量的對象來調用構造方法 TypedFML32。即使是很難預測最大數量，提供合理的數量也可以提高性能。可以通過將欄位的數量乘以
1.33 得到近似的最大數量。
注意：
注意，此性能提示不應用於 TypedFML 緩沖區類型。
例如：
如果在 TypedFML32 緩沖區類型中有 50 個欄位，那麼最大數量就是
63。調用構造方法 TypedFML32(63, 50) 比 TypedFML32() 執行得更好。
如果在 TypedFML32 緩沖區類型中有 50 個欄位，並且每個欄位最多可以有
10 個事件，則調用構造方法 TypedFML32(625, 50) 將會有比 TypedFML32() 更好的性能。
當配置 Tuxedo 應用程序（這些應用程序可以作為與 WTC 客戶端互操作的伺服器）時，請考慮平行問題，這一點可以通過在不同 Tuxedo 計算機上仔細配置不同伺服器來實現。
要知道在 Tuxedo 應用程序中可能會存在資料庫訪問死鎖現象。可以通過認真配置 Tuxedo 應用程序來避免死鎖現象。
如果正在使用 WTC 負載平衡或服務級故障轉移，BEA 建議不要禁用 WTC 事務關系。
針對負載平衡出站請求，為導入服務配置使用不同密鑰的多個條目。導入服務將使用復合密鑰來確定每個記錄的唯一性。復合密鑰的構成：服務名稱 + 本地訪問點 + 遠程訪問點列表中的主要路由。
下面是一個如何為 service1 在 TDomainSession(WDOM1,TUXDOM1) 和TDomainSession(WDOM1,TUXDOM2) 之間正確配置負載平衡請求的示例：
ResourceName
LocalAccessPoint
RemoteAccessPointList
RemoteName
service1
WDOM1
TUXDOM1
TOLOWER
service1
WDOM1
TUXDOM2
TOLOWER2
下面是一個錯誤配置負載平衡請求的示例。下面的配置會導致 service1 具有相同的復合密鑰：
ResourceName
LocalAccessPoint
RemoteAccessPointList
RemoteName
service1
WDOM1
TUXDOM1
TOLOWER
service1
WDOM1
TUXDOM1
TOLOWER
在建立連接/會話前更改該會話/連接配置（本地 AP、遠程 AP、密碼和資源）：
接受更改並在新的會話/連接中實現這些更改。
在建立連接/會話後更改該會話/連接配置（本地 AP、遠程 AP、密碼和資源）：
接受更改，但是要到連接斷開並重新連接後，才在現有的連接/會話中實現這些更改。請參閱「管理控制台聯機幫助」中的定位
WTC 服務。
更改導入和導出服務配置：
接受更改並在下一個入站或出站請求中實現這些更改。BEA 建議不要使用此做法，因為這會讓正在進行的請求處於未知狀態。
更改 tBridge 配置：
對已部署的 WTC 服務進行任何更改都會導致異常。在進行任何 tBridge 配置更改前都必須先取消對 WTC 服務的定位。在取消定位和進行配置更改後，必須定位 WTC 服務以便實現更改。
在配置中可以有多種 WTC 服務。
只能將一種 WTC 服務定位到伺服器實例。
WTC 不支持連接緩沖池。WTC 通過單個物理連接多路傳輸請求。
配置更改可按照如下方式實現：