Im randomly getting the error: A MessageReceived handler is blocking the gateway task and when that happens my shard were the error ocurred disconnects without reconnecting.
The problem seems to occur with all the commands. But there is only a small change of it actually occurring. Most of the time the error happens when someone uses the Color = command because that's the most used command.
Im using Discord.net v2.0.0-beta. I switched to the beta because i was having the same issue with 1.0.2
This error occurs when something is running and your bot receives new messages. Your bot wants to process the command, but the previous task is still running so it has to wait for it to finish.
You can fix this by making your bot async. A good introduction to asynchronous programming can be found here.
Related
I've created an SNMP listener application for one of our servers that runs as a service and passively listens for any SNMP message alerts sent from another server, and when one is received is sends out a page/email to appropriate staff. I followeda few online tutorials for setting up the application as a windows service since it needs to run constantly and won't require input/interaction from a user, or interaction with any GUI/desktop applications.
For some reason, when I install the application as a service, it installs correctly, but doesn't actually seem to be working. When SNMP messages are sent to the server nothing happens. However, in my app.publish folder there's an SNMPTrapper.exe application,and if I run that exe on its own, then everything works fine. For the time being I'm using a workaround so that the Onstart section of the code for the service basically just launches the SNMPTrapper.exe application, and when the service is stopped, it finds and kills the SNMPTrapper.exe process. At this point though, the service itself doesn't seem to be working/doing anything. It's essentially just a way to get the SNMPTrapper.exe application launched.
Does anyone know what the issue may be? In some of the tutorials I've read through they outline how to setup polling intervals for the service, but I don't think that would be applicable since this service will essentially just run constantly to listen for new messages, it won't need to check for anything at a regular interval.
Right now pretty much all of my code is executed in Sub Main() except for a few function calls.
Any help would be greatly appreciated.
You don’t state how you’re doing any of this. For a windows service you get two messages from the system: OnStart and OnStop. The job of OnStart is to set up all the required code to do the job, then exit. It doesn’t take part in the work so you need a Task or Thread setting up to do that. The Task or Thread should loop until it gets a message, passed by OnStop, that we’re done. If you want a service that you can test from the command line then your Main routine needs to do exactly the same setup, then wait for a key to be pressed before sending an OnStop.
(As an aside, you ARE remembering to start the service once you have installed it?)
This is not about pinning down the hang as such, its more about wondering if there is a way to make testcafe decide the test must be a failure after a given period of time.
Our test works fine on local machines, but occasionally when run in CI using a docker image on semaphore one of the selectors causes it to hang. I am fine ivestigating why that is, but it would be good if I could tesll the test to give up after say 5 minutes (it should finish in under 3) and exit gracefully so we can have the stack trace and video - if we have to kill the test run we don;t get either, so we end up having to debug by the logging we emit from the test code.
Currently, this functionality is not implemented in TestCafe. Please track the https://github.com/DevExpress/testcafe/issues/6096 issue to check our progress.
We're facing an issue with handling unexpected behaviours when performing xmlHttpRequests on Android devices using React-Native. We've experienced behaviour where the app becomes unavailable to complete API calls, even though the device is connected to the internet perfectly well (browser can access non-cached sites just fine). The only way to resolve this issue for our users has been to completely restart the app.
To understand the issue and its severity, we wrapped all our API calls to a timer function in production and sent reports to Sentry whenever a request took longer than 30 seconds to finish. Now we've been receiving these kind of reports in the hundreds per day with the duration sometimes being in the hours or even days.
First, instead of using whatwg-fetch, we moved to using axios so that we can manually set the timeout of each request, but this ended up not helping at all.
Second, we dove deeper into understanding how React-Native actually implements timing out XHR requests on Android, and found that it uses OkHttp3 under the hood. OkHttp has a default value for connect, read and write timeouts and react-native allows developers to change the value of connect timeout here. However, OkHttp also has a method for setting a call timeout (everything from connect to reading the response body), but this has a default value of 0 (no timeout) and React-Native doesn't allow users to change that. More on okhttp timeouts here
My question is whether this can be the cause of our worries and whether it should be reported to React-Native as a bug. Lets assume the following case:
app makes an API call to a resource
okhttp is able to connect to the resource within specified timeout limit (default 10s)
okhttp is able to write the request body to the server within timeout limit (10s)
server processes request but for some reason it fails to start sending a response to the client. I guess there could be many reasons for this like server being disconnected, server crashing or server simply losing the connection to the client without the client noticing it. As there is no timeout here, okhttp will happily wait for days on end for the server to start responding to the request.
Am I missing something here or misunderstanding how timeouts work in okhttp? Is there another, perhaps better solution than implementing the ability for developers to set callTimeout on API calls performed on android? And also, isn't it a bit stupid that developers cant set their own write and read timeouts? Cant this lead to unexpected behaviour when you want to send large amounts of data in either direction on a slow connection? 10s is quite long, but perhaps not long enough for all use-cases.
Thanks for your help in advance!
Maybe someone had the same problem.
I use Weblogic at work. So, we have two small applications on it. And today it stopped writing logs(all logs stopped writing at the same time). Then, after three hours it writes in log “JVM called WLS shutdown hook. The server will force shutdown now” and shutdown. After start everything works fine.
But I want to understand, why this situation happened
Thanks
This happens when System.exit(int) is called. Check if some of the deployed components call System.exit instead of throwing an Exception. This also can be due to the JVM taking up the OS signals.Set the -Xrs option in the startup scripts in JAVA_OPTIONS if you are using Sun JDK.It reduces use of operating-system signals by the JVM.
I have an app and it fails randomly sometimes because my internet is not so fast (my app uses the webbrowser). How can I make my app restart itself it it fails? Or make my app click button1 on my form if it fails.
I have had similar problems in the past. I solved it by using scheduled tasks to start the app on a regular basis. On Startup the new version would attempt to stop the old version and if that failed, (because it was hung) it would kill the process of the old program.