I am creating a Datapower MPGW which will send a SOAP/MQ Request. I have created a stub backend which will hold and not return any response in order to try simulate a timeout for testing purposes.
The issue I'm facing is the following, all with the same timestamp eg. 11:14:28
"Issuing a request to URL: dpmq://xxx/?RequestQueue=yyy, with a size of 100 bytes"
"No reply for URL: dpmq://xxx/?RequestQueue=yyy will be processed."
"Received a reply from URL: dpmq://xxx/?RequestQueue=yyy, with a size of 0 bytes"
To my knowledge my stub does not reply (one way i am ensuring this is by keeping the debugger on my IIB Stub holding the process preventing the response)
Perhaps as i am new i am not understanding, but i was expecting my Servers timeout to eventually kick in and my response/error flow to start. However due to this instant 0byte reply, it does not seem to happen.
What could be causing this 0-Byte Response?
How can i stop this from happening?
Thanks
Related
I have long operation, which called via Web API. Status code 102 says to us:
An interim response used to inform the client that the server has
accepted the complete request, but has not yet completed it.
This status code SHOULD only be sent when the server has a reasonable
expectation that the request will take significant time to complete.
As guidance, if a method is taking longer than 20 seconds (a
reasonable, but arbitrary value) to process the server SHOULD return a
102 (Processing) response. The server MUST send a final response after
the request has been completed.
So, I want to return 102 status code to client, then client waits response about result of operation. How to implement it on .NET?
I read this thread: How To Return Http 102 Processing in Asp.Net Web Api?
This thread has good explanation what is necessary, but no response. I don't understand how it implement on .NET, not theory...
Using HTTP 102 requires that the server send two responses for one request. ASP.NET (Core or not) does not support sending a response to the client without completely ending the request. Any attempt to send two responses will end up in throwing an exception and just not working. (I tried a couple different ways)
There's a good discussion here about how it's not actually in the HTTP spec, so implementing it isn't really required.
There are a couple alternatives I can think of:
Use web sockets (a persistent connection that allows data to be sent back and forth), like with SignalR, for example.
If your request takes a long time because it's getting data from elsewhere, you can try pulling in that data via a stream and send it to the client via a stream. That will send the data as it's coming in, rather than loading it all into memory first before sending it. Here's an example of streaming data from a database to the response: https://stackoverflow.com/a/45682190/1202807
I've got following error while trying to send a message to a specific telegram channel:
TimedOut: Timed out
The read operation timed out
the method which I used from python-telegram-bot was send_message.
Although my bot got this error but it still sent the message to the channel and because I did not catch that exception all data from the message was lost but I really need to remove my messages from that channel after a specific period of time.
Is this OK that the bot sent the message even though it got Timed Out? How can I prevent this from happen again or remove this kind of messages from the channel after being sent?
Time out errors mean that TG didn't send a response to your send_message request quick enough. It does not necessarily mean that the request wasn't processed - that's why the message may still be sent. However, without response from TG, you don't have the message id of the resulting message and it will be hard to impossible to delete it.
You can try to increase the time that PTB waits for a response from TG. THis can be done in different ways:
with the timeout parameter of send_message
with Defaults.timeout, if you're using PTBs Defaults setup
by specifying it via the request_kwargs that you pass to Updater
You may want to have a look at this wiki page on networking.
Disclaimer: I'm currently the maintainer of python-telegram-bot
After a couple of hours reading here and there, and passing timeout=30 to context.bot.send_audio and getting an error that says unknown parameter even though send_audio's docs clearly states it takes a timeout param, I found that you can fix this by passing the timeouts to the Application upon building it:
application = ApplicationBuilder()
.token(bot_data["token"])
.read_timeout(30)
.write_timeout(30)
.build()
This fixed my bot. Hope this helps you as well.
Is there a module or a built-in function in apache which I can use/activate to send information how long it took to retrieve/process a resource?
For example the resource http://dom.net/resource is accessed. The response header will include the total time it took to wait for the resource to be ready before it gets sent back to the client.
Apache doesn't really 'wait' until the resource is ready before sending the response back to you - it streams data back to the client as and when it receives it.
Depending on what you're interested in measuring, you could record the time taken for the client to receive the first byte/last byte back from Apache, or measure the time taken for Apache to receive the first byte from the (remote?) resource like so. The time taken for Apache to receive the entire response back from the remote resource is not something you can send in the headers, as the headers will have been sent to the client before the remote response is fully received. This information could trivially be written to the Apache logs, however.
I am building an Air application that long-polls a Spray server to get relevant updates.
I am new to Spray and have read that, if requests are not handled on time, a 500 timeout error is automatically sent to the client by the framework. I can catch this error on the Air side, and then send another request, etc.
Are there any drawbacks to using this approach (I cannot think of any) or is it better to avoid the timeout and send back some sort of "no news" message to the client instead?
I would say, from a RESTful perspective, that the response should pertain to the state of the resource. Looking at the available response codes:
204 No Content The server successfully processed the request, but is
not returning any content.
This states that the request was carried out successfully yet there is nothing to return.
204 No Content
I am currently working on a WCF service and have a small issue. The service is a Polling Duplex service. I initiate data transfer through a message sent to the server. Then the server sends large packets of data back through the callback channel to the client fairly quickly.
To stop the I send a message to the sever telling it do stop. Then it sends a message over the callback channel acknowledging this to let the client know.
The problem is that a bunch of packets of data get buffered up to be sent through the callback channel to the client. This causes a long wait for the acknowledgement to make it back because it has to wait for all the data to go through first.
Is there any way that I can clear the buffer for the callback channel on the server side? I don't need to worry about loosing the data, I just need to throw it away and immediately send the acknowledgement message.
I'm not sure if this can lead you into the correct direction or not... I have a similar service where when I look in my Subscribe() method, I can access this:
var context = OperationContext.Current;
var sessionId = context.SessionId;
var currentClient = context.GetCallbackChannel<IClient>();
context.OutgoingMessageHeaders.Clear();
context.OutgoingMessageProperties.Clear();
Now, if you had a way of using your IClient object, and to access the context where you got the instance of IClient from (resolve it's context), could running the following two statements do what you want?
context.OutgoingMessageHeaders.Clear();
context.OutgoingMessageProperties.Clear();
Just a quick ramble from my thoughts. Would love to know if this would fix it or not, for personal information if nothing else. Could you cache the OperationContext as part of a SubscriptionObject which would contain 2 properties, the first being for the OperationContext, and the second being your IClient object.