Support timeouts for network reads/writes about stompngo HOT 16 CLOSED

This is not a one size fits all piece of functionality.

I will try to figure out a good way to make it optional.

What action to take if a timeout does occur? The answer to that is not one size fits all either.

What version of go are you running?

from stompngo.

Understood. I was imagining a method or two that could be used to set/remove a timeout and if it occurs, it gets reported as an error and the user decides what to do. They can then decide to retry/reconnect/etc. At least for sending that should work. For consuming, not sure. I haven't really looked at the code.

As for the version, it's a bit old from what I can tell. The data in our git repo (we vendored it) is from September 2016.

from stompngo.

I will put this in motion. All will not be completed at the same time.

I will do writes first, as that will be the easiest to implement. Your client code will have to "buy in" to this functionality. I am not going to make it the default.

Right now I am thinking a set/remove functionality with a callback if/when a timeout occurs.

from stompngo.

Hi - take a look at the HEAD of the dev branch.

Optional support of write deadlines is implemented.

My testing has been mostly to make sure I did not break anything. I am hoping you can look at this, do some vigorous testing, and give me feedback.

Also - if you could get me stack traces of any heartbeat error scenarios, I would really appreciate it.

from stompngo.

Hi - Ditto for reads: on the DEV branch.

This was actually easier than I had first thought.

from stompngo.

Hi,

I quickly looked at the changes and they look good. I'll try to get to testing this soon. Other things came up that I have to deal with.

Thanks!

from stompngo.

O.K. I tried them out and using the new features seems fine, however it's not helping my particular case. I'm digging through some log messages right now to try to figure out what's going on, but I don't think the issue is your timeout code. I see resquests/responses occurring (finally enabled logging in your client), so I think that the timeouts simply aren't being triggered.

If anything changes I'll let you know. Hopefully this does help someone out.

from stompngo.

If you set timeouts too "high/long" is it unlikely they will ever occur.

If you set them too "low/short" you should see them at times when you do not really want to.

This is still very much 'development' in my mind - an experiment if you will. I am going to do a lot more testing here, and likely some refinement before I merge this to master. And I of course reserve the right to just back it all out. That is what the dev branch is for.

I know that read timeouts will fire correctly. I can put a system under load, use a very low timeout value, and one will fire.

I saw some real oddities on my Mac late last night, and I want to explore those quite a bit more. Partially I think because the Mac is old and slow.

I would be willing to look at any logs you have if that information is not proprietary.

In any case I appreciate your efforts with tests, and any feed back you have. Thanks.

If you can explain your original problem in more detail, I would like to think about that. You mentioned heartbeats, and if there is some odd problem with stompngo heartbeats I really need to know about that.

from stompngo.

Looking at this log file a bit more, I do see this:

[RDR_RECEIVE_FRAME RDR_RECEIVE_ERR read tcp <source>-><dest>: i/o timeout]
[HDERR starts {{ connection_read_error:read tcp <source>-><dest>: i/o timeout []} read tcp <source>-><dest>: i/o timeout}]

However, I never got a message from the method I passed into ExpiredNotification.

from stompngo.

Regarding the timeouts: I currently have them set to 1 second as the network shouldn't be an issue. That's when I got the errors in my previous comment.

Regarding the logs: unfortunately I can't share log files. :( I can share snippets as needed and I'll do so as I see things that I find.

Regarding my original problem, here's a link to what caused this all: http://stackoverflow.com/questions/43505774/receiving-and-sending-messages-with-rabbitmq-with-prefetch-1-for-the-consumers

I didn't post this here because I don't know if this is a stompngo problem or not. I was trying to get more information before "blaming" the client driver. Unfortunately, I'm not quite getting the info I want. My gut is leaning towards us not doing things "correctly", but I'm not 100% sure.

from stompngo.

Great info, thanks. That would seem to be a flaw in the current logic. Not sure where, I will think about it.

What do you do in the call back ? During this initial round I would suggest at a minimum:

debug.PrintStack()

that would give me a lot of information.

from stompngo.

My callback just uses fmt.Printf to print out both incoming parameters. After I do some more digging, I'll run a test doing just that.

from stompngo.

There is additional work on HEAD of dev. Use that please. In at least one case the callback was not being invoked.

I have at least one more piece of logic to add (that I am aware of). It has to do with "large" messages, for some value of "large".

For example, a write of a 32K body can complete with a timeout, but only 8K written. I am not sure how I will handle that. I am currently thinking I need to not treat that as an error. Call the callback yes, but essentially not treat it as a hard error. This .... might mean that this entire effort is of dubious value for writes. I need to think about this a little more.

I suppose the idea could apply to "large" reads. However, I have not actually seen that to date.

from stompngo.

The new code didn't change anything for me, but I think it's because in my test case, the connection is being dropped. You can look at the StackOverflow post I linked to earlier in case you want to check out the details.

from stompngo.

Can this be closed ? If so, please take care of that.

If not, give me more feedback.

from stompngo.

Apologies for the late reply. The code looked good when I checked it out, so I'll close this. Thanks!

from stompngo.