r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[!REBOL3-OLD1]

Pavel
22-Dec-2009
[20403x4]
Mine last three server messages:
len: 20000 total: 4260000 of 51923978
subport read
len: 20000 total: 4280000 of 51923978
subport read
len: 20000 total: 4300000 of 51923978
And client:
send: 20000 bytes
wrote
send: 20000 bytes
wrote
** Internal error: stack overflow

** Where: either switch applier wake-up loop applier wait send-chunk 
either switch applier wake-up loop

er switch applier wake-up loop applier wait send-chunk either switch 
applier wake-up loop applier wait

ier wake-up loop applier wait send-chunk either switch applier wake-up 
loop applier wait send-chunk eit

op applier wait send-chunk either switch applier wake-up loop applier 
wait send-chunk either switch app

t send-chunk either switch applier wake-up loop applier wait send-chunk 
either...
>>
Server stops smoothly after pressetted timeout
Steeve
22-Dec-2009
[20407x2]
hum, i tried the ping-pong example  with 3clients and I don't have 
this bug, did you modified the client in some way Pavel ?
especially the send-chunk function which seems to do some recursive 
stuffs
Pavel
22-Dec-2009
[20409]
Steeve I've mentioned large file example with server/client not modified,
Henrik
22-Dec-2009
[20410]
let's be sure we're all running the same examples. The one in bug#1369 
is not the one Pavel is referring to, as far as I can tell.
Steeve
22-Dec-2009
[20411]
The thing i can say after inspecting the source, is that it's not 
adapted to have several clients.

The clients are not waiting for any response from the server after 
sending each chunk.

So that, the server could be stucked with massives waiting chunks 
in memory
Pavel
22-Dec-2009
[20412]
Steeve pls look up one page we are using single server single client 
large file example
Steeve
22-Dec-2009
[20413]
Well, my remark stay relevant.

Because  if for any reason the server is slower than the client, 
a lot of chunks can be stacked in the server's memory
Henrik
22-Dec-2009
[20414]
Pavel is referring to this example:

http://www.rebol.net/wiki/Port_Examples#Transfer_a_large_file
Steeve
22-Dec-2009
[20415]
Guys, I know that well, just read what i say
Henrik
22-Dec-2009
[20416]
it's not adapted to have several clients
 <- but why do I get problems, then?
Steeve
22-Dec-2009
[20417x5]
it's not the only one problem, all the chunks are sent in one massive 
request before the server treat them, i guess
can you just  change this function:

send-chunk: func [port file /local data] [
    append clear data read/part file 20000
    if empty? data [return false]
    print ["send:" length? data "bytes"]
    write port data
    read port
    true
]

just an idea, not tested
sorry, it's wrong, cause data is local.
I should make my tests first
Guess i'm stupid, the problem is really simple.
there is a timeout both in CLIENT and SERVER.
after 10 seconds both server and clients are stopped.
(check the wait command at the end of the scripts)
That's for Henrik's problem.
I don't have the stack overflow bug
Henrik
22-Dec-2009
[20422]
doh... it's even written in a comment. :-)
Steeve
22-Dec-2009
[20423]
:)
Henrik
22-Dec-2009
[20424x2]
I suggest that the wait is done in a different way in the example, 
otherwise the example is not very useful, I think.
removed the wait, and it transfers perfectly.
Pavel
22-Dec-2009
[20426]
Where you removed wait Henrik?
Henrik
22-Dec-2009
[20427]
oops, not the wait, just the 10 near the bottom of both scripts.
Pavel
22-Dec-2009
[20428]
Sorry to say that but still the same in my machine 4'300'000. But 
when you are happy it must not be generall bug.
Henrik
22-Dec-2009
[20429]
well, we still need to figure out what goes wrong. do you start the 
client or the server first?
Steeve
22-Dec-2009
[20430x2]
We know what's going wrong.

The write function (in the send-chunk function) triger a WROTE action 
immediatly without returning in the waiting process before.
To me it's a system bug, probably linked with the OS used (XP).
check the version of R3 u use too
Henrik
22-Dec-2009
[20432]
A96
Steeve
22-Dec-2009
[20433x2]
not you, Pavel
Pavel use XP, i guess only XP has this bug
Henrik
22-Dec-2009
[20435x2]
I guess my version would be important too, if I don't experience 
the bug :-)
and I use XP as well and I don't have the bug.
Steeve
22-Dec-2009
[20437x3]
you got VISTA, me too, and we don't have this bug
Oh ! really ?
strange
Henrik
22-Dec-2009
[20440]
yes... :-)
Steeve
22-Dec-2009
[20441x3]
so we have to check the version Pavel uses at least
Pavel, there is ablsolutly nothing else in the scripts you use than 
the code we are testing, right ?
i have to go, i pass...
Pavel
22-Dec-2009
[20444]
Henrik, I started server first, originally I've set the wait to 60 
in server to be able to start client without hassle. Only what I've 
changed else in server was make-dir to not to create temp directory 
each time the server is started. But give me some time to try it 
in other machine.
Pekr
22-Dec-2009
[20445]
Carl's Twitter message: "And yes, we will open the R3 Host Kit to 
all developers before the end of Dec. We did it this way to avoid 
a possible flood of dev feedback."
Pavel
22-Dec-2009
[20446]
Henrik 1399 tested on different machine without problem (infinite 
wait) 200MB transfered, definitely the problem is in my machine. 
Apology for hoax.
Henrik
22-Dec-2009
[20447]
Pavel, it's still a bug. It should work on your machine.
Pavel
22-Dec-2009
[20448]
FYI when ran on Win2008 server only first lookup, read, write, happened 
but not repeating cycle sending data.
Henrik
22-Dec-2009
[20449]
does R3 Chat work on win2008 server?
Robert
24-Dec-2009
[20450x2]
Trying to understand how the Port model works WRT sequences of calls, 
events etc.
For this I try to create a sequence diagram. You can take a look 
at:


http://www.websequencediagrams.com/?lz=U2NyaXB0LT4AAgY6IE1ha2UgUE9SVAoAChBTZXQgQVdBS0UgRnVuY3Rpb24AGglQb3J0OiBPUEVOClBvcnQtPkFjdG9yAAsHAAcFLT5UQ1BfRGV2aWNlOiBMT09LVVAKbm90ZSByaWdodCBvZiAAFQxPcHRpb25hbCBjYWxsIGlmIGhvc3RuYW1lIGdpdmVuCgBDCi0-QXdhawA8GAAVB0NhbiBkbyBJUCBmaWx0ZXJpbmcgZXRjLgoANwUAgQ4OUmV0dXJucyBUUlVFAFoOAIFOBj8_AFQQAIFmBjJuZCB0aW1lAIICBQCBMwUAgWYUAIIfBQCBKxNDT05ORUNUCg&s=napkin

This is a very cool
Pekr
24-Dec-2009
[20452]
Nice ...