On 03/13/2013 10:40 PM, Mark Thomas wrote:
On 13/03/2013 21:20, Remy Maucherat wrote:
On Wed, 2013-03-13 at 20:52 +, Mark Thomas wrote:
I mean check for Socket.setsbb somewhere after the socket is
returned from poller. Either the new buffer has been set or
the buffer address is different be
On 13/03/2013 21:20, Remy Maucherat wrote:
> On Wed, 2013-03-13 at 20:52 +, Mark Thomas wrote:
>>> I mean check for Socket.setsbb somewhere after the socket is
>>> returned from poller. Either the new buffer has been set or
>>> the buffer address is different because of Socket.sendbb's offset p
On Wed, 2013-03-13 at 20:52 +, Mark Thomas wrote:
> > I mean check for Socket.setsbb somewhere after the socket is
> > returned from poller. Either the new buffer has been set or
> > the buffer address is different because of Socket.sendbb's offset param
> > (in this case it would be -11530560
On 13/03/2013 20:43, Mladen Turk wrote:
> On 03/13/2013 09:29 PM, Mladen Turk wrote:
>> On 03/13/2013 07:07 PM, Mark Thomas wrote:
>>> DEbug logs from v4 of your debug dll
>>>
>>>
>>> [3296] ssl_socket_send 4 bytes from 1772C0F0 with timeout -1
>>> [3296] SSL_write returned -1, apr_get_neto
On 03/13/2013 09:29 PM, Mladen Turk wrote:
On 03/13/2013 07:07 PM, Mark Thomas wrote:
DEbug logs from v4 of your debug dll
[3296] ssl_socket_send 4 bytes from 1772C0F0 with timeout -1
[3296] SSL_write returned -1, apr_get_netos_error=730035 SSL_get_error=3
[3296] ssl_socket_send 4 byte
On 03/13/2013 07:07 PM, Mark Thomas wrote:
DEbug logs from v4 of your debug dll
[3296] ssl_socket_send 4 bytes from 1772C0F0 with timeout -1
[3296] SSL_write returned -1, apr_get_netos_error=730035 SSL_get_error=3
[3296] ssl_socket_send 4 bytes from 16C2CFB0 with timeout -1
[329
On 13/03/2013 18:11, Mark Thomas wrote:
> On 13/03/2013 14:46, Mladen Turk wrote:
>
>> SSL_write is weird. Docs says that if the return value is EAGAIN the
>> next SSL_write *must* be called with the same params. I presume it
>> internally
>> maintains a state logic or something.
>
> Ah. I might
On 13/03/2013 14:46, Mladen Turk wrote:
> SSL_write is weird. Docs says that if the return value is EAGAIN the
> next SSL_write *must* be called with the same params. I presume it
> internally
> maintains a state logic or something.
Ah. I might not be doing this. Let me take a look...
Mark
---
DEbug logs from v4 of your debug dll
[3296] ssl_socket_send 193 bytes from 13615030 with timeout 6000
[3296] SSL_write wrote 193 bytes
[3296] ssl_socket_send 4 bytes from 1772C0F0 with timeout -1
[3296] SSL_write wrote 4 bytes
[3296] ssl_socket_send 8192 bytes from 177
On 13/03/2013 14:55, Mladen Turk wrote:
> On 03/13/2013 03:25 PM, Mark Thomas wrote:
>> On 13/03/2013 14:07, Mladen Turk wrote:
>>>
>>> Sending you a version that returns APR_EGENERAL on SLL_ERROR_SSL ...
>>
>> Thanks. That fails fast which is good but still fails. Fundamentally we
>> need to be ab
On 03/13/2013 03:25 PM, Mark Thomas wrote:
On 13/03/2013 14:07, Mladen Turk wrote:
Sending you a version that returns APR_EGENERAL on SLL_ERROR_SSL ...
Thanks. That fails fast which is good but still fails. Fundamentally we
need to be able to handle the situation when we have some, but not
en
On 03/13/2013 03:25 PM, Mark Thomas wrote:
On 13/03/2013 14:07, Mladen Turk wrote:
00267.85627747[3976] SSL_write returned -1,
apr_get_netos_error=0 SSL_get_error=1
That's a problem
apr_get_netos_error returned zero (and thats what we return)
However SSL_get_error returned SSL_ERRO
On 13/03/2013 14:07, Mladen Turk wrote:
> On 03/13/2013 02:47 PM, Mark Thomas wrote:
>> On 13/03/2013 13:36, Mark Thomas wrote:
>>> On 13/03/2013 13:12, Mladen Turk wrote:
>>
I can create a debug version which would write couple of lines to
the dbgview.exe window (from SysInternals
h
On 03/13/2013 02:47 PM, Mark Thomas wrote:
On 13/03/2013 13:36, Mark Thomas wrote:
On 13/03/2013 13:12, Mladen Turk wrote:
I can create a debug version which would write couple of lines to
the dbgview.exe window (from SysInternals
http://technet.microsoft.com/en-us/sysinternals/bb896647)
Fan
On 13/03/2013 13:36, Mark Thomas wrote:
> On 13/03/2013 13:12, Mladen Turk wrote:
>> I can create a debug version which would write couple of lines to
>> the dbgview.exe window (from SysInternals
>> http://technet.microsoft.com/en-us/sysinternals/bb896647)
>>
>> Fancy to give it a shot.
>> It woul
On 13/03/2013 13:12, Mladen Turk wrote:
> On 03/13/2013 01:29 PM, Mark Thomas wrote:
>> Henri Gomez wrote:
>>
>>> What's your test platform (or tests platforms) ?
>>>
>>> Differents OS, kernel configuration, OpenSSL / APR could bring various
>>> results
>>
>> I've seen the same behaviour (either w
On 03/13/2013 01:29 PM, Mark Thomas wrote:
Henri Gomez wrote:
What's your test platform (or tests platforms) ?
Differents OS, kernel configuration, OpenSSL / APR could bring various
results
I've seen the same behaviour (either with the test case or with the
Autobahn test suite) on the follo
Henri Gomez wrote:
>What's your test platform (or tests platforms) ?
>
>Differents OS, kernel configuration, OpenSSL / APR could bring various
>results
I've seen the same behaviour (either with the test case or with the
Autobahn test suite) on the following platforms:
Windows Server 2008 R2 wit
What's your test platform (or tests platforms) ?
Differents OS, kernel configuration, OpenSSL / APR could bring various
results
2013/3/13 Mladen Turk
> On 03/13/2013 01:20 AM, Mark Thomas wrote:
>
>>
>> And an infinite loop is entered.
>>
>> I believe I can fix this by changing how I do the bu
On 03/13/2013 01:20 AM, Mark Thomas wrote:
And an infinite loop is entered.
I believe I can fix this by changing how I do the buffering in WebSocket
so I don't end up having to write short 4 byte chunks. I have been
meaning to do this for a while anyway.
That said, this does look like an issue
On 12/03/2013 18:25, Remy Maucherat wrote:
> On Tue, 2013-03-12 at 13:25 +, Mark Thomas wrote:
>> Thanks for the pointers. I tried a few of them (the less invasive ones)
>> with no luck. I'm putting together a test case that demonstrates the
>> problem. That should make it very simple to determ
On Tue, 2013-03-12 at 13:25 +, Mark Thomas wrote:
> Thanks for the pointers. I tried a few of them (the less invasive ones)
> with no luck. I'm putting together a test case that demonstrates the
> problem. That should make it very simple to determine if the root cause
> lies in APR or my code.
On 12/03/2013 09:47, Remy Maucherat wrote:
> On Tue, 2013-03-12 at 00:25 +, Mark Thomas wrote:
>> I assume I am doing something wrong. Pointers appreciated.
>
> So I don't know precisely, but for non blocking, you're not doing the
> same thing I'm doing (which went through stress tests succ
On Tue, 2013-03-12 at 00:25 +, Mark Thomas wrote:
> I have been tracking down a problem with the Autobahn test suite and
> APR/native connector when using SSL (all is fine with non-SSL).
>
> In the test Autobahn sends a 16MB frame to the server which the server
> echos back to the client.
>
>
"Caldarale, Charles R" wrote:
>> From: Mark Thomas [mailto:ma...@apache.org]
>> Subject: Strange APR/native behaviour
>
>> The problem I am seeing is with a non-blocking write in the
>> AprServletOutputStream [1].
>
>> If a write returns EAGAIN (line 97) the socket is added to the poller
>> for
> From: Mark Thomas [mailto:ma...@apache.org]
> Subject: Strange APR/native behaviour
> The problem I am seeing is with a non-blocking write in the
> AprServletOutputStream [1].
> If a write returns EAGAIN (line 97) the socket is added to the poller
> for write notifications. The poller immediat
26 matches
Mail list logo
