As shown below, when send the request body, the request header is send as the body content.
[enter image description here][1]
I compared the 3.x and 4.x codes, find two versions on the processing of RetryAndFollowUpInterceptor.intercept() is different.
The 4.x version calls the detachWithViolence methods in the finally to release the resource, but the 3.x version does not release the resource if an exception occurs, this results in unsuccessfully send data in the Buffer being consumed by the next request.
Please help to fix this BUG in version 3.x, thank you!
List 135 of class okhttp3.internal.http.RetryAndFollowUpInterceptor does not execute when an excption is thrown.
Because the difference between the two version is too big, the team will not upgrade for the time being.
Could you fix the BUG on the 3.x version?
Related
I have used quickblox chat sdk in my old xamarin.forms project. I know that quickblox is not supporting xamarin now, but old sdk was working fine till now, but from last week I am getting this error.
Code:
var baseSesionResult = await Provider.QbProvider.GetBaseSession();
When I am calling QbProvider.GetBaseSession() it throws below error:
CONTENT: {"errors":{"base":["nonce is required"]}}
I have tried different methods available in sdk but none is working. Any one know how to fix this error?
This is Nikolay from QuickBlox support.
Please add "" symbols around nonce and timestamp values and check if the issue is resolved.
The same information is mentioned in our documentation: https://docs.quickblox.com/reference/authentication#create-session
We released a patch for authentication that improves validation according to our documentation.
Hence, the issue is caused by incorrect implementation in the application that is why the server has started showing errors for submitted requests.
I am using the rest client to update some documents and got some version conflict issues. I then added a call to retryOnConflict(3) when creating the UpdateRequest. However, I still got some conflicts like below:
exception [type=version_conflict_engine_exception, reason=[myDocId]: version conflict, document already exists (current version [1])]]
The puzzling thing to me here is the currrent version is 1. Since i set retries to 3, it seems like the current version reported in the exception should be have been much higher before Elasticsearch gives up and returns a failure. I debugged my code and confirmed the json content the rest client builds contains the retry parameter. Scripted updates in bulk requests are being done, but otherwise nothing special.
Is this just an issue of a misleading error message or maybe something else is going on?
I'm using Processing 3 for generating a Treemap.I installed gicentreUtils and placed TreeMappa file in the library folder of Processing. I'm getting nullPointerException in line:
pTreeMappa = new PTreeMappa(this).
The full code can be found in this
link
Can someone please let me know how to resolve this error.
Thanks
It seems the TreeMapa library hasn't been updated in a few years and internally it may use some Processing code that changed from version 2.x to 3.x (like windows/frames/etc.) which is why the error might occur.
I advise using TreeMapa with Processing 2.2.1 available on the Processing Downloads page
Version :
Apache MyFaces 2.1.14 and RichFaces 4.3.5
Issue:
We are migrating from jsf 1.2 to jsf 2. We are facing very strange issue as :
When any ajax operation is performed , we are getting below error and page is not refreshed (or rerended as usual)
org.apache.myfaces.context.servlet.ServletExternalContextImpl setResponseContentType
SEVERE: Cannot set content type. Response already committed
This question is very similar to jsf 2.0 response already commented (ajax) ,
but it seems that no one has answered this question.
It also comes only at the specific page and same code at other places works fine and this error is very random in nature?
Is this anything to do with apache myfaces ?
Please help if any inputs are available .
The xhtml ajax tags causing these issues are : a4j:commandLink and a4j:ajax
That usually occurs because there is an error on render response phase and part of the response has been already send to the client. The algorithm then try to render the error page but it can't because the response has been already sent so you get the problem.
The solution usually is avoid the early commit, increasing the buffer size of the response. To do that use javax.faces.FACELETS_BUFFER_SIZE web config parameter (by default is 1024 bytes).
Theoretically this param has a negative effect over memory, because the larger the buffer, the more memory is allocated for that, but the JVM is fast enough if there is enough memory.
I'm integrating Glimpse to a legacy production application (Upgraded to MVC3). Most pages have a lot of ajax requests and some of the ajax requests return an empty response based on the business logic.
Glimpse client fails to parse such empty responses (out of may be 20-30 responses). Chrome console clearly shows where it fails.
Uncaught TypeError: Cannot call method 'indexOf' of null Glimpse.axd?n=glimpse_client&hash=0a37c827:3633
display.ajax.processContentType Glimpse.axd?n=glimpse_client&hash=0a37c827:3633
display.ajax.update Glimpse.axd?n=glimpse_client&hash=0a37c827:3657
display.ajax.XMLHttpRequest.open
The reason is that the processContentType function is given a 'null' as contentType (variable named 'type' within the function) and the following statement fails.
return type.substring(0, type.indexOf(';'));
What bothers me is the fact that the whole Glimpse window does not show up (Glimpse icon is not hyper-linked to open up the Glimpse tabs) as a result. Is there anyway (configuration?) to workaround the issue?
Thank you!
The issue was resolved by updating Glimpse to 1.5.0.
---Here's the comment from Glimpse;
avanderhoorn commented 6 hours ago
You must be running an old version of Glimpse.core. This was fixed with PR #401 (reported in
#400) and went live in release https://github.com/Glimpse/Glimpse/releases/1.5.0.
All I did was 'Update-Package Glimpse' in VS package manager console and it's fixed now.