On Sep 11, 2012, at 8:27 AM, Oleg Kalnichevski wrote:
> On Mon, 2012-09-10 at 17:10 -0400, Daniel Kulp wrote:
>> On Sep 10, 2012, at 6:13 AM, Oleg Kalnichevski wrote:
>>
>>> I think this problem can be easily fixed. If the expected X500Principal
>>> is known in advance, one can stick it into t
On Mon, 2012-09-10 at 17:10 -0400, Daniel Kulp wrote:
> On Sep 10, 2012, at 6:13 AM, Oleg Kalnichevski wrote:
>
> > I think this problem can be easily fixed. If the expected X500Principal
> > is known in advance, one can stick it into the local execution context
> > as ClientContext#USER_TOKEN at
On Sep 10, 2012, at 6:13 AM, Oleg Kalnichevski wrote:
> I think this problem can be easily fixed. If the expected X500Principal
> is known in advance, one can stick it into the local execution context
> as ClientContext#USER_TOKEN attribute [1]. This will force the client to
> request connection
On Sun, 2012-09-09 at 08:14 -0400, Daniel Kulp wrote:
> On Sep 8, 2012, at 4:33 PM, Oleg Kalnichevski wrote:
> > I committed your patch with some minor tweaks. Please double-check.
> >
>
> Cool. Thanks. I'll take a look on Monday.
>
> > The fundamental problem here is that SSL connections set
On Sep 8, 2012, at 4:33 PM, Oleg Kalnichevski wrote:
> I committed your patch with some minor tweaks. Please double-check.
>
Cool. Thanks. I'll take a look on Monday.
> The fundamental problem here is that SSL connections set up on a per
> request (or per client basis) when kept alive by the
On Fri, 2012-09-07 at 12:53 -0400, Daniel Kulp wrote:
> On Sep 6, 2012, at 9:33 AM, Oleg Kalnichevski wrote:
>
> > On Wed, 2012-09-05 at 10:49 -0400, Daniel Kulp wrote:
> >> Still not sure about the Proxy stuff at all, but that's likely because I
> >> don't know much about Proxies at all. I'll
On Sep 6, 2012, at 9:33 AM, Oleg Kalnichevski wrote:
> On Wed, 2012-09-05 at 10:49 -0400, Daniel Kulp wrote:
>> Still not sure about the Proxy stuff at all, but that's likely because I
>> don't know much about Proxies at all. I'll likely need to look more into
>> what proxy stuff does on the
On Thu, 2012-09-06 at 10:14 -0400, Daniel Kulp wrote:
> On Sep 6, 2012, at 9:42 AM, Oleg Kalnichevski wrote:
>
> > On Wed, 2012-09-05 at 15:30 -0400, Daniel Kulp wrote:
> >> On Sep 5, 2012, at 10:49 AM, Daniel Kulp wrote:
> >>
> >> OK. Went ahead and ripped out the HttpHost related stuff and r
On Thu, 2012-09-06 at 10:12 -0400, Daniel Kulp wrote:
> On Sep 6, 2012, at 9:40 AM, Oleg Kalnichevski wrote:
> > On Wed, 2012-09-05 at 10:55 -0400, Daniel Kulp wrote:
> >> On Sep 5, 2012, at 9:35 AM, Alessio Soldano wrote:
> >>
> >>> On 09/04/2012 09:03 PM, Daniel Kulp wrote:
>
> That
On 09/06/2012 04:12 PM, Daniel Kulp wrote:
>>
>> I personally use Squid [1] running locally in non-daemon mode to test
>> HttpClient against. It is one of the most widely used proxies around.
>
>
> I was originally looking at this, but there is a big disadvantage: it's
> external to the build.
On Sep 6, 2012, at 9:42 AM, Oleg Kalnichevski wrote:
> On Wed, 2012-09-05 at 15:30 -0400, Daniel Kulp wrote:
>> On Sep 5, 2012, at 10:49 AM, Daniel Kulp wrote:
>>
>> OK. Went ahead and ripped out the HttpHost related stuff and replaced with
>> a CXFHttpHost which is basically a copy of the H
On Sep 6, 2012, at 9:40 AM, Oleg Kalnichevski wrote:
> On Wed, 2012-09-05 at 10:55 -0400, Daniel Kulp wrote:
>> On Sep 5, 2012, at 9:35 AM, Alessio Soldano wrote:
>>
>>> On 09/04/2012 09:03 PM, Daniel Kulp wrote:
That said, there is still a bit of work todo:
1) Proxy suppo
On Wed, 2012-09-05 at 15:30 -0400, Daniel Kulp wrote:
> On Sep 5, 2012, at 10:49 AM, Daniel Kulp wrote:
>
> >
> > On Sep 5, 2012, at 9:26 AM, Oleg Kalnichevski wrote:
> >>
> >> Just ditch HttpHost. You obviously need a richer class to represent
> >> connection routes. HttpClient has HttpRoute
On Wed, 2012-09-05 at 10:55 -0400, Daniel Kulp wrote:
> On Sep 5, 2012, at 9:35 AM, Alessio Soldano wrote:
>
> > On 09/04/2012 09:03 PM, Daniel Kulp wrote:
> >>
> >> That said, there is still a bit of work todo:
> >>
> >> 1) Proxy support - haven't looked into this at all yet. Hard for me to
On Wed, 2012-09-05 at 10:49 -0400, Daniel Kulp wrote:
> On Sep 5, 2012, at 9:26 AM, Oleg Kalnichevski wrote:
...
> >> 2) Lots of issues trying to associate the request with the connection at
> >> connection creation time. I needed information from the request in order
> >> to setup the SSL s
On Sep 5, 2012, at 10:49 AM, Daniel Kulp wrote:
>
> On Sep 5, 2012, at 9:26 AM, Oleg Kalnichevski wrote:
>>
>> Just ditch HttpHost. You obviously need a richer class to represent
>> connection routes. HttpClient has HttpRoute class for that matter. You
>> probably should be using a custom cla
On Sep 5, 2012, at 9:35 AM, Alessio Soldano wrote:
> On 09/04/2012 09:03 PM, Daniel Kulp wrote:
>>
>> That said, there is still a bit of work todo:
>>
>> 1) Proxy support - haven't looked into this at all yet. Hard for me to
>> test as well as I don't have any sort of proxy setup anywhere.
On Sep 5, 2012, at 9:26 AM, Oleg Kalnichevski wrote:
> HC connection pools distinguish between route info and connection state.
> Routes are immutable and are well known in advance. A route in its basic
> form is a scheme/host/port combo. At connection creation time only the
> route matters as al
On 09/04/2012 09:03 PM, Daniel Kulp wrote:
>
> That said, there is still a bit of work todo:
>
> 1) Proxy support - haven't looked into this at all yet. Hard for me to test
> as well as I don't have any sort of proxy setup anywhere. I may need to look
> into how to setup a simple proxy to di
On Tue, 2012-09-04 at 15:20 -0400, Daniel Kulp wrote:
> On Aug 6, 2012, at 10:43 AM, Oleg Kalnichevski wrote:
> CXF allows these to be configured on a per-client (and sometimes even
> per- request) basis.It looks like HC seems to have these on the
> connection factory.
> >>>
>
On Tue, 2012-09-04 at 15:03 -0400, Daniel Kulp wrote:
> Finally had a chance over the last week or so to re-dig into the async http
> stuff. You've probably seen a lot of commits and such related to it. :-)
>
> Good news:
> ALL of the CXF system tests now pass using it instead of the URLConnec
On Aug 6, 2012, at 10:43 AM, Oleg Kalnichevski wrote:
CXF allows these to be configured on a per-client (and sometimes even
per- request) basis.It looks like HC seems to have these on the
connection factory.
>>>
>>> It does not have to be this way. Connections can start off as
Finally had a chance over the last week or so to re-dig into the async http
stuff. You've probably seen a lot of commits and such related to it. :-)
Good news:
ALL of the CXF system tests now pass using it instead of the URLConnection
based transport. I'm pretty excited about that as that's
On Fri, 2012-08-03 at 09:17 -0400, Daniel Kulp wrote:
> On Friday, August 03, 2012 11:29:41 AM Oleg Kalnichevski wrote:
> > > I just went through and added a little bit of error handling into it as
> > > well. Mostly around a connection refused exception and for read
> > > timeouts. For the read
On Friday, August 03, 2012 11:29:41 AM Oleg Kalnichevski wrote:
> > I just went through and added a little bit of error handling into it as
> > well. Mostly around a connection refused exception and for read
> > timeouts. For the read timeout, I DID have to add an ioct.shutdown() in
> > the Share
On Thu, 2012-08-02 at 14:58 -0400, Daniel Kulp wrote:
> On Wednesday, August 01, 2012 05:58:23 PM Oleg Kalnichevski wrote:
> > Hi Daniel
...
>
> > I also noticed that for some reason additional connections get open and
> > closed without transmitting any data, which obviously should not be
> > ha
On Wednesday, August 01, 2012 05:58:23 PM Oleg Kalnichevski wrote:
> Hi Daniel
>
> I believe I have fixed the thread synchronization issue. All tests
> repeatedly passed for me. Could you please have a look at my changes and
> confirm that everything is more or less sane and HTTP transport still
>
On Mon, 2012-07-30 at 19:47 -0400, Daniel Kulp wrote:
> On Monday, July 30, 2012 11:41:55 PM Oleg Kalnichevski wrote:
> > On Mon, 2012-07-30 at 17:06 -0400, Daniel Kulp wrote:
> > > BTW: I think the NHttpClient.java referenced from:
> > > http://hc.apache.org/httpcomponents-core-ga/examples.html
>
On Mon, 2012-07-30 at 19:47 -0400, Daniel Kulp wrote:
> On Monday, July 30, 2012 11:41:55 PM Oleg Kalnichevski wrote:
> > On Mon, 2012-07-30 at 17:06 -0400, Daniel Kulp wrote:
> > > BTW: I think the NHttpClient.java referenced from:
> > > http://hc.apache.org/httpcomponents-core-ga/examples.html
>
On Monday, July 30, 2012 11:41:55 PM Oleg Kalnichevski wrote:
> On Mon, 2012-07-30 at 17:06 -0400, Daniel Kulp wrote:
> > BTW: I think the NHttpClient.java referenced from:
> > http://hc.apache.org/httpcomponents-core-ga/examples.html
> > needs work as well. I don't think most of the parameters s
On Mon, 2012-07-30 at 17:06 -0400, Daniel Kulp wrote:
> On Monday, July 30, 2012 10:40:32 PM Oleg Kalnichevski wrote:
> > Individual ContentDecoder / ContentEncoder implementations are marked
> > with @NonThreadSafe annotation but public APIs do not make it clear
> > enough that codecs are not thre
On Monday, July 30, 2012 10:40:32 PM Oleg Kalnichevski wrote:
> Individual ContentDecoder / ContentEncoder implementations are marked
> with @NonThreadSafe annotation but public APIs do not make it clear
> enough that codecs are not thread safe. Thank you for pointing that out.
> I'll update javado
On Mon, 2012-07-30 at 10:35 -0400, Daniel Kulp wrote:
> On Sunday, July 29, 2012 12:59:15 PM Oleg Kalnichevski wrote:
> > All right. Then, with your permission, I'll try to commit some of my
> > changes. You can always revert or re-work them if anything is not to
> > your liking.
>
> Yep. That's
On Sunday, July 29, 2012 12:59:15 PM Oleg Kalnichevski wrote:
> All right. Then, with your permission, I'll try to commit some of my
> changes. You can always revert or re-work them if anything is not to
> your liking.
Yep. That's the purpose of version control. :-) Major thanks for taking
a
On Sat, 2012-07-28 at 16:47 -0400, Daniel Kulp wrote:
> On Saturday, July 28, 2012 03:14:16 PM Oleg Kalnichevski wrote:
> > > 4) Apache HTTP Components (HC)- this was the first one I tried, ran into
> > > performance issues, abandoned it to test the others, then came back to
> > > it
> > > and figu
On Saturday, July 28, 2012 03:14:16 PM Oleg Kalnichevski wrote:
> > 4) Apache HTTP Components (HC)- this was the first one I tried, ran into
> > performance issues, abandoned it to test the others, then came back to
> > it
> > and figured out the performance issue. :-) I had this "working", but
On Fri, 2012-07-27 at 15:20 -0400, Daniel Kulp wrote:
> I've committed a few experiments I've been working on to:
>
> https://svn.apache.org/repos/asf/cxf/sandbox/dkulp_async_clients
>
>
> Basically, I've been trying to find an async client that is somewhat usable
> for CXF without completely r
On Friday, July 27, 2012 03:11:18 PM Jeff Genender wrote:
> Any reason you chose not to use Mina?
Two answers:
1) I would put Mina in the category of lower level than even Netty.
Probably doable, but would require a lot of work to write all the HTTP
symantics onto it. The "asyncweb" subpro
Any reason you chose not to use Mina?
Jeff
On Jul 27, 2012, at 2:20 PM, Daniel Kulp wrote:
>
> I've committed a few experiments I've been working on to:
>
> https://svn.apache.org/repos/asf/cxf/sandbox/dkulp_async_clients
>
>
> Basically, I've been trying to find an async client that is some
I've committed a few experiments I've been working on to:
https://svn.apache.org/repos/asf/cxf/sandbox/dkulp_async_clients
Basically, I've been trying to find an async client that is somewhat usable
for CXF without completely re-writing all of CXF. Not exactly an easy
task. For "POST"s, th
40 matches
Mail list logo
