My app is unable to access the server after about 30 minutes in background on Android phone and iPhone.
I know it should be related to the serverSessionTimeout. However, I cannot connect to server any more after that occurred, and I tried to invoke "WL.Client.connect()", but it didn't work. I always got request timeout response.
I test my app on local (without DMZ) via Worklight Studio embedded server, and it worked fine. Only get this issue on UAT (DMZ) and PROD (DMZ).
Project architecture:
1. DMZ (IBM IMC/LMC)
2. LAN
3. Worklight 6.0
4. Production environment
5. No Load Balancer and cluster setup
My assumption:
1. it seems the DMZ kept the credential between DMZ and WL server and didn't refresh it when try to connect WL server again after WL session is timeout.
This issue is fixed now.
The root cause is because we sent out two requests to WL server going through IMC at the same time, only the second one shake hands with WL server successfully.
Related
I created an ASP.NET Core Web API and deployed it in Azure as an App Service.
I created a Hybrid Connection and installed the Hybrid Connection Manager on the On-Premise Database Server, set the Hybrid Connection Status to Connected (Successfully connected the App Service with On-Premise Db Server).
When sending Get Request or accessing the Web API on the web browser or Postman
The Result I receive is:
500 - The request timed out. The web server failed to respond within
the specified time.
When developing the Web API on my local machine it works smoothly and I could connect to the On-Premise through a VPN connection.
I also added this piece of code
services.AddDbContext<RepositoryContext>(o => o.UseSqlServer(connectionString, sqlServerOptionsAction: sqlOptions =>
{
sqlOptions.EnableRetryOnFailure(
maxRetryCount: 5,
maxRetryDelay: TimeSpan.FromSeconds(60),
errorNumbersToAdd: null);
}));
In the absence of more information, the 500 error, I guess the most likely reason is that there is a problem connecting to the On-Premise sql server.
TroubleShooting:
Click Diagnose and solve problems to view Application Event Log to view specific logs.
(Optional) Open Application Logging (Filesystem) and Detailed error message.
Specifically, you can log in to the scm website to view the error log.
If you test the interface and connect to the database locally or using vpn, there is definitely no problem. Now the problem must be the database connection part. It is recommended to recheck Hybrid connections. You also can raise a support ticket on portal, let them check logs and help you.
Related Posts:
1. Hybrid Connection Shows “Connected”, but Application Fails to Connect
2. Azure Web App Hybrid Connection Failing
Problem
The Hybrid Connection's Endpoint/Host I made in Azure had a different name as the SQL server. I named the endpoint randomly instead of giving it the actual name/IP address.
Additional info
Even if you installed the Connection Manager on the Server and the Status is set to Connected, this doesn't mean that your App Service will communicate with the Database.
Solution
Create a new Hybrid Connection and set the Endpoint Host name with the actual name/IP address, where the Hybrid Connection Manager is installed.
We have SignalR Core running in IIS and the connections are not being closed over time.
This results in a 503 error:
HTTP Error 503.2 - Service Unavailable
The serverRuntime#appConcurrentRequestLimit setting is being exceeded.
When recycling the apppool the Current Connections will drop to 0 and then back up to around 50 (as actual clients reconnect). Over the course of a day it can easily reach 2000. Not every connection is leaking - the number does decrease but trends upwards over time.
Latest .NET Core 3.1 is installed.
We are using Argo Tunnel which creates a tunnel from our webserver to the Cloudflare network.
Turns out it was an out of date cloudflared executable.
The version we were running was from 5/2019 and updating to the new version from 12/2019 has fixed the problem. In fact when stopping the cloudflare service all the connections instantly dropped away.
I need to have an Android app where I use a proxy URL to connect to our MFP 8.0 server. When I make an android build without proxy pointing directly to the MFP server the app registers in the server and I am able to see the push notification in my device.
But when using a proxy in the config.xml the app is able to reach the server but returns an error on the step where I do WLAuthorizationManager.obtainAccessToken.
This is the error:
errorCode:"201"
errorMsg:"Created"
responseText:"{"server_version":"8.0.2017081900"}"
status:201
statusText:"Created"
I am using IBM MobileFirst 6.3, with Apple, Android, Blackberry and Windows Environments.
I have enabled Push Notifications for Apple, Android and Windows environment. I mistakenly uploaded application with sandbox certificate on my production server. On noticing the mistake, I removed the version with Sandbox certificate and uploaded the production certificate version properly and restarted the Websphere Liberty server.
After the restart, push notification is NOT WORKING for any platform.
Earlier I got APNS SSL connection error in my logs, but now I can not see any Push related error in my logs, I enabled trace on com.ibm.pushworks.server.notification.apns.*=all, and still got nothing back.
The only error I get is of could not piggyback ... , which I believe even IBM is suggesting to suppress. I have attached the finest level trace here
I have checked through Wireshark, and server receives request on HTTP GET method and replies with status 200. But what happens after that is a mystery.
P.S. The push notification worked once while the SandBox certificate version was enabled, but didn't work after the restart at all.
#eshaa when you use to change in certificate related settings in client side code you need to take new build i means new .wlapp files to be upload to the server then it will be effect whatever changes you done.
I have installed Worklight 6.2 on Linux, using Liberty 8.5.5 and DB2 10.5. Created the DB2 databases for WRKLGHT and WLREPORT. Have executed the Server Configuration Tool and successfully created a Worklight Server configuration (did not have any errors in the Console view when running the Ant tasks, tables were created successfully in the database, and configuration shows deployed status in the SCT). Created a runtime environment in the SCT, also seemed to succeed (no errors in Console view, tables created/updated, runtime environment shows deployed in the SCT). Stopped and restarted the Liberty server.
Can hit Worklight admin at (/worklightconsole) and log in successfully using my demo user, however it then indicates there are no runtime environments. When trying to access runtime environment at /worklight/console (which should be the correct URL given how I created the runtime config in SCT using my Worklight project WAR), I get various errors: first "Service unavailable since initialization is not yet complete." then after retrying for about a minute or two I get "javax.servlet.ServletException: java.lang.RuntimeException: Timeout while waiting for the management service to start up at com.worklight.core.auth.impl.AuthenticationFilter.isWaitingForInitialization(AuthenticationFilter.java:561)".
Seems the management service is not starting up successfully. Upon reviewing the messages.log I see the following error precede it: "FWLSE0242E: Failed to synchronize application runtime information. The servlet initialization failed and the servlet will deny serve. The most common reason is a failure in JMX communication with the ''worklightadmin'' service. You need to restart the web application after fixing the problem. [project worklight]" and this creates an FFDC log.
I know this is a lot of information but trying to be complete. Anything I should check to fix the JMX communication issue and get the management service starting?
Thank you for the replies back. Turns out there is an issue with Liberty (I was on 8.5.5.0) and the IBM JDK I was using (1.7_64). Swapped out to the Oracle JRE (1.7.0_60-b19), pointed Liberty to use it, and the problem was solved. I am pursuing a fix with the Liberty team through IBM Support for this issue.
I cannot give a unique solution, but I can explain the situation and this may lead to a solution.
The runtime servlet initialization tries to contact the Worklight Admin service. The Worklight Admin service is a web application that must be running when the runtime starts. The runtime was not able to find the Worklight Admin service. It waited a while, in case that the Worklight Admin service is just starting up, but then gave up due to a timeout because within a given time, it could not find the Worklight Admin service.
Possible reasons:
the web server is not at all configured to run the Worklight Admin service. In your case, this seems not the problem, since you can access the Worklight Console. You should also see in the log file whether the Worklight Admin service did start.
the worklightadmin service might never start up ... this could be a configuration problem, e.g. with the WLADMIN data base. This could also be detected from the server logs.
when the runtimes and the Worklight Admin service start up together, it might be that the Worklight Admin service simply takes too long to start. Let's say you have 100 webapps, and the runtime starts first and the Worklight Admin service starts last, it could be that the 98 other webapps take too much time to start. In that case, make your web server lighter ... run only Worklight on that webserver, nothing else.
the Worklight Admin service starts, but the runtime cannot communicate with it. This indicates that the JMX communication is misconfigured. Follow the documentation of the webserver how to configure JMX. For liberty, see http://www-01.ibm.com/support/knowledgecenter/SSD28V_8.5.5/com.ibm.websphere.wlp.core.doc/ae/twlp_admin_restconnector.html?cp=SSD28V_8.5.5%2F1-5-2-10-1&lang=en