+1 from me.
The latest trunk works well with Centos 5.6 (64 bit) .
On Wed, Aug 24, 2011 at 8:52 AM, Leif Hedstrom wrote:
> On 08/22/2011 09:15 AM, Leif Hedstrom wrote:
>
>> Hi all,
>>
>> I've prepared a package for a v3.1.0 release. Please take a look at the
>> artifacts, check the STATUS/READM
On 08/22/2011 09:15 AM, Leif Hedstrom wrote:
Hi all,
I've prepared a package for a v3.1.0 release. Please take a look at
the artifacts, check the STATUS/README/CHANGES files, and do builds
and tests. After finishing your examination of the release candidate,
please cast your ±/0 votes, I will
I think it should be OK. It uses ink_inet_port_cast which extracts the port
without changing byte order. TSNetConnect used ink_inet_get_port which flips
the byte order. I think I will add it to the patch to not bother to extract the
address and port (that was needed before the changes in 3.1.0).
After looking at 3.1.0, is it possible that TSFetchUrl might also have
the same problem?
On Tue, Aug 23, 2011 at 9:48 AM, Alan M. Carroll
wrote:
> Because of the change over to IPv6 in the internals, ports are stored
> differently. Let me take a look ...
>
> Yeah, that's a bug introduced by the
Because of the change over to IPv6 in the internals, ports are stored
differently. Let me take a look ...
Yeah, that's a bug introduced by the change. A quick fix is to change
InkAPI.cc:6196 from
return (TSAction)netProcessor.connect_re(i, ip, port);
to
return (TSAction)netProcessor.connect_r
Hi,
The trunk code version of TSNetConnect now seems to take a host byte ordered
port number. Previously (i.e. 3.0.0) took the network byte order. I.e. I now
have to use the ntohs function on the port number.
Is this by design?
Thank-you,
Chris Reynolds.
On 08/23/2011 09:01 AM, Chris Reynolds wrote:
Thank-you. The trunk build does seem to have fixed the problem.
Great! If you wouldn't mind, take the 3.1.0-unstable release candidate
out for a spin, and post your vote on it here.
http://people.apache.org/~zwoop/rel-candidates/
This versi
Thank-you. The trunk build does seem to have fixed the problem.
On 22 August 2011 10:45, ming@gmail.com wrote:
> we have fixed the problem in trunk, please test with latest trunk and
> report back if it is fixed in you situation.
>
> be aware, that v3.0.1 is not fixed too, you should test th
