MFP_PERSISTENT_DATA Truncate Issue - ibm-mobilefirst

Using MFP8, I have truncated MFP_PERSISTENT_DATA and MFP_TRANSIENT_DATA of more than 0.8 million records in live.
Currently, iOS users are facing issues and can see the below logs in server. How to rectify the same
ibm.mfp.server.registration.internal.RegistrationServiceImpl E FWLSE4213E: Client JWT authentication failed - public keys do not match com.ibm.mfp.server.security.shared.webtoken.WebTokenException: Invalid signature
ibm.mfp.server.registration.internal.rest.RegistrationEndpoint E FWLSE4225E: Invalid update self registration request, client signature could not be verified com.ibm.mfp.server.security.shared.webtoken.WebTokenException: Invalid signature
ibm.mfp.server.registration.internal.rest.RegistrationEndpoint E FWLSE4224E: Failed to process registration request.
com.ibm.mfp.server.core.shared.MFPRESTException: 400; headers=[]; body={ errorCode=APPLICATION_DOES_NOT_EXIST errorMsg=Application doesn't exist}

Firstly, random deletion of entries from the MFP-PERSISTENT_DATA is not at all recommended thing to do.for any cleanup of tables, we would recommend you to do so via https://mobilefirstplatform.ibmcloud.com/blog/2018/12/27/purge-mfp-runtime-tables/. suggestions given your current scenario is
1) Starting Nov 2018 level of SDK, Intelligence is incorporated in to MFP SDK to take care of such accidental deletions by cleaning up client context and doing fresh registration. If the customer’s application has a client SDK level that takes care of auto registration , this issue would not appear and MFP SDK will recover from the above error scenario by cleaning up and doing fresh registration . As per information provided below, customer is in a older level of SDK and the auto re registration feature requires an SDK level of Nov 2018 or later.
2) Is there a way to backup / restore data which you have truncated ? if you have taken backup / can you restore and follow proper instructions to clean up as updated in the blog above ?
3)Provided there is no way to restore / cannot upgrade their application to a newer level of SDK , options are to manually clear the application cache /uninstall and reinstall of the application which needs end user actions to recover.
4) Another option is to update your application to setServerURL() method upon this error, but this would again need update to application and careful planning to ensure it is added appropriately only to the exact error scenario in the application logic as it clears the client context completely
https://mobilefirstplatform.ibmcloud.com/api-ref/wl-android-n-java-apidoc/html/refjava-worklight-android-native/html/com/worklight/androidgap/api/WL.html#setServerUrl(java.net.URL)

Related

Trigger DAG Run - 403

I am following this tutorial to build a Cloud Function that triggers a DAG run. I have run into a permission issue. Upon the function being triggered and thus trying to run the DAG, I get a permission error message. It reads as follows:
Service account does not have permission to access the IAP-protected application.
I have followed the recommendation in the tutorial to have a service account with the Composer User role. What am I missing?
Note: I am calling Airflow version 2's Stable REST API and my Composer is version 1.
-Diana
I found a perhaps duplicate question here:
Receiving HTTP 401 when accessing Cloud Composer's Airflow Rest API
As Seng Cheong noted in their answer, the reason for this error is that Google Cloud seems to have issues adding service account IDs that are longer than 64 characters to the Airflow list of users. Upon changing my service account ID to one <= 64 characters, I was able to trigger the DAG successfully. If you can't make your service account ID shorter, then Google documentation suggests adding the "numeric user id" corresponding to your service account directly. The steps for how to do so can be found here: https://cloud.google.com/composer/docs/access-airflow-api#access_airflow_rest_api_using_a_service_account
Best of luck friend

Intermittent problems starting Azure App Services: "500.37 ANCM Failed to Start Within Startup Time Limit"

Our app services are experiencing the problem, that they can’t be restarted by the hosting environment (ANCM).
The user is getting the following screen in that case:
Http Error 500.37
Our production subscription consists of up to 8 different app services and the problem can randomly harm one of them ore some of them.
The problem can occur several times a week, or just once a month.
The bootstrapping procedure of our app services is not time consuming.
The last occurrence of the problem has this log entries within the eventlog:
Failed to gracefully shutdown application 'MACHINE/WEBROOT/APPHOST/XXXXXXXXX'.
followed by:
Application '/LM/W3SVC/815681839/ROOT' with physical root 'D:\home\site\wwwroot' failed to load coreclr. Exception message: Managed server didn't initialize after 120000 ms
In most cases the problem can be resolved by manually stopping and starting the app service. In some cases we had to do that twice.
We are not able to reproduce that behavior locally.
The App Service Plan is S2 and we actually use just one instance.
The documentation of the Http error 500.37 recommends:
"You may need to stagger the startup process of multiple apps."
But there is no hint of how to do that.
How can we ensure that our app services are restarted without errors.
HTTP Error 500.37 - ANCM Failed to Start Within Startup Time Limit
You can try following approaches:
Approach 1: If possible, can try to move one app into a new App Service with a separate App Service plan, then check whether it can start as expected.
Please note that creating and using a separate App Service plan would be charged.
Approach 2: Increasing the startupTimeLimit attribute of the aspNetCore element.
For more information about the startupTimeLimit attribute, please check: https://learn.microsoft.com/en-us/aspnet/core/host-and-deploy/aspnet-core-module?view=aspnetcore-3.1#attributes-of-the-aspnetcore-element

