Tried to install fresh instance of PT on VM running Linux with following versions:
OS: Linux CentOS 6.5 64bit
Database: Oracle 11.2.0.1 64bit
App Serv: Tuxedo 11gR1 11.1.1.3 64bit RP015
Web Serv: WebLogic 10.3.6
JDK: Jrockit for linux jdk 1.6.0_45 R28.2.7-4.1.0 64bit
PT: 8.51.25
I could:
- start DB, able to connect w SQLPLUS, App Designer, Data Mover
- start App Serv (listening on ports 7000, 9000)
- start Web Serv
- Access to Web Page (Web Serv is running fine)
Once I load PIA login page, I got TPESVCERR error (default setting error).
Same error if i try to login via PIA.
Web Serv Log (same error can be seen repeatedly)
SEVERE psft.pt8.net.NetReqRepSvc sendRequest TPESVCERR - server error while handling request
SEVERE psft.pt8.net.NetReqRepSvc sendRequest An error occurred on the application server within Jolt while running the service. Cancel the current operation and retry. If the problem persists contact your system administrator. Error Code:10
SEVERE psft.pt8.net.NetReqRepSvc sendRequest Application Server last connected //192.168.236.129_9000
SEVERE psft.pt8.auth.WebProfile loadProfile ERROR: WebProfile loading internal default settings because of an Exception while communicating with "192.168.236.129:9000"
SEVERE psft.pt8.auth.WebProfile loadProfile TPESVCERR - server error while handling request
SEVERE psft.pt8.net.NetReqRepSvc sendRequest TPESVCERR - server error while handling request
SEVERE psft.pt8.net.NetReqRepSvc sendRequest An error occurred on the application server within Jolt while running the service. Cancel the current operation and retry. If the problem persists contact your system administrator. Error Code:10
SEVERE psft.pt8.net.NetReqRepSvc sendRequest Application Server last connected //192.168.236.129_9000
SEVERE psft.pt8.util.PIAPerfUtil initializePSPerf PerfMon: Unable to retrieve performance monitor MonitorURL, Reason:Error connecting to AppServer, Ppm JoltSession to 192.168.236.129:9000 not created, reason: bea.jolt.ServiceException: TPESVCERR - server error while handling request
App Serv Log (same error can be seen repeatedly)
PSAPPSRV.3767 (1) [06/25/14 09:29:08 GetCertificate](0) Process aborted.
PSPAL: Abort: Unexpected signal received
PSPAL: Abort: Location: /vob/peopletools/src/pspal/exception_sigaction.cpp:494: RecoverableSignalHandler
PSPAL: Abort: Generating process state report to /db/pt851cfg/appserv/psdb1/LOGS/PSAPPSRV.3983/process_state.txt
PSAPPSRV.4171 (0) [06/25/14 09:29:15](0) PeopleTools Release 8.51.25 (Linux) starting. Tuxedo server is APPSRV(99)/1
PSAPPSRV.4171 (0) [06/25/14 09:29:15](0) Cache Directory being used: /db/pt851cfg/appserv/psdb1/CACHE/PSAPPSRV_1/
PSAPPSRV.4171 (0) [06/25/14 09:29:15](2) App server host time skew is DB+00:00:00 (ORACLE PSDB)
PSAPPSRV.4171 (0) [06/25/14 09:29:15](2) (PreloadMemoryCache) No project name set in the configuration file Cache Settings parameter, PreloadMemoryCache. Nothing to preload into memory cache.
PSAPPSRV.4171 (0) [06/25/14 09:29:15](2) Use FTP Library has value : Y
PSAPPSRV.4171 (0) [06/25/14 09:29:15](0) Server started
PSAPPSRV.3983 (1) [06/25/14 09:29:17 GetCertificate](0) Process aborted.
Tuxedo Log (same error can be seen repeatedly)
092925.PSDB!PSAPPSRV.4357.735041312.0: 06-25-2014: Tuxedo Version 11.1.1.3.0, 64-bit
092925.PSDB!PSAPPSRV.4357.735041312.0: LIBTUX_CAT:262: INFO: Standard main starting
092925.PSDB!PSAPPSRV.4357.735041312.0: LIBTUX_CAT:476: WARN: Server 99/2: client process 3487: lost message
092925.PSDB!PSAPPSRV.4357.735041312.0: LIBTUX_CAT:477: WARN: SERVICE=GetCertificate MSG_ID=0 REASON=server died
I don't think there is any problem with connection between Web Serv and App Serv.
(When i shutdown App Serv, Web Serv will complain of App Serv not available)
From the logs, it appears that PSAPPSRV crashed while working on GetCertificate request.
The debug info says "unable to determine location of exception" which is troubling.
Extract from stack trace:
#0 0x0000003b80ae15e3 in select () from /lib64/libc.so.6
#1 0x00007f3ccafc58f7 in PSPAL::DumpProcessState::CallDebugger(int, char const*, PSPAL::ExceptionContext const*, bool) () from /db/pt851/bin/libpspal64.so
#2 0x00007f3ccafc5bd4 in PSPAL::DumpProcessState::GenerateAbortDiagnostics(char const*, PSPAL::ExceptionContext*) () from /db/pt851/bin/libpspal64.so
#3 0x00007f3ccafba1db in PSPAL::Abort(char const*, char const*, int, char const*, PSPAL::ExceptionContext*) () from /db/pt851/bin/libpspal64.so
#4 0x00007f3ccafbfad1 in PSPAL::SigactionSignalHandler::RecoverableSignalHandler(int, siginfo*, void*) () from /db/pt851/bin/libpspal64.so
#5 0x00007f3ccafc03a5 in PSPAL::SigactionSignalHandler::SignalHandler(int, siginfo*, void*) () from /db/pt851/bin/libpspal64.so
#6 <signal handler called>
#7 0x00007f3cca099f0e in CReadSerialObj::Init(void*) () from /db/pt851/bin/libpscmnutils.so
#8 0x00007f3cca09a275 in CReadSerialObj::CReadSerialObj(EOBJECT_TYPE, void*) () from /db/pt851/bin/libpscmnutils.so
#9 0x00007f3cca09a449 in CReadFrame::CReadFrame(EOBJECT_TYPE, void*) () from /db/pt851/bin/libpscmnutils.so
#10 0x00007f3cc8b33b59 in CNetRecvMsg::CNetRecvMsg(void*) () from /db/pt851/bin/libpsnetapi.so
#11 0x00007f3cc8b3e557 in CNetReqRepSvc::CNetReqRepSvc(CNetServer*, tpsvcinfo*, wchar_t const*) () from /db/pt851/bin/libpsnetapi.so
#12 0x00007f3cc082ce5c in CCertificateService::CCertificateService(CNetServer*, IPSSignonPeopleCode*, tpsvcinfo*) () from /db/pt851/bin/libpssecurity.so
#13 0x00007f3cc082f2a7 in CertificateServiceFactory::Create(CNetServer*, IPSSignonPeopleCode*, tpsvcinfo*) const () from /db/pt851/bin/libpssecurity.so
#14 0x0000000000419235 in CAppServer::GetCertificate(tpsvcinfo*) ()
#15 0x000000000041549d in GetCertificate ()
#16 0x00007f3cccdaca4b in _tmsvcdsp () from /db/tuxedo/tuxedo11gR1/lib/libtux.so
#17 0x00007f3cccdd4146 in _tmrunserver () from /db/tuxedo/tuxedo11gR1/lib/libtux.so
#18 0x00007f3cccdaa42c in _tmstartserver () from /db/tuxedo/tuxedo11gR1/lib/libtux.so
#19 0x000000000040a747 in main ()
Have tried many different configuration settings, no joy. Could it be library compatibility issue?
Any help would be appreciated.
8:51 PT version is only certified for Oracle Tuxedo version 10.3.0.0.0
And you are using version 11g, this may be the problem of crash AppServer.
hope this helps :)
Related
i am trying to create high-level app based on IntercoreComms samples from azsure-sphere-samples, the high level sample code itself it's working w/o issue on my mt3620 dev board, but when i try to add my code on top of it and run it, there is error message as below from high-level app.
ERROR: Unable to create socket: 13 (Permission denied)
and, the error message from RTApp is as below.
TargetName Type Endian TapName State
0* io0 cortex_m little mt3620.cpu unknown
Info : Listening on port 6666 for tcl connections
Info : Listening on port 23 for telnet connections
Info : clock speed 4800 kHz
Info : SWD DPIDR 0x3ba02477
Info : io0: hardware has 6 breakpoints, 4 watchpoints
Info : io0: external reset detected
Info : Listening on port 4444 for gdb connections
Info : accepting 'gdb' connection on tcp/4444
target halted due to debug-request, current mode: Thread
xPSR: 0x61000000 pc: 0x001008ea msp: 0x0012fb90
Warn : target io0 is not halted (gdb fileio)
Polling target io0 failed, trying to reexamine
Info : SWD DPIDR 0x3ba02477
Info : SWD DPIDR 0x3ba02477
Info : SWD DPIDR 0x3ba02477
Info : SWD DPIDR 0x3ba02477
Info : SWD DPIDR 0x3ba02477
To give permission for your high-level app to talk to your real-time app, and vice versa, the "AllowedApplicationConnections" field of the app_manifest.json for each app must contain the component ID of the other app. See here for details. The "ComponentId" is itself a field in the app manfiest: your new app(s) likely have different IDs to the sample apps.
Also, if you are deploying through Visual Studio (Code), you need to declare each app as a 'partner' of the other so one is not deleted when the other is deployed. See here for details of that. The RT app error that you see may come from it being deleted when the high-level app is deployed.
My app does a lot of HTTP requests to a server. After installing a SSL certificate on it, the app broke.
My server is running Ubuntu with Nginx hosting PHP code (using the certificate and working) and "proxy-ing" the app server code written in NodeJS. It was working until I changed to HTTPS.
My POST Request typical usage:
var jsonRequest = //Some JSON.
Map<String, String> headers = {'Content-type': 'application/json'};
var response = await http.post(urls['auth'], body: jsonRequest,headers: headers);
The error I get:
E/flutter (25875): [ERROR:flutter/lib/ui/ui_dart_state.cc(148)] Unhandled Exception: HandshakeException: Handshake error in client (OS Error:
E/flutter (25875): WRONG_VERSION_NUMBER(tls_record.cc:242))
E/flutter (25875): #0 IOClient.send (package:http/src/io_client.dart:33:23)
E/flutter (25875): <asynchronous suspension>
E/flutter (25875): #1 BaseClient._sendUnstreamed (package:http/src/base_client.dart:169:38)
E/flutter (25875): <asynchronous suspension>
E/flutter (25875): #2 BaseClient.post (package:http/src/base_client.dart:54:7)
E/flutter (25875): #3 post.<anonymous closure> (package:http/http.dart:70:16)
...
As #Patrick mentioned in the comments, this is the result of TLS mismatch.
General thumb rule: If the server (API) is based on https (TLS) then the client should connect using https. If the server uses http (non-TLS) then the client should use http to connect to it.
In your case, seems like the API you are trying to hit is an http type hence from your flutter app you should use:
Uri.http(baseUrl, endPointUrl)
I think you are using https:// but havent installed SSL certificate. So try to use http:// instead of https://.
This work in my case.
hope also work on your side.
Add this to your android/app/src/main/AndroidManifest.xml
android:usesCleartextTraffic="true"
the result is this:
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
package="com.example.contact_wsp">
<application
android:label="contact_wsp"
android:usesCleartextTraffic="true"
android:icon="#mipmap/ic_launcher">
<activity
android:name=".MainActivity"
I just upgraded Apache webserver from 2.2 to 2.4. After upgrade, I am getting lot of stuck threads in W mode. I am not using php. The stuck threads are happening even on static html pages or while doing load testing via Jmeter.
Because of these stuck threads, it is reaching the MaxRequestWorkers/MaxClients Limit and server becomes non-responsive. Memory is not an issue. Since even during the server crash I had about 10Gb of free memory.
Just to verify if it is Apache, I swithced it back to 2.2 (old server) and no more hung threads!
ServerTokens OS
ServerRoot "/etc/httpd"
PidFile run/httpd.pid
TimeOut 295
KeepAlive Off
MaxKeepAliveRequests 100
KeepAliveTimeout 15
StartServers 20
MinSpareServers 15
MaxSpareServers 40
ServerLimit 1024
MaxClients 2048
MaxRequestWorkers 2048
MaxRequestsPerChild 5000
MaxConnectionsPerChild 5000
Following is the pstack on one fo the threads:
pstack 30078
#0 0x00007f0c6536df4d in __lll_lock_wait () from /lib64/libpthread.so.0
#1 0x00007f0c65369d02 in _L_lock_791 () from /lib64/libpthread.so.0
#2 0x00007f0c65369c08 in pthread_mutex_lock () from /lib64/libpthread.so.0
#3 0x00007f0c58e53f4b in yodysMtxLock () from /etc/httpd/modules/libdms2.so
#4 0x00007f0c58e518e6 in yodSlotLock () from /etc/httpd/modules/libdms2.so
#5 0x00007f0c58e50266 in yodStateIncrementSb8 () from /etc/httpd/modules/libdms2.so
#6 0x00007f0c597ca764 in wl_increment_state_metric () from /etc/httpd/modules/mod_wl_24.so
#7 0x00007f0c597c5af9 in request_handler () from /etc/httpd/modules/mod_wl_24.so
#8 0x00007f0c668dc290 in ap_run_handler ()
#9 0x00007f0c668dc7d9 in ap_invoke_handler ()
#10 0x00007f0c668f0bca in ap_process_async_request ()
#11 0x00007f0c668f0ea4 in ap_process_request ()
#12 0x00007f0c668ed7f2 in ap_process_http_connection ()
#13 0x00007f0c668e5890 in ap_run_process_connection ()
#14 0x00007f0c58c2280f in child_main () from /etc/httpd/modules/mod_mpm_prefork.so
#15 0x00007f0c58c22a55 in make_child () from /etc/httpd/modules/mod_mpm_prefork.so
#16 0x00007f0c58c22ab6 in startup_children () from /etc/httpd/modules/mod_mpm_prefork.so
#17 0x00007f0c58c237c0 in prefork_run () from /etc/httpd/modules/mod_mpm_prefork.so
#18 0x00007f0c668c25be in ap_run_mpm ()
#19 0x00007f0c668bbb46 in main ()
Any guidance will be helpful.
The particular thread is stuck in the proprietary weblogic plugin waiting on a lock. It's surprising it manages to trigger even on static requests. But it's something you'll need to take up with the vendor, nobody else can debug it.
I am using the following on Linux
MFP 6.3
WAS Libery 8.5.5.6 (core trial)
Tried with JDK1.7 and JDK1.6 but nothing worked out
MySQL
I could not see any other error/exception in messages.log except this and I am not sure where to change the 'timeout' value in WAS Liberty profile.
http://pastebin.com/7uuVtjHL (server.xml)
http://pastebin.com/2ScrUQLa (messages.log)
Exception thrown by application class
'com.worklight.core.auth.impl.AuthenticationFilter.isWaitingForSynchronization:598'
javax.servlet.ServletException: java.lang.RuntimeException: Timeout
while waiting for the management service to start up.120 secs. at
com.worklight.core.auth.impl.AuthenticationFilter.isWaitingForSynchronization(AuthenticationFilter.java:598)
at
com.worklight.core.auth.impl.AuthenticationFilter.doFilter(AuthenticationFilter.java:141)
at
com.ibm.ws.webcontainer.filter.FilterInstanceWrapper.doFilter(FilterInstanceWrapper.java:207)
at [internal classes] Caused by: java.lang.RuntimeException: Timeout
while waiting for the management service to start up.120 secs. at
com.worklight.core.init.WorklightServletInitializer$1.run(WorklightServletInitializer.java:121)
at java.lang.Thread.run(Thread.java:798)
Right now it does seem like you are experiencing the same issue as mentioned here: How to solve management service not starting up in Worklight 6.2
You are currently using IBM Java 1.7 per the messages.log file:
java.home = /usr/lib/jvm/java-1.7.0-ibm-1.7.0.9.0.x86_64/jre
Download Oracle Java 1.7 and make sure your java.home points to it. Start the server and see if there are any differences.
Instead, or in addition, you can try this: https://developer.ibm.com/answers/questions/184195/no-runtime-can-be-found-and-failed-to-obtain-jmx-c.html
In server.xml find the following:
<jndiEntry jndiName="ibm.worklight.admin.jmx.host" value="localhost"/>
Replace "localhost" with the Public IP address of the host machine and start the server.
I have installed latest Zend Server CE in my notebook (it has Win 7 installed) and then
I installed it on my desktop machine. But when you start server controller there is an alert saying Connection refused (or timed out)
What's the problem?
When I start server http://localhost:10081/ZendServer/
the following message appears
Internal Server Error
The server encountered an internal error or misconfiguration and was unable to complete your request.
Please contact the server administrator, admin#example.com and inform them of the time the error occurred, and anything you might have done that may have caused the error.
More information about this error may be available in the server error log.
and apache works well in the following address http://localhost:81
when i telnet localhost 10081 there is a reply !!!
I found from the inet http://forums.zend.com/viewtopic.php?f=8&t=7518 that it's because of not having ipv6 support, I am running windows xp3 on my desktop
how to disable default ipv6 support in Zend conf?
how to fix this problem or should I switch to win 7 (my desktop)?
Thanks in advance!
I had a similar problem, on Debian Squeeze after an upgrade to the currently latest version of Zend from the zend apt repo, [deb http://repos.zend.com/zend-server/deb server non-free] . The Zend gui fails.
zend-server-ce-php-5.3 5.5.0+b63
Log in /usr/local/zend/gui/lighttpd/logs/php.log throws this exception.
[10-Jan-2012 11:20:03] PHP Fatal error: Uncaught exception 'Exception' with message 'Unknown application version' in /usr/local/zend/gui/application/CheckDependencies.php:28
Stack trace:
#0 /usr/local/zend/gui/html/index.php(16): CheckDependencies::getChecker('INSTALLATION_PL...')
#1 {main}
thrown in /usr/local/zend/gui/application/CheckDependencies.php on line 28
The problem is the zend-server.ini file in /usr/local/zend/gui/application/data/zend-server.ini But after doing the changes shown below it seems to work ok again.
--- zend-server.ini 2012-01-05 16:45:29.000000000 +0100
+++ zend-server.ini 2012-01-10 12:01:37.000000000 +0100
## -3,7 +3,7 ##
[zendServer]
version = 5.6.0
-edition = INSTALLATION_PLACEHOLDER_GUI_EDITION
+edition = CE
devEnv=0
This is Zend's default error message, meaning you have some error in the php script you are running. By default, your php.ini file in Zend is configured to report errors, but not specifically state what errors had occurred, which makes this case hard to diagnose. My recommendation is that if you are using this server for debugging purposes, go to your Zend php.ini file (typically C:\Program Files\Zend\ZendServer\etc) and search for "display_errors" and change its default value from "Off" to "On". This will allow you to see the specific error PHP is encountering rather than getting the generic Zend error message.