As of yesterday, when I publish the (current) Product and its API, the deployed Assembly is not updated and what is running is from an earlier state - most likely from early December. The APIC domain was created at the end of Nov, so what I is deployed could even be the initial deployment.
As a test, I changed the API's description (add 'XXX') and changed a Gateway script to add XXX to a 'console.warn' at the start of the Assembly. The description change can be seen in Portal, but there is no 'XXX' visible in the DP log. I set DP log level to 'debug', but none of the 'tracing' statements added in Dec can be seen.
Does anyone have any ideas as to how I can resolve this? Or, how can I see the API's deployed code? I've looked in the DP File Management, but everything is dated at then end of Nov.
[EDIT]
Catalogs are in Dev mode, so I change and publish using same version. I have just done a series of tests using the api referred to above (VAT-Num-Check) (which is our first 'real' api) and an older trivial one that just divides two numbers. The Sandbox catalog is associated with the DEV gateway, and the SIT catalog, with the SIT gateway.
The other kind of corruption is, after deploying a new api, calling it results in 404 'No resources match requested URI'.
My conclusions are:
Something has broken in Mgmt server and/or DP APiC Gateway. Once code has been deployed to DP, it can't be changed or deleted. Changes in Portal are correct.
The possible exception is that the deployment of the VAT-Num-check API appears to have reverted to an earlier version after a CLI publish to the SIT Gateway this morning.
[/EDIT]
Background:
I have been creating a Windows script to publish draft Product/APIs and then run Postman tests. This means that I have been performing a lot of publish actions to DP (V5 type). On Monday evening, in my last run, the Postman tests all worked. Yesterday morning, some failed.
Back in early Dec, I made a change so that all JSON error messages in user responses used error as the 'prefix' to the message contents. Before that, some used message and some used reply. The reason for the failures is error messages have reverted to using the earlier 'prefix'.
API Connect 2018.3.7 went out of support on November 15, 2018. You'd need to upgrade to 2018.4.1.x, which will be supported for a longer term.
If you still have the issue at that point, then please open a support ticket for further investigation.
Related
I'm trying to allow my search indexer to connect to a cosmosdb behind a vnet. When adding a shared private access, the provisioning state is set to failed, without giving me an explanation. I have a private endpoint on the CosmosDB setup already. How do I make this work?
I had the same issue occur on the same day as you reported it.
I had been setting up running this connection via Azure Pipelines the day before but suddenly the same Pipeline stopped working.
I raised it as an issue with MS and it was quickly reproduced by the 1st line and passed onto escalation engineers who confirmed there was a recent change in the Fluent SDK used, when we initiate an ARM deployment for Shared Private Link resources we end up specifying both template link and template id (incorrectly/by accident). As a result, customers creating SPL resources are failing to do so with a 500.
I am told there is a world-wide fixed being rolled out and to be completed on Monday pacific time.
I am managing a Google Cloud Composer environment which runs Airflow for a data engineering team. I have recently been asked to troubleshoot one of the dags they run which is failing with this error : [12:41:18,119] {credentials_utils.py:23} WARNING - [redacted-name] connection ID not available, falling back to Google default credentials
The job is basically a data pipeline which reads from various sources and stores data into GBQ. The odd part is that they have a strictly similar Dag running for a different project and it works perfectly.
I have recreated the .json credentials for the service account behind the connection as well as the connection itself in Airflow. I have sanitized the code to see if there was any hidden spaces or so.
My knowledge of Airflow is limited and I have not been able to find any similar issue in my research, any one have encountered this before?
So the DE team came back to me saying it was actually a deployment issue where an internal module involved in service account authentication was being utilized inside another DAG running in stage environment, rendering it impossible to proceed to credential fetch from the connection ID.
My app has been working fine since I changed my free account to a Pay-As-You-Go account but yesterday I started receiving the Access denied due to invalid subscription key error
I haven't changed anything. What can be the source of this error?
Microsoft CRIS servers were experiencing down time starting from ~ 10 pm GMT (according to my observation) on Wednesday 04/19 till 9 am GMT Thursday 14/20. I've experienced problems with log in, deployment access. But some of their servers went back and I was able to log in console. However all my deployments weren't accessible including newly created one. So, as their system went down, you might have problems accessing your deployment. Even if error description is related to invalid subscription key, it might be that issue. It's a new service and I still see 500 Internal errors in console often. If issue is still reproducing, I recommend you to contact their support team crservice#microsoft.com. They are very helpful. However they respond during European working hours.
I have experienced similar issues when we hit the API limits. It would not be a bad idea to check if either the number of requests per second or the volume has been reached ( in case of bootstrap keys it is 1000 hits)
Sometimes when we open folder, Alfresco shows spinning wheel and never opens the folder. The log has below exception.
2016-03-08 11:45:40,652 INFO [webscripts.connector.RemoteClient] [http-bio-8080-exec-494] Exception calling (GET) http://localhost:8080/alfresco/s/slingshot/doclib/treenode/site/test/documentLibrary/Books/science?children=true&max=-1&alf_ticket=TICKET_400a73c20348346eed011695af270f837f27a654
2016-03-08 11:45:40,652 INFO [webscripts.connector.RemoteClient] [http-bio-8080-exec-494] Error status 500 null
ClientAbortException: java.net.SocketException: Connection reset
at org.apache.catalina.connector.OutputBuffer.realWriteBytes(OutputBuffer.java:413)
If I curl the above URL or open directly in webrowser I am able to get the json response successfully.
I am using only Alfresco Share and not anyother client. The localhost:8080 is working perfectly fine in most of the cases except this one.
Can anyone please tell me what is the issue and why connection is closed or ClientAbortException exception is occurring?
Mostly this is an issue of timeout and you'll need active monitoring on your Alfresco & Share environment to see how Alfresco is running.
Easy check is to install some java monitoring or use Jmeter to load test the system and see how it responds on different load.
Mostly the outcome is more CPU/RAM for Alfresco :).
As Tahir Malik mentioned above, the issue is related to performance.
The ClientAbort error itself occurs when the client (in this case, Share) times out or the user cancels a download. The message on the log is type INFO. More details here: https://issues.alfresco.com/jira/browse/ALF-20349
If you are on SSO and using Alfresco Enterprise 5.2.3 or 5.2.4, there is a chance that you may hit a similar bug, which is discussed in the Alfresco Forum. However, this particular bug would not show the ClientAbortException.
I'm trying to use the PayPal Express sandbox (which I have to over 5+ years) and all of a sudden, I'm getting this error. I'm running the latest Chrome on a Windows 2012 server that's up to date. It's happening on the first call to PP using SetExpressCheckout. Where do I start looking for the cause?
After a week of trying to get help from PayPal support, I accidentally came across this link: https://www.paypal.com/webapps/mpp/ssl-security-update that let me to the fix. Support never mentioned it.
The key is to actively use TLS 1.2 in your code. It's not enough to just have your server hardened (we were showing an "A" rating on SSLlabs.com). I put the following immediately before the instantiation of WebClient:
System.Net.ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12
Connected to PayPal without a problem after that.