I'm trying to process a bunch of payloads (requests) with API Manager testing in postman am getting only one response payload and other payloads am getting fault message like,"Currently Address endpoint : [ Name : **********API--v1.0.0_APIproductionEndpoint State : SUSPENDED ]".
I am struck with this issue could you please how one of them look give me the answer and I need a way to test the bunch of payloads at a time without timeout exception and Address endpoint suspend error.
The backend endpoints are suspended when they can't be reached for some reason. You should look at the log to see what the exact reason is. You need to look for the error logs printed before suspension logs.
And if you want to disable suspension at all, you can follow this doc.
https://docs.wso2.com/display/AM260/Prevent+API+Suspension
Related
I have a simple PHP script (using Botman) called by my Telegram bot via a webhook. It's supposed to respond on receiving a keyword. This works, sending response messages to my phone.
Randomly however it repeats the messages, without any input. Though random, its so frequent I would estimate it does this at least 10 times per minute.
Thinking this could be due to some web bots calling my URL, I modified the script to check the presence (and value of) and query parameter and all random messages stopped. The web bots wouldn't know this secret parameter, right?
As expected, once I updated the PHP script (without updating Telegram with the modified webhook), the messages stopped. So far so good.
Next, updated the Telegram with the webhook containing the secret query parameter, then waited 5 minutes. No messages: still looking good.
Alas, once I send my keyword, it gives the expected response but then keeps repeating endlessly again.
Where do I look to fix this?
Ps. To test, the script also returns general info of the user. I can see it keeps returning my info in the repeated message, as if I made each request. Could this be a bug with Telegram?
According to your description, it seems that your webhook architecture it still looking for the most recent updates returned by Telegram getUpdates method: if your script repeats answering to the same exact message, it means that it's receiving the same exact update object more than one time.
A good solution to solve this problem could be have a look at the webhook working of, how it communicates with Telegram servers in order to understand how does it handle updates received from the Telegram Chatbot itself.
As the title suggests, I have an API Manager that is unsuccessfully reaching out on port 9099 multiple times per second and filling up the wso2carbon.log (as seen below)
I do not have any websocket APIs published so I'm unsure what endpoint it's looking for. We tried commenting out the ws_endpoint in the apim.gateway.environment block of the deployment.toml but that did not produce any perceptible changes. Any help would be greatly appreciated.
UPDATE: I have noticed whenever I shut down API manager, this stack trace below appears. It is failing to destroy this Inbound endpoint, and then tries to recreate it after the service starts, but says it already exists (so any changes on the websocket endpoint configs do nothing)
I was developing Instant triggers for my Integromat app. I finished 2 of them, and when I started the third one, all webhooks stopped working.
I wrote a mail to the support of about the situation and received the answer:
We can see in logs that webhooks fired from our end but your system
returned us error 400 - it means that webhook works on our side but
was not properly received on your servers side.
So why Integromat can answer 400 code? Is it a bug or my mistake? From that moment, I have tried with the new account, but the issue is still there.
Any suggestions?
Judging by the response you received from the 3rd-party tech support, there's an error somewhere in your webhook code.
The first thing I'd check is of course the code directly inside your webhook's Communication tab, but also, if this code is calling any IML functions you wrote, you'll need to double-check that the IML code is not failing as well.
You could create an IML test using the Integromat Apps SDK VS Code plugin to simulate the function call with incoming JSON data (according to the documentation of the service you are implementing) and see if this call results in some kind of an unexpected error.
I'm trying to send Json payload from WSO2 API Manager to ESB, for the 1st hit its working fine and for the second hit its throwing 101504 Error. Similarly, not only for the 2nd hit its repeating the same if I'm trying to hit the service multiple times. Tried giving small and big payload but the Error is same. I can find through the logs only half payload is sent to ESB in failure cases. Is there any solution/input for these kind of issues?
Note : In both server(APIM 2.6, ESB 6.5) chunking is enabled
With the available information, it is difficult to determine the exact cause of the issue. Since it is working without any issue for the first request, it might be related to the connections made with the server. With the available information, I could suggest you try to apply the following property before the call to the APIM [1].
<property name="NO_KEEPALIVE" scope="axis2" value="true"/>
If you continue to observe the issue, it is better to investigate further through a TCP dump.
[1]-https://docs.wso2.com/display/ESB500/HTTP+Transport+Properties#HTTPTransportProperties-NO_KEEPALIVE
While using google cloudVision services we have a need to track individual requests made and the response. Is there a way I can generate an ID as a memo field to every request I make to the CloudVision API & read it in the usage logs/ billing statement?
I can get close to this with timestamps- but with concurrent usages and latencies, mapping can get challenging. Along with reconciliation, this will also help track error codes and reasons
I am wondering whether you can log every request which has error yourself?
You may sending request in parallel in multiple thread, but in each thread you can just write the request and its result to a GCS bucket to record the log.