re-configuring a worklight application with analytics

After redeploying a worklight application, some configuration for analytics got lost and I'm trying to configure worklight with analytics again.
The dashboard shows "No data available" for time after the deployment although there are old records displayed for the time before the deployment of the application. So the db was not affected.
I set the wl.analytics.logs.forward property to "true" in worklight.properties;
also I set the wl.analytics.url of the db to be something like:
https://myserver:port/analytics/data
The dashboard is on
https://myserver:port/analytics/console
That is the URL for the analytics server.
Although if I put the db URL in a browser I get something like:
Error 404: java.io.FileNotFoundException: SRVE0190E: File not found: /data
Checked SystemOut.log and SystemErr.log (WAS logs) and I did not see errors there.
Does anybody know which is the XML I need to check in order to validate the configuration is OK for analytics? How could I troubleshoot this problem? Are there other logs I could check?
In the list of environment variables you gave I do not see any for username and password. Try to set:
wl.analytics.password=admin
wl.analytics.username=admin
It would be useful to see a wireshark trace, maybe you are not getting 403s. The Analytics data uploader generally has a small bit of protections and you have the option to keep or remove it.
#patbarron is correct about the multiple WAR files though. You need to send your analytics data to the /analytics-service context. The WAR analytics-service is the WAR that handles all the data processing, querying, etc. The other WAR analytics just handles the console UI.
When testing it might be beneficial to lower the
wl.analytics.queue and wl.analytics.queue.size, those values are for collecting data on the MobileFirst runtime server. Data is collected at the runtime server then sent to the analytics server. The larger these values are generally, the longer it will take to send. There are good to set for production

SCVMM: A Hardware Management error has occurred trying to contact server %servername%:a:DestinationUnreachable

Today we found our host status is "Needs Attention".
We have upgraded the WMF 3.0.
And to check the health status and it reports the following error:
A Hardware Management error has occurred trying to contact server
iwwbgc8.dir.slb.com :a:DestinationUnreachable :The WS-Management
service cannot process the request. The service cannot find the
resource identified by the resource URI and selectors. .
Check that WinRM is installed and running on server
iwwbgc8.dir.slb.com. For more information use the command "winrm
helpmsg hresult".
ID: 2927 Details: Unknown error (0x8033803b)
Following the post: How to Interpret Job Failures in VMM and How to troubleshoot the “Needs Attention” and “Not Responding” host status in System Center 2012 Virtual Machine Manager
But the error is still there.
And there does some performance issue in events but by following the post How to manually rebuild Performance Counters for Windows Server 2008 64bit or Windows Server 2008 R2 systems, the performance counter can't not be fixed.
Error:
Installing the performance counter strings for service .NET Data Provider for Oracle (_) failed. The first DWORD in the Data section
contains the error code.
Cannot repair performance counters for .NET Data Provider for Oracle service. Reinstall the performance counters manually using the
LODCTR tool.
Event filter with query "SELECT * FROM __InstanceModificationEvent WITHIN 60 WHERE TargetInstance ISA "Win32_Processor" AND
TargetInstance.LoadPercentage > 99" could not be reactivated in
namespace "//./root/CIMV2" because of error 0x80041003. Events cannot
be delivered through this filter until the problem is corrected.
Unable to read Server Queue performance data from the Server service. The first four bytes (DWORD) of the Data section contains the
status code, the second four bytes contains the IOSB.Status and the
next four bytes contains the IOSB.Information.
Any idea bout it?
Later we found the issue is caused by the WMF 3.0 upgrade.
We follow the post Managing Hyper-V hosts using Virtual Machine Manager fails with Error: 0x8033803b after installing WMF 3.0 and apply the hotfix.
The hotfix (Windows6.1-KB2781512-x64) is applied but the issue still exists.
At last I select the solution to uninstall the WMF 3.0.
And the issue is fixed at last.

Sporadic invalid_request 400 errors connecting to Shopify /admin/oauth/access_token

I am using a java raw HTTP client to connect to Shopify API (specifically, using Play Framework with the non-defualt sync driver which is actually the JDK's default driver).
My application usually manages to connect successfully and convert the temporary access token into a permanent one by calling the /admin/oauth/access_token endpoint.
However, sometimes I get this error result from the API:
Generic Error(400)
{"error":"invalid_request"}
I haven't been able to reproduce the issue with my test stores - I've tried installing a fresh store, reinstalling existing stores after uninstalling, I'm not sure why this call sometimes fail and how to debug it. The API call still continues to succeed for some stores using our application.
Some things that I am doing:
Even if the URL of the store is on a custom domain, I'm always using the https://foo.myshopfiy.com/admin/oauth/access_token URL and not the URL of the custom domain, to prevent a redirect.
I am always using an https URL and never an http one, again to prevent a redirect (we noticed a few issues with redirect with the Java HTTP client, so we aim to have zero redirects)
A thread I found about this error suggest possible problems with our SSL certificates, however I don't think this is my problem because some requests work for us, and the result of running openssl on our machine does't show any issues.
How should I proceed? Open a support ticket with Shopify?
FYI, I see that this specific problem only started yesterday on Feb 19 2013, so it might be a temporary issue.
FYI, the problem was caused by reusing a temporary access code.
Our fault - Shopify could have been more clear in their error message though.