That is true.
I don't expect to need more than 20 connections total, but possibly 3-6
connections per route; I don't know what is optimal yet.
Nathan
--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to
In most apps AndroidHttpClient is best used a singleton for the reasons you
describe. It doesn't make sense to create a thread pool
for each AndroidHttpClient instantiation.
From the Apache HttpComponents dosc:
DefaultHttpClient is thread safe. It is recommended that the same instance
of this
Well, I can say that it sounds really nice in theory.
In practice, all you have to do is have a few requests fail, and then
a subsequent request is completely frozen.
The thread is then blocked on this call.
ConnPoolByRoute.getEntryBlocking(HttpRoute, Object, long, TimeUnit,
I found the same issue (actually, response-content from a previous request
was 'bleeding' over into the next one).
I solved this by make an AndroidHttpClient a ThreadLocal.
This way, the number of AndroidHttpClients is never larger than the number
of threads handling http-requests in the
When an error (Exception) occurs you must call abort() on the request (ie
your HttpGet or HttpPost instance).
Also if you don't read (or read partially) the Entity in the response, you
must call EntityUtils.consume(entity). Otherwise you may have hanging
threads / connections.
But I forgot to
After forcing some errors and doing some debugging, I found that I was not
always calling entity.consumecontent() if I got an error, as you suggested
in another thread. If an actual exception is thrown, I hope I don't have to.
Nonetheless, if I get a status code other than 200, there can still
On Tue, Aug 30, 2011 at 9:40 AM, Nathan critter...@crittermap.com wrote:
After forcing some errors and doing some debugging, I found that I was not
always calling entity.consumecontent() if I got an error, as you suggested
in another thread. If an actual exception is thrown, I hope I don't have
The following links may be useful. Jt implements web/services and
messaging
on Android:
a) Java Pattern Oriented Framework, An application of the Messaging
Design Pattern
IBM Technical Library
http://www.ibm.com/developerworks/webservices/library/ws-designpattern/index.html
b) Messaging Design
Hi Bob, thanks for the reply. What happens on the server is completely out
of my hands. It is not part of my app, and it's not under my control. That
said, the use of get to update the database is something that the server
offers as a convenience. It's not the case the a user could
You might gain some good ideas from watching the RESTful application
development video from this year's GoogleIO conference:
http://www.google.com/events/io/2010/sessions/developing-RESTful-android-apps.html
I found it fascinating.
On Dec 15, 4:28 am, flipside flipside...@gmail.com wrote:
I'm
Yes, I had watched that talk, and I agree that it was very interesting. The
pattern of keeping track of requests in a local database might well be the
way I end up going. It initially seemed as though that might be overkill for
what I'm doing, but the more I think about it the more likely it
You should not be using GET to update your database. This is abuse of
GET. From RFC 2616, Section 9:
9.1.1 Safe Methods
Implementors should be aware that the software represents the user in
their interactions over the Internet, and should be careful to allow
the user to be aware of any actions
12 matches
Mail list logo
