[
https://issues.apache.org/jira/browse/HTTPCLIENT-948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12874586#action_12874586
]
Sam Berlin commented on HTTPCLIENT-948:
---
Excellent find, Oleg! I just tried
[
https://issues.apache.org/jira/browse/HTTPCLIENT-427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12865134#action_12865134
]
Sam Berlin commented on HTTPCLIENT-427:
---
One statement, one question:
1) Without
[
https://issues.apache.org/jira/browse/HTTPCORE-219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12841899#action_12841899
]
Sam Berlin commented on HTTPCORE-219:
-
I don't think it's all that terribly bizarre
ConcurrentHashMap has a high memory overhead (which has bitten me in
projects before, where CHM was used for in many places convenience but
wasn't strictly needed). Unless there's a compelling need to have a
non-blocking threadsafe map, a synchronized hashmap should work well.
Sam
On Mon, Feb
If IOSessions are disposed of properly, ByteBufferAllocater can become
ByteBufferManager the ByteBuffers can be returned recycled/reused.
Sam
On Mon, Dec 14, 2009 at 10:20 AM, Oleg Kalnichevski ol...@apache.orgwrote:
Asankha C. Perera wrote:
Hi Oleg
Has anyone encountered this issue
Oleg,
I finally had a chance yesterday to look over some of the async stuff.
Would you prefer that I hack away directly on the code, or summarize
thoughts in email/JIRA for discussion?
Thanks.
Sam
On Mon, Sep 7, 2009 at 9:13 PM, Sam Berlin sber...@gmail.com wrote:
This actually times very
This actually times very well with some work we're going to do on
refactoring the download code for LimeWire in the coming months. I or
someone else on the team should be able to work against a draft of this and
come up some API that is, at a minimum, is extensible enough for our use
(which
[
https://issues.apache.org/jira/browse/HTTPCLIENT-854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12722856#action_12722856
]
Sam Berlin commented on HTTPCLIENT-854:
---
Oleg,
Would you be comfortable
[
https://issues.apache.org/jira/browse/HTTPCLIENT-854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12721772#action_12721772
]
Sam Berlin commented on HTTPCLIENT-854:
---
I can see the patch being reformed
[
https://issues.apache.org/jira/browse/HTTPCLIENT-854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12721561#action_12721561
]
Sam Berlin commented on HTTPCLIENT-854:
---
Would something as simple
[
https://issues.apache.org/jira/browse/HTTPCLIENT-854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12721631#action_12721631
]
Sam Berlin commented on HTTPCLIENT-854:
---
I'm not sure I fully understand
[
https://issues.apache.org/jira/browse/HTTPCLIENT-854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12721634#action_12721634
]
Sam Berlin commented on HTTPCLIENT-854:
---
That makes sense. What's the use-case
[
https://issues.apache.org/jira/browse/HTTPCLIENT-841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12699686#action_12699686
]
Sam Berlin commented on HTTPCLIENT-841:
---
I have a little familiarity
25, 2009 at 3:25 PM, Oleg Kalnichevski ol...@apache.org wrote:
Sam Berlin wrote:
It might help with debugging arbitrary NonRepeatableRequestExceptions
if it somehow captured the original exception that triggered the retry
and added it to the cause. Think this has any merit (or is it even
Annotations are explicitly designed to allow code to continue working
even if the annotation is not present at runtime. Annotations just
describe arbitrary additional details about code, but do nothing to
inherently change or add logic. Of course, if there's some code that
looks at annotations
Adding (optional?) built-in transfer-encoding support?
Sam
On Fri, Mar 13, 2009 at 11:09 AM, Oleg Kalnichevski ol...@apache.org wrote:
Folks
Do we want to propose any project ideas?
http://wiki.apache.org/general/SummerOfCode2009
Oleg
My thought was more along the lines of built-in compression support
(gzip, etc..), but your mention of caching is a *very* good idea.
Much more involved than gzip, but also much more useful!
Sam
On Fri, Mar 13, 2009 at 1:47 PM, Oleg Kalnichevski ol...@apache.org wrote:
Sam Berlin wrote
Congratulations, everyone. And especially congratulations to Oleg.
You really deserve something special for all your extraordinary work
on HttpComponents.
Sam
On Thu, Feb 26, 2009 at 2:11 PM, Oleg Kalnichevski ol...@apache.org wrote:
The Apache HttpComponents project is pleased to announce the
the auth finishes? What trick would I
use in an interceptor in order to get the subsequent GET?
Thanks!
Sam
On Tue, Jan 13, 2009 at 2:33 PM, Oleg Kalnichevski ol...@apache.org wrote:
Sam Berlin wrote:
Hi All,
Is there a preferred way of adding a Connection: Close header into
an exchange you
wrote:
Sam Berlin wrote:
Sorry, I had a bit of troubling grasping the question in my head, so
it didn't come out too clearly.
On the client side, I'd like to send a request that I know will
require credentials. So I get the HttpClient's credentialsProvider
set some credentials in it. I'd
Hi All,
Is there a preferred way of adding a Connection: Close header into
an exchange you expect (and want) to use credentials with? I would
expect if the initial request had a failure due to unauthorized
credentials that the Connection: Close would kill the connection
instead of continuing the
[
https://issues.apache.org/jira/browse/HTTPCORE-155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12659137#action_12659137
]
sberlin edited comment on HTTPCORE-155 at 12/24/08 10:43 AM:
I'm driving around the states right now without any solid access to a
computer (much less a computer I can code with). Sorry for not being
able to check out the release! Will continue being away from a
computer for the next two or so weeks.
Sam
On Aug 21, 2008, at 2:44 PM, Oleg
[
https://issues.apache.org/jira/browse/HTTPCLIENT-787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12614044#action_12614044
]
Sam Berlin commented on HTTPCLIENT-787:
---
Perhaps something like
I noticed that the recent fix to multipart is dependent on a snapshot
of mime4j. If we go BETA1 for HttpClient, does that also freeze the
API of the mime component? Is that OK if it's dependent on a snapshot
release of mime4j?
Sam
On Thu, Jul 10, 2008 at 4:59 PM, Oleg Kalnichevski [EMAIL
Components: HttpClient
Affects Versions: 4.0 Alpha 4
Reporter: Sam Berlin
Fix For: 4.0 Beta 1
Some attention should be placed on classes who shared their variables directly
(as opposed to through a getter). This is sometimes OK for subclasses, but
rarely good for other
the connection] looks just as
the user token attribute). But then again, since AbstractConnPool is
abstract, that can be done whenever it's needed too.
Sam
On Thu, Jul 10, 2008 at 5:57 PM, Sam Berlin [EMAIL PROTECTED] wrote:
That's the question, really. I'll dig into it a bit deeper tonight
and try
Whew! Thanks for the heads-up about the problem, and confirmation
that the fix works, Paul.
Sam
On Tue, Jul 1, 2008 at 7:16 PM, Paul Lindner [EMAIL PROTECTED] wrote:
That did it. I'm running svn head on one production server and seeing very
good behavior.
On Jun 30, 2008, at 6:53 PM, Sam
Yikes, that's no good. Did you test this using the first revision of
the fix or the second (changed to use 'setIdleDuration' in
ManagedClientConnection)?
Think it'd be possible to isolate the problem to a unit test?
Sam
On Mon, Jun 30, 2008 at 10:33 AM, Paul Lindner [EMAIL PROTECTED] wrote:
Kalnichevski [EMAIL PROTECTED] wrote:
On Mon, 2008-06-30 at 10:43 -0400, Sam Berlin wrote:
Yikes, that's no good. Did you test this using the first revision of
the fix or the second (changed to use 'setIdleDuration' in
ManagedClientConnection)?
Think it'd be possible to isolate the problem
Hi Paul,
I think I've fixed this one -- the problem was using deleteEntry
instead of dropEntry. The former required the entry to be considered
'free', but the entry had just been allocated and was definitely not
'free'. I'm pretty certain this will indirectly fix the
connection/memory leak -- a
This looks really cool! Makes it much easier to use HttpClient for
everyday usage.
Sam
On Fri, Jun 27, 2008 at 7:43 PM, Oleg Kalnichevski [EMAIL PROTECTED] wrote:
On Fri, 2008-06-20 at 11:50 -0700, Bob Lee wrote:
...
Or even something like this:
public interface ResponseHandlerT {
T
[
https://issues.apache.org/jira/browse/HTTPCLIENT-781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12608898#action_12608898
]
Sam Berlin commented on HTTPCLIENT-781:
---
i cleaned up the code a bit, including
Respect Keep-Alive Header
-
Key: HTTPCLIENT-781
URL: https://issues.apache.org/jira/browse/HTTPCLIENT-781
Project: HttpComponents HttpClient
Issue Type: Bug
Affects Versions: 4.0 Alpha 4
Reporter: Sam
the timeout elapses? (I don't think the
latter is possible without an additional thread.)
Sam
On Wed, Jun 25, 2008 at 5:33 PM, Oleg Kalnichevski [EMAIL PROTECTED] wrote:
On Wed, 2008-06-25 at 17:14 -0400, Sam Berlin wrote:
Hi Folks,
We just stumbled across an issue with persistent connections
PROTECTED] wrote:
On Wed, 2008-06-25 at 17:42 -0400, Sam Berlin wrote:
Done @ https://issues.apache.org/jira/browse/HTTPCLIENT-781 . I can
take a look at this in the coming days -- do you think an
implementation that just closes the prior connection makes a new one
on a subsequent request
It is true, but this helps you keep track of open connections, right?
You can easily add more control logic around ConnectingIOReactor in
addition to that.
So, i think a viable approach could be to build the connection
management code as an extra control layer on top of both IOEventDispatch
+1
On 6/17/08, Oleg Kalnichevski [EMAIL PROTECTED] wrote:
Please vote on releasing these packages as HttpComponents Core
4.0-beta2. The vote is open for the next 72 hours, and only votes from
HttpComponents PMC members are binding. The vote passes if at least
three binding +1 votes are cast.
Hi Folks,
I've got a situation where an HttpResponse can come without a
content-length set, but the application can determine when the entity
is 'finished' through reading it. In HttpCore this is solvable by
closing the InputStream after reading what you need. (It will use an
I'm fairly certain there's a bug IdentityDecoder
LengthDelimitedDecoder.transfer(FileChannel, position, count). If
SessionInputBuffer.hasData() returns true, then an attempt is made to
read from the SessionInputBuffer into the FileChannel, but the
FileChannel is not positioned correctly
Works for me, although I should have a better feel for it by the end
of this coming week. Absolutely no strong objections, though.
Sam
On Sun, Jun 8, 2008 at 1:03 PM, Oleg Kalnichevski [EMAIL PROTECTED] wrote:
Sam et al
How do you feel about cutting the 4.0-beta2 release of HttpCore some
Done, thanks for the heads-up.
On Sun, Jun 8, 2008 at 11:53 AM, Oleg Kalnichevski [EMAIL PROTECTED] wrote:
On Sun, 2008-06-08 at 13:21 +, [EMAIL PROTECTED] wrote:
Author: sberlin
Date: Sun Jun 8 06:21:20 2008
New Revision: 664505
URL: http://svn.apache.org/viewvc?rev=664505view=rev
If the library contains only annotations, there should be no problem.
Annotations are only strictly required at compile-time. At runtime,
the annotations don't have to be on the classpath (even if they have a
RetentionPolicy of Runtime).
Sam
On Fri, Jun 6, 2008 at 10:02 AM, Ortwin Glück [EMAIL
[
https://issues.apache.org/jira/browse/HTTPCORE-162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12602928#action_12602928
]
Sam Berlin commented on HTTPCORE-162:
-
FWIW, this kind of thing is an excellent use
Hi Folks,
I'm starting to get into using the client side of httpcore-nio, and am
using AsyncNHttpClientHandler w/ NHttpRequestExecutionHandler.
One thing I'm finding slightly odd is the order that way the handlers
processors are notified of incoming responses. The order right now
is:
1)
Reporter: Sam Berlin
Fix For: 4.0 Beta 1
HttpClient.execute should throw only one exception, for easier general use.
HttpMethod constructors (HttpGet, HttpPut, etc..) should throw
IllegalArgumentException in the string constructor (imply the string is
pre-checked). People wanting
[
https://issues.apache.org/jira/browse/HTTPCLIENT-779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sam Berlin updated HTTPCLIENT-779:
--
Attachment: httpclient-exception-cleanup.txt
patch attached.
toplevel exception cleanup
[
https://issues.apache.org/jira/browse/HTTPCLIENT-779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12600903#action_12600903
]
Sam Berlin commented on HTTPCLIENT-779:
---
Sure thing, that's a good idea
[
https://issues.apache.org/jira/browse/HTTPCLIENT-779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sam Berlin updated HTTPCLIENT-779:
--
Attachment: httpclient-exception-cleanup.txt
take two.
toplevel exception cleanup
I wonder if putting a small Thread.yield() or Thread.sleep(500) right
before the assertEquals could fix it. It could be that the the
continuum box is overloaded, so the context hasn't shifted to the
localserver thread to accept the connection by the time the
assertEquals has run.
Sam
On
I personally think that just throwing IOException from execute is the best
course of action (and allowing the cause to be retrieved from getCause). I
offered HttpClientException as a new type simply because a third exception
that isn't IOException or HttpException seemed like a good compromise --
[
https://issues.apache.org/jira/browse/HTTPCLIENT-747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12599616#action_12599616
]
Sam Berlin commented on HTTPCLIENT-747:
---
Can't reproduce this issue anymore
[
https://issues.apache.org/jira/browse/HTTPCLIENT-777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sam Berlin updated HTTPCLIENT-777:
--
Attachment: changes.txt
Patch thta always recreates the uniquePoolEntry if the prior
[
https://issues.apache.org/jira/browse/HTTPCLIENT-776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12598339#action_12598339
]
Sam Berlin commented on HTTPCLIENT-776:
---
The only possible way I can see the NPE
[
https://issues.apache.org/jira/browse/HTTPCLIENT-776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12598357#action_12598357
]
Sam Berlin commented on HTTPCLIENT-776:
---
The NPE can happen if another thread
[
https://issues.apache.org/jira/browse/HTTPCLIENT-776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sam Berlin updated HTTPCLIENT-776:
--
Attachment: changes.txt
Attached is a testcase that reproduces the problem
[
https://issues.apache.org/jira/browse/HTTPCLIENT-776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12598458#action_12598458
]
Sam Berlin commented on HTTPCLIENT-776:
---
Looks like this change:
http://fisheye6
[
https://issues.apache.org/jira/browse/HTTPCLIENT-776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sam Berlin updated HTTPCLIENT-776:
--
Attachment: changes.txt
The attached patch should fix the problems, plus adds a few new
Hmm... As I'm typing this, I an idea came to me. Originally, I had dismissed
using a separate client class because it would be difficult to tie the
connection limits together. What just occurred to me (duh), is that the
connection manager is a separate object. The second client class
Things look great on the server-side. It's going to take a bit of
time (I'd guess no shorter than a month) to hash things out with the
client side. If folks think a month is too long, my guess is that the
client side is stable and the API is ok, but it'll take some using it
to verify
+1
On Sun, May 4, 2008 at 2:30 PM, sebb [EMAIL PROTECTED] wrote:
+1
2008/5/4 Oleg Kalnichevski [EMAIL PROTECTED]:
+1
Oleg
On Sun, 2008-05-04 at 18:49 +0200, Oleg Kalnichevski wrote:
Please vote on releasing these packages as HttpComponents Client
4.0-alpha4. The vote
[
https://issues.apache.org/jira/browse/HTTPCLIENT-769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12593861#action_12593861
]
Sam Berlin commented on HTTPCLIENT-769:
---
That's great, Oleg! As far as I can
[
https://issues.apache.org/jira/browse/HTTPCLIENT-769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12593693#action_12593693
]
Sam Berlin commented on HTTPCLIENT-769:
---
We also just released a new beta
Affects Versions: 4.0 Alpha 3
Reporter: Sam Berlin
.. patch coming.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e
[
https://issues.apache.org/jira/browse/HTTPCLIENT-764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sam Berlin updated HTTPCLIENT-764:
--
Attachment: httpclient-javadocs.txt
This is a small patch for improving some httpclient
We're going to release a LimeWire beta sometime this week with the
latest client core snapshots (or betas, if they're out by then), but
we've had a few betas already (prior to the latest concurrency fixes)
and everything seems to be working great. I'm very confident that the
server-side API is
Hi Folks,
There's been a number of times that we've been looking to debug things
within httpcore httpcore-nio, but have to resort to recompiling
and/or using a debugger with breakpoints, due to no logging within the
package. I can understand the desire to reduce dependencies, but I
humbly
[
https://issues.apache.org/jira/browse/HTTPCLIENT-760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12581003#action_12581003
]
Sam Berlin commented on HTTPCLIENT-760:
---
I should mention the patch also has
[
https://issues.apache.org/jira/browse/HTTPCLIENT-734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sam Berlin updated HTTPCLIENT-734:
--
Attachment: changes.txt
Ya, it makes sense. I took a swipe at using
[
https://issues.apache.org/jira/browse/HTTPCLIENT-734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12580518#action_12580518
]
sberlin edited comment on HTTPCLIENT-734 at 3/19/08 12:54 PM:
[
https://issues.apache.org/jira/browse/HTTPCLIENT-734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sam Berlin updated HTTPCLIENT-734:
--
Attachment: changes.txt
This patch takes a different approach than the prior one. Instead
I was curious about this, so just setup Maven Subclipse integration,
and everything checked out well. I have six mvn+svn projects setup in
Eclipse now:
- httpclient-TRUNK
- httpcomponents-client-TRUNK
- httpcomponents-core-TRUNK
- httpcore-nio-TRUNK
- httpcore-TRUNK
- httpmime-TRUNK
(The
[
https://issues.apache.org/jira/browse/HTTPCLIENT-734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sam Berlin updated HTTPCLIENT-734:
--
Attachment: changes.txt
Here's the exact same patch, just diffed against the most recent
/browse/HTTPCLIENT-759
Project: HttpComponents HttpClient
Issue Type: Bug
Components: HttpClient
Affects Versions: 4.0 Alpha 3
Reporter: Sam Berlin
See HTTPCLIENT-747 for more info. Basically the deal is that an entry is
always allocated
[
https://issues.apache.org/jira/browse/HTTPCLIENT-759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sam Berlin updated HTTPCLIENT-759:
--
Attachment: changes.txt
The attached patch fixes the problem and adds two tests (that used
[
https://issues.apache.org/jira/browse/HTTPCLIENT-734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12579637#action_12579637
]
Sam Berlin commented on HTTPCLIENT-734:
---
That makes sense -- I agree
[
https://issues.apache.org/jira/browse/HTTPCLIENT-759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12579660#action_12579660
]
Sam Berlin commented on HTTPCLIENT-759:
---
Ya that's probably the best course
[
https://issues.apache.org/jira/browse/HTTPCLIENT-747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12579200#action_12579200
]
Sam Berlin commented on HTTPCLIENT-747:
---
Thanks I'll think about it and post
[
https://issues.apache.org/jira/browse/HTTPCLIENT-747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12578994#action_12578994
]
Sam Berlin commented on HTTPCLIENT-747:
---
We're still being hit
[
https://issues.apache.org/jira/browse/HTTPCLIENT-747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12578995#action_12578995
]
Sam Berlin commented on HTTPCLIENT-747:
---
Also, if it's useful -- the first two
Is there a preferred way of closing a connection using the IOReactors
[N]HttpRequestExecutionHandlers? The only thing I can think of
would be to close it in submitRequest or handleResponse. Is there
another (better?) way of doing it?
Thanks,
Sam
handleResponse are the
only options, I think?
Sam
On Thu, Mar 13, 2008 at 4:11 PM, Oleg Kalnichevski [EMAIL PROTECTED] wrote:
On Thu, 2008-03-13 at 15:36 -0400, Sam Berlin wrote:
Is there a preferred way of closing a connection using the IOReactors
[N]HttpRequestExecutionHandlers? The only thing
That's a bug with the method signature. It should be defined as:
public void removeRequestInterceptorByClass(Class? extends
HttpRequestInterceptor clazz);
Sam
On Mon, Mar 10, 2008 at 8:49 AM, Johannes Koch
[EMAIL PROTECTED] wrote:
Hi,
I try to remove the HTTP request interceptor
Components: HttpCore NIO
Reporter: Sam Berlin
See: http://marc.info/?l=httpclient-commons-devm=120484419511590w=2
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online
[
https://issues.apache.org/jira/browse/HTTPCORE-154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sam Berlin updated HTTPCORE-154:
Attachment: changes.txt
Attached patch adds a test and changes DefaultNHttpClientConnection
Hi Folks,
It looks like snapshot builds occasionally get uploaded to
http://people.apache.org/repo/m2-snapshot-repository/org/apache/httpcomponents/
. Is there any rhyme or reason for when they're added? (And how are
they added?)
Would it be possible for r632589 (or later -- no big difference)
Type: Bug
Components: HttpCore NIO
Reporter: Sam Berlin
AsyncNHttpServiceHandler.processRequest always submits the response at the
bottom of the method, which breaks NHttpResponseTriggers that don't want to
trigger immediately. Patch + test cases (that break before
[
https://issues.apache.org/jira/browse/HTTPCORE-151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sam Berlin updated HTTPCORE-151:
Attachment: changes.txt
Patch w/ fixes test cases.
AsyncNHttpServiceHandler broken
To spur some interest in the fisheye view (though it makes zero
difference), here's the comparable link:
http://fisheye6.cenqua.com/changelog/httpcomponents?cs=619163 .
Sam
On Mon, Feb 25, 2008 at 4:47 PM, Oleg Kalnichevski [EMAIL PROTECTED] wrote:
On Sat, 2008-02-23 at 10:17 +0100, Roland
Looks like it's up running at:
http://fisheye6.cenqua.com/browse/httpcomponents .
Thanks everyone!
Sam
On Wed, Feb 20, 2008 at 9:42 AM, Erik Abele [EMAIL PROTECTED] wrote:
On 20.02.2008, at 15:16, Oleg Kalnichevski wrote:
On Wed, 2008-02-20 at 01:39 -0500, Sam Berlin wrote:
Hi Everyone
[
https://issues.apache.org/jira/browse/HTTPCORE-148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12571453#action_12571453
]
Sam Berlin commented on HTTPCORE-148:
-
Yes, that approach looks good.
Is it OK
[
https://issues.apache.org/jira/browse/HTTPCORE-148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sam Berlin updated HTTPCORE-148:
Attachment: client-changes.txt
Attached are changes necessary for the client side. It turned
[
https://issues.apache.org/jira/browse/HTTPCORE-148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sam Berlin updated HTTPCORE-148:
Attachment: changes.txt
Attached is a small revision to update javadocs, add an easy-to-use
[
https://issues.apache.org/jira/browse/HTTPCORE-148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12571198#action_12571198
]
Sam Berlin commented on HTTPCORE-148:
-
Would it be possible to leave thread-safety
[
https://issues.apache.org/jira/browse/HTTPCORE-148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sam Berlin updated HTTPCORE-148:
Attachment: changes.txt
Alright -- suppose that'd be dreaming to hope implementations do
Hi FishEye Folk HttpComponents Folk,
As our project uses HttpComponents more more (and as I'm hacking
within it at the moment), I find myself wanting to see a FishEye view
of the repository more more.
There appears to be some limited Apache projects at:
http://fisheye6.cenqua.com/ . The page
[
https://issues.apache.org/jira/browse/HTTPCORE-148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12570511#action_12570511
]
Sam Berlin commented on HTTPCORE-148:
-
Excellent suggestion. Working on the branch
throttling.
Anyone able to do this? (If I can do it too, let me know. Though I
don't think I'm a 'project member'.)
Sam
On Feb 19, 2008 2:56 PM, Sam Berlin [EMAIL PROTECTED] wrote:
Hi FishEye Folk HttpComponents Folk,
As our project uses HttpComponents more more (and as I'm hacking
within
[
https://issues.apache.org/jira/browse/HTTPCORE-148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12569743#action_12569743
]
Sam Berlin commented on HTTPCORE-148:
-
Shouldn't hold back any work on the client
[
https://issues.apache.org/jira/browse/HTTPCORE-148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sam Berlin updated HTTPCORE-148:
Attachment: changes.txt
Attached is a final revision of the async service side. There's a slew
1 - 100 of 115 matches
Mail list logo
