We use EventStore 5.0.0 and we faced with the following situation:
when we store event, sometimes, C# client receives response with error. Error from log:
EventStore.ClientAPI.Exceptions.WrongExpectedVersionException: Append failed due to WrongExpectedVersin. Stream: QWE.Api.SomeClassifier.Actors.ProductInfoActors.ProductActor-q5839583-5r82-5k30-sl13-1t485329g395, Expected version: 13, CurrentVersion:14
Disregard this response with error, event is stored with version 14.
What could it be the reason of this error message, while event was really stored?
We think the problem is in slow ssd, or high load.
This is the database built-in optimistic concurrency check. You can find more about it here: https://developers.eventstore.com/clients/grpc/appending-events/#handling-concurrency
Related
I am getting the stuck thread error often while trying to send the JMS message to another manager server within the domain in our production environment.
Initially, we felt that it might be due to Load on the server but issue occurred randomly Even at the time of less load and system processing well some high volume time
We are not able to find the reason for the same.
Error Information:
weblogic.jms.client.JMSConnectionFactory.createQueueConnection(JMSConnectionFact
ory.java:199)
Hi we have created a Syslog Drain from pcf to logstash but sometimes we are getting 2018-07-19T15:09:53.524+05:30 [LGR/] [ERR] Syslog Drain: Error when writing. Backing off for 4ms.
this error.
What is this and why?
I suspect that it's a communication problem with the logging system in your Cloud Foundry platform as it's trying to talk with your LogStash. The message doesn't give you an exact error though. To find that, you would need to be a platform operator and look at the Loggregator logs to see why it's failing. If you're not the CF platform operator, reach out to your operator for assistance.
When you see errors like this I would suggest checking for two things:
How often do you see this message?
How large does the number in "Backing off for XXms." get?
When an error occurs sending logs the platform will back off, but as errors continue to occur the backoff timeout will get larger. If you see a large value in the backoff timeout, that means you have a prolonged problem. This could be something like you've configured the log drain incorrectly, your LogStash server is down or the network to it is down. If you see the errors frequently, but the number stays low, it means it's only intermittently failing (some logs go OK, some don't) which could point to a flaky network connection, one that's up/down a lot.
I have a very tremendous issue in my app. App is using webrtc to create video connection between two people.
Currently the app it's in the test phase.
Everything is working fine on Chrome, but on Firefox there is a strange issue.
When the second Peer connects I receive this error:
Error adding ice candidate for pcInvalidStateError: setRemoteDescription needs to called before addIceCandidate
I know that the error message seems to be clear, but how it's possible that on Chrome this error does not exist?
I mean, maybe there is a bigger issue, not completely depending on this error message.
Do you have any ideas or solutions to this?
A part from WebRTC doc: (See Deprecated Exception section)
Deprecated exceptions
When using the deprecated callback-based version of
setRemoteDescription(), the following exceptions may occur:
InvalidStateError The connection's signalingState is "closed",
indicating that the connection is not currently open, so negotiation
cannot take place.
You should check you are not using deprecated callback version of this function. Also you should keep an eye on signalingState of the peer connection.
Hope it helps!
Calling https://www.googleapis.com/appsmarket/v2/licenseNotification/[myAppId] has suddenly started returning 500 Backend Error every time.
500 error is a generic message, given when no more specific message is suitable. There are a number of causes for a 500 Internal Server Error to display in a web browser.
With any error message, particularly one as broad as the 500 Internal Server Error, you will first want to check your error logs for your server. These logs can provide valuable context related to any code failures or other potential causes of a site failure.
As stated in the answer in this SO question.
In general, every Backend error should be handled with an exponential retry, as
there might be service problems.
If the error still persists after let's say 10 hours then you should
contact the support in order to provide you 1:1 help to your problem.
Without going into too much detail (I am looking for debugging techniques here), I would like to understand how to better debug Xlib failed requests. In particular dealing with the glx extension. The occurrence of the bug I am fighting is in a complex place within my application and trying to pull it apart to provide a small sample here is not possible.
With that said the failed request I am seeing is
x10: fatal 10 error 11 (Resource temporarily unavailable) on X server ":0.0"
after 46 requests (46 know processed) with 0 event remaining.
X Error of failed request: BadAccess (attempt to access private resource denied)
Major opcode of failed request: 135 (GLX)
Minor opcode of failed request: 5 (XGLMakeCurrent)
Serial number of failed request: 46
Current serial number in output stream: 46
I can see where the problem is being caused by stepping through with the debugger. However, I can't fully discern why it is happening.
The clue where to look is in the name of the extension and the name of the request itself. Unfortunately in this case because of your use of Xgl this isn't so helpful. But you can check what the request really is by checking out the protocol documentation like this one for glproto. From that you can see that the request is really glxMakeCurrent. Then you just need to find the documentation or code for that request.
The GLX specification says glxMakeCurrent will give BadAccess if "the context is current to some other thread".
Now, your error is about XGLMakeCurrent which is an implementation detail of Xgl . But from reading the implementation of this function it passes through to the the underlying GLX implementation.
To fix your problem I suggest you try and identify if that context is being used in another thread.
For debugging you want to turn on synchronous requests, this slows down your code but will make every X request wait until the server processes it before continuing and immediately return an error. You can turn it on with
XSynchronize(display, True);
Now you will get the X error at the routine that caused the issue and can use standard debugging tools from there.