Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>So what appears to be happening here is that your client sends a request, does not get a response in a timely manner, and as a result retries the same request again (as it should). This, in turn, results in multiple <code>POST</code> requests being sent to your server (almost in succession), which your server cannot currently deal with appropriately.</p> <p>To verify/debug this, try disabling HTTP retries as follows:</p> <pre><code>defaultHttpClient.setHttpRequestRetryHandler(new DefaultHttpRequestRetryHandler (0, false)); </code></pre> <p>This of course will deal with your <em>duplicate</em> requests issue, but then introduces another more serious issue; namely, it will try <em>once</em> (and only once) and fail. From the information I got from your comments, here are a few ideas you can try:</p> <p><em>Please bare with the pseudocode as I don't have all the details of how your client is architected</em></p> <p><strong>Handle Multiple POSTS in Succession</strong></p> <ul> <li>Disable automatic retries (as above)</li> <li>Wrap your <code>POST</code> requests in a loop similar to how <a href="http://w3mentor.com/learn/java/android-development/android-http-services/example-of-simple-retry-technique-to-deal-with-timeouts-in-android/">this</a> is implemented</li> <li>Then either <code>sleep</code> between your <em>manual</em> retries or implement your version of <a href="http://en.wikipedia.org/wiki/Exponential_backoff">exponential backoff</a></li> </ul> <p>No matter what, your server <strong>will</strong> need the capability to handle duplicate requests in a reasonable way, this is HTTP afterall. However, you're at least giving it a chance to process the first one before it's bombarded with duplicates.</p> <p>I recommend that the <em>first</em> step it takes when processing a request is to set some form of a (duplicate) <em>flag</em>. Then if/when it receives a dupe, it continues processing the <em>first</em> request (as usual) and silently ignores the dupes.</p> <p>So just to summarize, the point of this whole scheme was to <strong>give your server a chance to set the dupe flag</strong>. After that, it's your server's job to discard (or handle) duplicate requests as needed. Does this all make sense?</p>
    singulars
    1. This table or related slice is empty.
    1. POduplicate requests from HttpClient
      singulars
      1. PTQuestion
    1. PTAnswer
    1. This table or related slice is empty.
    1. USMarvin Pinto
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POduplicate requests from HttpClient
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTAcceptedByOriginator
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTBountyClose
    1. COThanks Marvin, your suggestion lead us down the right path.. now at least we know what we're dealing with.
      singulars
      1. PO
      1. USdanb
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload