Re: svn commit: r655311 - in /httpcomponents/httpclient/trunk: NTLM_SUPPORT.txt RELEASE_NOTES.txt

On Sun, 2008-05-11 at 19:48 +0100, sebb wrote: > On 11/05/2008, Oleg Kalnichevski <[EMAIL PROTECTED]> wrote: > > On Sun, 2008-05-11 at 15:20 +0100, sebb wrote: > > > On 11/05/2008, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > > Author: oleg

Re: [continuum] BUILD FAILURE: HttpComponents - HttpComponents Client - Build Def:

On Sun, 2008-05-11 at 19:51 +0100, sebb wrote: > On 11/05/2008, Oleg Kalnichevski <[EMAIL PROTECTED]> wrote: > > On Sun, 2008-05-11 at 19:44 +0100, sebb wrote: > > > After logging in, I can see that the first error is: > > > > > > [INFO] Compilation

Re: [continuum] BUILD FAILURE: HttpComponents - HttpComponents Client - Build Def:

On Sun, 2008-05-11 at 20:09 +0100, sebb wrote: > On 11/05/2008, Oleg Kalnichevski <[EMAIL PROTECTED]> wrote: > > On Sun, 2008-05-11 at 19:51 +0100, sebb wrote: > > > On 11/05/2008, Oleg Kalnichevski <[EMAIL PROTECTED]> wrote: > > > > On

Re: Final classes and methods

On Thu, 2008-05-15 at 12:28 -0700, David Byrne wrote: > I'm curious why so many classes and methods are declared final. For example, > I'd like to extend BasicHttpProcessor, but it's final. Instead, I'm basically > copying and pasting into a new class, then modifying what I want. It's not > the

Re: Final classes and methods

client objects/classes? It should not be a problem, I think Oleg > > Thanks, > David > > > - Original Message > From: Oleg Kalnichevski <[EMAIL PROTECTED]> > To: HttpComponents Project > Sent: Thursday, May 15, 2008 2:45:18 PM > Subject: Re: Fi

Re: SEARCH Method

On Mon, 2008-05-19 at 16:35 -0700, Pankaj Arora wrote: > Hi, > As per Http 1.1 specifications > > 5.1.1 Method > > The Method token indicates the method to be performed on the resource > identified by the Request-URI. The method is case-sensitive. > >Method = "OPTIONS"

[HttpClient] Support for stateful / user specific connections

Folks, I finally resolved a long standing problem with HttpClient not taking into account the user context when pooling / re-using connections. HttpClient should now be able to correctly handle stateful / user specific connections such as persistent NTLM connections and SSL connections with c

Re: Using Simple Input/Output Buffers with Synapse

Asankha C. Perera wrote: Hi Oleg I first tried to do the throttling version for Synapse, but didn't really get to a stable point last night.. and thus, looked at using the simple buffers first as you suggested.. I am now getting the following exception, and am trying to figure out what went

[HttpClient] Logging wars revisited for the last time (really)

Folks, We finally need to make a decision on the logging toolkit we are going to use in HttpClient 4.0 onwards. http://issues.apache.org/jira/browse/HTTPCLIENT-416 Here's my suggestion about the course of action we should take (1) I'll start a poll on the user list about popular opinion on the

Re: [HttpClient] Logging wars revisited for the last time (really)

On Fri, 2008-05-23 at 11:09 +0100, sebb wrote: > On 23/05/2008, Oleg Kalnichevski <[EMAIL PROTECTED]> wrote: > > Folks, > > > > We finally need to make a decision on the logging toolkit we are going > > to use in HttpClient 4.0 onwards. > > I agree th

[ANNOUNCEMENT] HttpClient 4.0 is nearing API freeze / API review request

Folks The redesign of HttpClient is now complete. All known problems with the old (3.x) API and architecture limitations have been resolved. All features planned for the 4.0 release are now in place. Due to the release schedule of one of our upstream projects we will have to freeze the 4.0 API r

Re: Using Simple Input/Output Buffers with Synapse

On Sun, 2008-05-25 at 01:17 +0530, Asankha C. Perera wrote: > Hi Oleg > ... > I also have a question on the Shared buffer class.. in > SharedInputBuffer::consumeContent() > > > why

Re: [ANNOUNCEMENT] HttpClient 4.0 is nearing API freeze / API review request

a lot easier to deal with, so > consider dropping the set methods if they aren't essential. > > Another point is visibility of variables - as far as possible these > should be private. > It's easy to relax the restriction later if necessary. This is > particularly importa

Re: API review request / HttpException subclass of IOException

On Mon, 2008-05-26 at 20:00 -0400, Sam Berlin wrote: > >Exception handling is one of those. We cannot make everyone happy. > > I think in this case it might actually be possible to appease most > people. I agree with Oleg that the separation between HttpException & > IOException is useful, especi

Re: HttpClient 3.1 - cookie handling bug (?)

On Tue, 2008-05-27 at 16:29 +0400, Oleg L wrote: > Guys, > > I hope it is not impolite to send this question to the devs list > directly w/o discussing the issue on the users list first, I guess I > just understand well enough what's going on and what's wrong here. > We are fairly lenient about

RE: API review request / HttpException subclass of IOException

changes you deem necessary. Probably opening a JIRA and attaching a patch for review would be a prudent way forward. Meanwhile I'll try my best to make sure you get your commit rights in time. If I fail to get hold of Erik, I'll send the account request myself. Cheers, Oleg > --

Re: Continuum build - "fixed"

sebb wrote: I've fixed the Continuum build by changing from mvn clean package to mvn clean install so that the core snapshot is made available to the client build. However, the Client build still fails - but this time it's a test error. It is this test case. What it truly puzzling is that

Re: bug? headers double when retrying the request

Jens Wilke wrote: Hi, just found something strange: 28 May 2008 17:58:22,972 DEBUG http-8899-Processor25 apache.http.headers - >> GET /xy HTTP/1.1 28 May 2008 17:58:22,972 DEBUG http-8899-Processor25 apache.http.headers - >> Host: localhost: 28 May 2008 17:58:22,972 DEBUG http-8899-Proces

Re: bug? headers double when retrying the request

Jens Wilke wrote: On Wednesday 28 May 2008, Oleg Kalnichevski wrote: Are you running 4.0a4 release or a SVN snapshot? I believe I fixed the cause of the problem a week ago. Please try the latest snapshot out and see if the problem persists. Oleg, I now moved to the SVN snapshot. Exact same

Re: HttpConnectionManagerParams -> ConnManagerParams

Jens Wilke wrote: Hi, back to API review, I see the name changed in in the trunk. See: http://fisheye6.atlassian.com/changelog/httpcomponents?cs=658785 However I think "Conn" is not a good idea since it is not a commonly used abbreviation for Connection. Cite from http://java.sun.com/docs/code

Re: Issue closing SSL sessions when using NIO

On Thu, 2008-05-29 at 12:38 +0530, Asankha C. Perera wrote: > Hi all > > It seems like sometimes client connections over SSL does not properly > terminate after the keepalive socket closes. This happens with the > Synapse ESB (which uses HttpCore/NIO-4.0-beta1), but I am still > investigating i

Re: bug? headers double when retrying the request

On Wed, 2008-05-28 at 22:29 +0200, Oleg Kalnichevski wrote: > Jens Wilke wrote: > > On Wednesday 28 May 2008, Oleg Kalnichevski wrote: > >> Are you running 4.0a4 release or a SVN snapshot? I believe I fixed the > >> cause of the problem a week ago. Please try the latest

Re: headers gone on trunk

On Fri, 2008-05-30 at 15:51 +0200, Jens Wilke wrote: > On Friday 30 May 2008, Jens Wilke wrote: > > I am now on the 4.0 trunk code. When I do a HttpPost and set an additional > > header nothing is send to the remote side. I am not sure whether this > > relates to latest fix on trunk, but OTOH I am

Re: BasicHttpParams not thread-safe?

On Sun, 2008-06-01 at 15:29 +0100, sebb wrote: > It looks like BasicHttpParams is not thread-safe. > > Although it uses a HashMap (which is thread-safe) to store parameters, > the instance variable which holds it is not final or volatile, and > accesses to it are not synchronized. > > If one thre

Re: BasicHttpParams not thread-safe?

On Sun, 2008-06-01 at 16:13 +0100, sebb wrote: > On 01/06/2008, Oleg Kalnichevski <[EMAIL PROTECTED]> wrote: > > On Sun, 2008-06-01 at 15:29 +0100, sebb wrote: > > > It looks like BasicHttpParams is not thread-safe. > > > > > > Although it uses

Re: [HttpClient] Logging wars revisited for the last time (really)

Folks, I started the poll on the logging tool for HttpClient 4.x on the user list. If you feel strongly about a particular option, please make your opinion known. Oleg On Fri, 2008-05-23 at 13:12 +0200, Oleg Kalnichevski wrote: > On Fri, 2008-05-23 at 11:09 +0100, sebb wrote: > > On 2

Re: HttpClient 4, I/O exception and

On Wed, 2008-06-04 at 09:40 +0200, Martin Zdila wrote: > Hello > > I am using HttpClient 4.0-alpha4 with following settings: > > > final HttpParams params = new BasicHttpParams(); > HttpConnectionManagerParams.setMaxTotalConnections(params, 100); > HttpConnectionManagerParams.setMaxC

Re: Timing of HttpProcessor.process w/ ClientHandlers

Sam Berlin wrote: 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 rig

Re: HttpClient 4, I/O exception and

On Thu, 2008-06-05 at 08:59 +0200, Martin Zdila wrote: > Thanks for reply, Oleg. > > > This is clearly a bug. I believe it has already been fixed in the SVN > > trunk. Please re-test application with the latest HttpClient snapshot > > and let me know if the problem still persists. > > I've upgrad

Re: HttpClient 4, I/O exception and

On Thu, 2008-06-05 at 11:30 +0200, Martin Zdila wrote: > > > SocketInputStream.socketRead0(FileDescriptor, byte[], int, int, int) > > > line: not available [native method] [local variables unavailable] > > > > The thread is blocked in the socket read operation. This is perfectly > > normal. If you

Re: HttpClient 4, I/O exception and

On Fri, 2008-06-06 at 11:57 +0200, Martin Zdila wrote: > Oleg, > > > > > > SocketInputStream.socketRead0(FileDescriptor, byte[], int, int, int) > > > > > line: not available [native method] [local variables unavailable] > > > > > > > > The thread is blocked in the socket read operation. This is p

Re: HttpClient 4, I/O exception and

On Fri, 2008-06-06 at 13:56 +0200, Martin Zdila wrote: > Hi Oleg > > > Is this a pissing contest for you or something? If so, I have neither > > time nor inclination to participate. > > I am sorry that you think that my only intent is to waste your time. I just > wanted to help solve this issue,

Re: HttpClient 4, I/O exception and

On Fri, 2008-06-06 at 15:06 +0200, Martin Zdila wrote: > Hi Ortwin > > On Fri 6. June 2008 14:11:47 Ortwin Glück wrote: > > DEBUG [main] org.apache.http.wire - >> "POST /post.html HTTP/1.1[EOL]" > > DEBUG [main] org.apache.http.wire - >> "Content-Length: 0[EOL]" > > DEBUG [main] org.apache.http.w

Re: HttpClient 4, I/O exception and

On Fri, 2008-06-06 at 15:43 +0200, Martin Zdila wrote: > > I'll patch HttpClient to throw an exception if an attempt is made to > > retry a request with a non-repeatable request entity. > > thanks > > > Meanwhile I suggest you change you code to use a repeatable entity, such > > as StringEntity o

Re: HttpClient 4, I/O exception and

On Fri, 2008-06-06 at 16:08 +0200, Martin Zdila wrote: > > > i would be happy if we could find out why those "I/O Exception"s are > > > occuring and to fix it. > > > > Most likely this is because the connection timed out on the server side. > > The target server dropped it, but the JVM on the clien

Re: HttpClient 4, I/O exception and

On Fri, 2008-06-06 at 16:36 +0200, Martin Zdila wrote: > > > It would be nice if HttpClient could detect it somehow if it is possible. > > > > It would also be great if HttpClient could walk my dog > > this would be fancy feature but with no real use. i think you should rather > decide for detect

Re: svn commit: r664505 - in /httpcomponents/httpclient/trunk/module-client/src: main/java/org/apache/http/client/ main/java/org/apache/http/client/methods/ main/java/org/apache/http/impl/client/ test

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=664505&view=rev > Log: > HTTPCLIENT-779: toplevel exception cleanup. HttpClient.execute now only > throws an IOException

[HttpCore] 4.0-beta2 soon?

Sam et al How do you feel about cutting the 4.0-beta2 release of HttpCore some time soon? Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]

Re: [HttpCore] 4.0-beta2 soon?

un 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 > > time soon? > > > > Oleg > > > > > >

Re: FileContentDecoder.transfer

On Mon, 2008-06-09 at 12:34 -0400, Sam Berlin wrote: > 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 FileChan

Re: [HttpCore] 4.0-beta2 soon?

? Cheers Oleg > 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 > > time soon? > > > > Oleg > > > > > > --

[POLL][RESULT] Logging toolkit for HttpClient 4.x

 Commons Logging: 8 slf4j: 10 java.util.logging:2 20 votes (out of ~330 subscribers) is hardly representative but there is not much I can do about it It looks like there is enough support to keep Commons Logging. Given the

[HttpCore] HttpCore 4.0-beta2 pre-release packages

Folks, Please do try to find a few minutes to review the release notes and the packages Release notes: http://people.apache.org/~olegk/httpcore-4.0-beta2-preview/RELEASE_NOTES.txt Packages: http://people.apache.org/~olegk/httpcore-4.0-beta2-preview/packages/ Oleg -

Re: ClientContext in AbstractHttpClient

On Fri, 2008-06-13 at 13:16 -0700, Bob Lee wrote: > call createHttpContext() instead of new > BasicHttpContext() You are absolutely right. Fixed in the SVN trunk. Many thanks Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] Fo

Re: Finishing the ContentEncoder

On Sun, 2008-06-15 at 10:20 -0400, Sam Berlin wrote: > 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

Re: svn commit: r667954

view=rev > > Log: > > HTTPCORE-163: Fixed AbstractMultiworkerIOReactor#execute() to correctly > > propagate the original I/O exception in case of an abnormal termination. > > Contributed by Patrick Moore > > Reviewed by Oleg Kalnichevski > > ...

Re: [HttpCore] HttpCore 4.0-beta2 pre-release packages

Oleg Kalnichevski wrote: Folks, Please do try to find a few minutes to review the release notes and the packages Release notes: http://people.apache.org/~olegk/httpcore-4.0-beta2-preview/RELEASE_NOTES.txt Packages: http://people.apache.org/~olegk/httpcore-4.0-beta2-preview/packages/ Oleg

[HttpCore] Structure outline for the HttpCore tutorial

Wiki notifications appear broken at the moment, so I am sending out this message to keep everyone in the loop. I put together a rough structure outline for the HttpCore tutorial. http://wiki.apache.org/HttpComponents/HttpCoreTutorial Feel free to make changes and add content more content. Oleg

[VOTE] HttpComponents Core 4.0-beta2 release

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. Packages: http://people.apache.org/~olegk/httpcore-4.0-beta2/p

Re: [VOTE] HttpComponents Core 4.0-beta2 release

+1 Oleg On Tue, 2008-06-17 at 20:54 +0200, Oleg Kalnichevski 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 > thre

Re: UrlEncodedFormEntity w/ Encoding

Sam Berlin wrote: The constructor for UrlEncodedFormEntity doesn't seem to include the encoding when setting the contentType. This is in contrast to it's parent class (StringEntity) that does set the contentType. (The content-type from StringEntity doesn't stick, though, because it's set in the

[VOTE][RESULT] HttpComponents Core 4.0-beta2 release

The vote to release HttpComponents Core 4.0-beta2 has passed with the following results +1 (6 binding votes in total) Ortwin Glück * Sam Berlin <sberlin -at- apache.org> Sebastian Bazley * Asankha C. Perera * Ant Elder * Andrea Selva Paul Fremantle * Oleg Kalnichevski * * b

Re: [VOTE] HttpComponents Core 4.0-beta2 release

On Wed, 2008-06-18 at 12:56 +0100, sebb wrote: > On 17/06/2008, Oleg Kalnichevski <[EMAIL PROTECTED]> wrote: ... > This is not a release blocker, but I think future releases should > include a means to actually build and test on Java 1.3, i.e. either an > M1 build or Ant scri

Re: Can we make it easier to release resources?

Bob Lee wrote: Right now, we have to do something like this: HttpResponse r = client.execute(...) try { ... } finally { HttpEntity e = r.getEntity(); if (e != null) { // Soon to be renamed finish() e.consumeContent(); } } It might be nice if we could do something like this: Htt

Re: Can we make it easier to release resources?

Bob Lee wrote: On Fri, Jun 20, 2008 at 4:16 PM, Oleg Kalnichevski <[EMAIL PROTECTED]> wrote: I _really_, _really_ like this idea. However, what shall HttpClient do if it gets status code other than 200? Throw an exception? Ignore the status code? We could pass a response to the hand

Re: Can we make it easier to release resources?

Bob Lee wrote: On Fri, Jun 20, 2008 at 4:39 PM, Oleg Kalnichevski <[EMAIL PROTECTED]> wrote: Coming to think of it, It seems perfectly okay to leave this decision up to the individual handlers. Simple handlers might just thrown an exception on all status codes but 200. More complex one

Re: HttpParams rename??

On Sat, 2008-06-21 at 12:00 +0100, sebb wrote: > There seem to be quite a few people who assume the HttpParams class is > something to do with parameters used in HTTP requests. > > It's probably too late now, but is it worth considering renaming > HttpParams to avoid this confusion? I suspect the

Re: HttpParams rename??

Folks, How about a somewhat different approach? (1) Leave HttpCore be for now (2) Make the following changes in HttpClient * Introduce ClientConfig interface extending HttpParams * Rename all #getParams methods to #getConfig and change them to return ClientConfig (3) Plan for API breakag

[ANNOUNCEMENT] HttpComponents HttpCore 4.0-beta2 released

The Apache HttpComponents project is pleased to announce the release of HttpComponents HttpCore 4.0-beta2. This release adds a number of improvements to the NIO components, most notable being improved asynchronous client side and server side protocol handlers. There has been a number of importa

Re: NIO Connection Management

On Mon, 2008-06-23 at 21:01 +0200, Quintin Beukes wrote: > Hey, > > I checked out the EventDispatch thread the other day.. the > createConnection() inside the connected() method is what drew my > attention to it. > > Problem is that I put a breakpoint there, and the connection is > already made t

Re: NIO Connection Management

;s very complex I'll probably have it done/tested it 2/3 days. Q On 6/23/08, Oleg Kalnichevski <[EMAIL PROTECTED]> wrote: On Mon, 2008-06-23 at 21:01 +0200, Quintin Beukes wrote: > Hey, > > I checked out the EventDispatch thread the other day.. the > createConnection() in

Re: Possible Causes for "Connection reset by peer" when using NIO

On Wed, 2008-06-25 at 18:13 +0200, Hubert, Eric wrote: > Hi devs! > > first of all I'd like to apologize for posting a "user-problem" to two > dev-lists. I only did this as have not much background knowledge of the NIO > implementation and think a solid understanding of NIO is necessary to help

Re: Keep-Alive timeout & persistent connections

On Wed, 2008-06-25 at 17:14 -0400, Sam Berlin wrote: > Hi Folks, > > We just stumbled across an issue with persistent connections where the > server is sending a Connection: Keep-Alive header, but also a > Keep-Alive header with a timeout=## (and a max=##). HttpClient's > connection management se

Re: Keep-Alive timeout & persistent connections

n advantage. This however does not seem to require changes in the public API so it could be done after BETA1. What we need to do before the API freeze is to ensure there is a way to set a timeout value on individual managed connections. Oleg > Sam > > On Wed, Jun 25, 2008 at 5:33

Response handler API; was Re: Can we make it easier to release resources?

On Fri, 2008-06-20 at 11:50 -0700, Bob Lee wrote: ... > Or even something like this: > > public interface ResponseHandler { > T handle(HttpResponse response) throws IOException; > } > > String result = client.execute(myHandler); > > Then you could have a few reusable response handlers, like

Re: Keep-Alive timeout & persistent connections

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 to a unit test? > > Sam > Sam,

Re: Keep-Alive timeout & persistent connections

e connection is released. > > Sam > Can you take care of that or shall I do it? Oleg > On Mon, Jun 30, 2008 at 2:51 PM, Oleg Kalnichevski <[EMAIL PROTECTED]> wrote: > > On Mon, 2008-06-30 at 10:43 -0400, Sam Berlin wrote: > >> Yikes, that's no good. Did

Re: svn commit: r673172

On Tue, 2008-07-01 at 22:50 +0100, sebb wrote: > On 01/07/2008, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > Author: olegk > > Date: Tue Jul 1 11:52:41 2008 > > New Revision: 673172 > > > > URL: http://svn.apache.org/viewvc?rev=673172&view=rev > > Log: > > HTTPCLIENT-668: removed static l

Re: svn commit: r674186

On Sat, 2008-07-05 at 13:29 +0100, sebb wrote: > On 05/07/2008, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > Author: olegk > > Date: Sat Jul 5 05:18:54 2008 > > New Revision: 674186 > > ... > > > > Modified: > > httpcomponents/httpclient/trunk/module-client/src/main/java/org/apache/http/

Re: The Cookie jar's lid seems stuck

On Mon, 2008-07-07 at 14:24 +0200, Quintin Beukes wrote: > Some more strange behaviour. > > Sometimes when I step this code, it sends the second header even when > pausing for only 1 second (literally only a breakpoint, refresh, > alt+tab to eclipse, press continue button). > > I can't really pla

[HttpClient] 4.0 beta1 soon?

Folks There are no feature requests / open bugs targeted for BETA1 left. How do you feel about the current state of HttpClient's API? It is good enough to move to the BETA phase? Does anybody want to spend more time refining the API? What should be the plan now? Oleg -

Re: [HttpClient] 4.0 beta1 soon?

> Sam > > On Thu, Jul 10, 2008 at 4:59 PM, Oleg Kalnichevski <[EMAIL PROTECTED]> wrote: > > Folks > > > > There are no feature requests / open bugs targeted for BETA1 left. How > > do you feel about the current state of HttpClient's API? It is good >

Re: [HttpClient] 4.0 beta1 soon?

On Thu, 2008-07-10 at 17:32 -0400, Sam Berlin wrote: ... > While adding keep-alive support, I noticed that code-changes that need > to provide the ClientConnectionManager with more information aren't > possible without API changes. In the rest of HttpClient's code, > there's usually an HttpConte

Re: [HttpClient] 4.0 beta1 soon?

remember having this nagging feeling while doing the keep-alive that > > it was only possible to add because the API wasn't frozen. Ideally, > > it would have been possible (if a little less elegant) even if the API > > was frozen. > > > > Sam > > > >

Re: Can an HTTP server close the socket before its client has finished receiving the message?

On Fri, 2008-07-11 at 12:43 +0200, Ortwin Glück wrote: > Asanka, > > The exact timing of the remote side closing the connection shouldn't matter. > If > coded propertly, buffers are flushed before/on close. The TCP FIN sequence > will > be queued *after* all the data packets. So the data will

Re: Can an HTTP server close the socket before its client has finished receiving the message?

On Fri, 2008-07-11 at 19:19 +0200, Ortwin Glück wrote: > > Oleg Kalnichevski wrote: > > The most plausible cause of this problem is a failure to flush the > > output buffer on the server side. Given this is Weblogic, which is known > > to be very stable, I admit this

[HttpClient] formal 4.0 API freeze

It looks like folks at Google really have to lock down the API of their Android platform. That also means they are going to ship HttpClient 4.0 before we could release BETA1. I personally think it is very important to avoid API incompatibilities between the version of HttpClient shipped with

Re: [HttpClient] formal 4.0 API freeze

ut the HttpMime module. Cheers Oleg > Sam > > On Wed, Jul 16, 2008 at 3:03 AM, Oleg Kalnichevski <[EMAIL PROTECTED]> wrote: > > > > It looks like folks at Google really have to lock down the API of their > > Android platform. That also means they are going to s

[VOTE] HttpClient 4.0 API freeze

[ ] I am in favor of maintaining backward API compatibility for the 4.x code line starting with the revision 677250 [ ] I am against freezing 4.0 API at this point. API needs more work. This is a consensus vote. A -1 from a PMC member will effectively veto the motion.

Re: [VOTE] HttpClient 4.0 API freeze

[X] I am in favor of maintaining backward API compatibility Oleg On Fri, 2008-07-18 at 11:50 +0200, Oleg Kalnichevski wrote: > [ ] I am in favor of maintaining backward API compatibility > for the 4.x code line starting with the revision 677250 > [ ] I am against freezing 4.0 AP

Re: Understanding asynchrounous request processing in Apache Synapse/Axis2/Http Core NIO

On Sun, 2008-07-20 at 16:39 +0200, Hubert, Eric wrote: > Hi devs, > > we are facing an issue in Apache Synapse where HttpClientWorkers are in > the process of writing a response back to the client using > HttpCoreNIOSender.sendAsyncResponse(), but are then waiting at > org.apache.http.nio.util.Sha

[VOTE][RESULT] HttpClient 4.0 API freeze

The vote passed +1 Oleg Kalnichevski Ortwin Glueck Sam Berlin Ant Elder +0 Sebastian Bazley The decision can still be reverted should the 4.0 BETA1 release vote fail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For

Re: SecureProtocolSocketFactory with SSLContext

Bruno Harbulot wrote: Hello, Hi Bruno, I have implemented a SecureProtocolSocketFactory with support for setting an SSLContext [1], based on StrictSSLProtocolSocketFactory, which is available in the contribution package of HttpClient 3.1. Would this be of interest to have it included in th

Re: NIO HttpCore - Can requestInput result in two new requests

On Fri, 2008-08-15 at 14:57 -0700, Rae Egli wrote: Hi Rae > I modified the NHttpReverseProxy slightly to act as a normal proxy. > > What I am encountering is the strange situation that I receive two requests. > One from an already open connection (conn1) in requestReceived() and the > other

Re: NIO HttpCore - Can requestInput result in two new requests

On Sat, 2008-08-16 at 08:45 -0700, Rae Egli wrote: > Oleg, > > Thanks for getting back so quickly. > > I came to the same conclusion last night after having an even closer look at > the problem. However, it does seem that the reverseproxy example > misunderstands that concept as well as it c

Re: NIO HttpCore - Can requestInput result in two new requests

On Sun, 2008-08-17 at 21:43 -0700, Rae Egli wrote: > Oleg, > > > I do not think so. I just ran a simple test using Apache Benchmark with > > 20 concurrent connections and all looked quite okay to me. I put the > > reverse proxy in front of a local Tomcat instance. > > Thanks for going through

Re: NIO HttpCore - Can requestInput result in two new requests

On Mon, 2008-08-18 at 08:46 -0700, Rae Egli wrote: > Oleg, > > > > > I chose a reverse proxy as an example primarily due to the fact that a > > reverse proxy can get away with a much simpler connection management > > logic than a normal caching proxy. > > > One needs a significantly more compl

Re: NIO HttpCore - Can requestInput result in two new requests

Rae Egli wrote: Oleg, I am still not sure this is the case. Please take a closer look the #connected methods of ListeningHandler and ConnectingHandler. Listening protocol handler always creates a new ProxyTask instance on each incoming client connection, requests a completely _new_ connection

Re: Bug in HC

Quintin Beukes wrote: Hey, Recently I posted the following bug, in response to which someone told me to try the latest version of HC. Up till now I got along fine, since these would only occur once, at which time the exception will rise up through to the JMS provider, and then the message would

Re: Bug in HC

; Q > Quintin You only need the latest snapshot of HttpClient. http://people.apache.org/repo/m2-snapshot-repository/org/apache/httpcomponents/httpclient/4.0-alpha5-SNAPSHOT/ There is no need to upgrade HttpCore to a snapshot. Hope this helps Oleg > On Tue, Aug 19, 2008 at 12:10

[HttpClient] HttpClient 4.0-beta1 preview

Folks Please do try to find a few minutes to review the packages and the release notes for HttpClient 4.0-beta1 (these are preview packages, still tagged as 4.0-alpha5-SNAPSHOT) Release notes: http://people.apache.org/~olegk/httpclient-4.0-beta1-preview/RELEASE_NOTES.txt Packages: http://people

Re: [HttpClient] HttpClient 4.0-beta1 preview

ook like a release blocker to me. The problem results in a overwrite warning on some platforms but otherwise the extracted content of the package looks sane. What do you think? Oleg >...ant > > On Tue, Aug 19, 2008 at 10:58 PM, Oleg Kalnichevski <[EMAIL PROTECTED]>wrote: >

Re: HttpCore nio - Tunnelling

On Wed, 2008-08-20 at 16:12 -0700, Rae Egli wrote: > Does anybody have any suggestions as to how to implement tunneling to extend > the nio proxy server. > > I've looked at the potential of subclassing DefaultNHttpServerConnection on > the client side with a pass-through function once the clien

Re: [HttpClient] HttpClient 4.0-beta1 preview

20, 2008 at 4:45 PM, Oleg Kalnichevski <[EMAIL PROTECTED]> wrote: > > > On Wed, 2008-08-20 at 08:07 +0100, ant elder wrote: > > > The bin-with-dependencies distro on windows includes duplicate jars for > > > httpcore-4.0-beta2.jar and commons-logging-1.1.1.jar. I

[VOTE] HttpComponents Client 4.0-beta1 release

Please vote on releasing these packages as HttpComponents Client 4.0-beta1. 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 and there are more +1 than -1 votes. Packages: http://people.a

Re: [VOTE] HttpComponents Client 4.0-beta1 release

[x] +1 Release the packages as HttpComponents Client 4.0-beta1 On Sat, 2008-08-23 at 13:18 +0200, Oleg Kalnichevski wrote: > Please vote on releasing these packages as HttpComponents Client > 4.0-beta1. The vote is open for the next 72 hours, and only votes from > HttpComponents PMC me

Re: HttpCore - DefaultNHttpServerConnection

Rae Egli wrote: Oleg, Thanks for your suggestions regarding tunneling. Would it be possible to change the private scope to protected for requestParser, responseWriter as it prevents me from subclassing DefaultNHttpServerConnection? Thanks for your help. Done. You will need to pull the

Re: [Proposal] Apache Droids as subproject of HttpComponents (was Re: Apache Droids using Norbert)

Thorsten Scherler wrote: On Mon, 2008-02-25 at 13:35 +0100, Thorsten Scherler wrote: On Sat, 2008-02-23 at 09:16 +0100, Roland Weber wrote: Hi Thorsten, Is there are still interest to host Droids and sponsor it in incubation as mentioned in [2]? Definitely :-) Meanwhile, we have created a ch

[VOTE][RESULT] HttpComponents Client 4.0-beta1

The vote to release HttpComponents HttpClient 4.0-beta1 has passed with the following results +1 (5 binding votes in total) Oleg Kalnichevski * Asankha C. Perera * Thuannd Paul Fremantle * ant elder * Ortwin Glück * * binding votes Original voting thread: http://www.nabble.com/-VOTE

Re: Connection closes and SharedInputBuffer shutdown

On Fri, 2008-08-29 at 18:14 +0530, Asankha C. Perera wrote: > Hi Oleg > > I am looking at the SharedInputBuffer, for which Jason has proposed some > fixes (https://issues.apache.org/jira/browse/HTTPCORE-172), with which I > agree. > > Sometime back my original fix for it, was to not shutdown th

<    1   2   3   4   5   6   7   8   9   10   >