There might be a performance issue here, especially if URL points to a remote server or processing takes a while. We have discussed option for batching forwarding, but it's not implemented yet.
Thanks Anton
The URL is local on 127.0.0.1, and I respond immediately after getting the forwarded message.
I can adjust my app that processes the forward URL data, and increase the max connections, but if traccar/the underlying technology also has this limitation, I doubt it would make much difference, if any.
Another solution maybe to save the messages into a Queue, such as Rabbit or Microsoft Message Queue.
This would simply dump messages into a queue instead of forwarding to a URL and waiting for a response.
It would bypass any limitations, and could scale past the 30 per second failures i've seen
Would this be something you would consider as an alternative?
You can create a feature request for it, but I don't think it would be implemented any time soon.
Thanks Anton
I can edit the code myself and create a pull request if it's something you think would be helpful
Which file should I look at where is actually does the forwarding?
I can figure the rest out from there.
Also, should I move this chat to github for any further stuff?
WebDataHandler
class. Yes, you can move this discussion to GitHub.
Hi All
I'm trying to hunt down an issue on missing forwarded data
I see the data in the traccar DB, but in the forwarded logs on the other multithreaded app, I'm missing a chunk of 13 mins
I've seen this happen a few times, but now need to figure out where its going wrong.
To help with investigation:
Or are there any general performance issues with post and get that I should consider (I know this wouldn't be a traccar issue)
Any help appreciated
Thanks for your time