On Friday 07 December 2001 04:15 pm, you wrote: > > I'm using PoCoCi:UA 0.03 and I encountered a problem while using regular > > LWP::UserAgent style callbacks. From PoCoUA's POD: > > > > '""callback"" "callback" is an optional subroutine reference. If it is > > specified, the subroutine will be called as chunks of the response are > > received.' > > > > However, as far as I could tell the callback is blocking. I had actually > > tracked it down to LWP somewhere where a while() would call the callback > > with data chunks as they came in, but I can't find it now. > > I am not sure what you mean by "the callback is blocking". Like the POD > says, the callback mechanism is inherited from LWP::Parallel, so it does > not use POE events or anything else from POE. A callback is just a sub > reference that will be called every time a chunk of data is received. > You can control the maximum size of the chunk.
Well, what I meant might not be the slightest bit accurate. What I was attempting to express was that it seemed to me that when LWP saw that it was given a callback ref that it looped on a sysread() and called that callback whenever there was data, thusly not returning control until it had finished receiving the whole request. I was looking at LWP UA though, not LWP Parallel, so what I saw probaby has little to do with reality is in this situation. That's pretty common for me anyway. > > The result was my callback only received the first data chunk and then > > the rest mysteriously vanished. I would get an HTTP::Response back from > > UA indicating success, but the data was missing in action. > > Right now there seems to be a problem with the callback implementation > in LWP::Parallel. Currently the only way to make it work properly is by > returning undef from your callback. However, in that case you will get > a warning about usage of undefined value somewhere in LWP::Parallel. > But otherwise callbacks do seem to work correctly if you return undef. Well, I wasn't doing that, so perhaps that was my problem. Thanks for the reply. > One more thing is that the current LWP::Parallel (2.51) does not work > with LWP 5.60+ very well. It was not designed to support HTTP/1.1, so > that may or may not work, but I'd guess it probably won't. Also you'll > need to fix a couple of obvious compilation errors in LWP::Parallel if > you want to run it with LWP 5.60 or LWP 5.61. In fact I myself am > running LWP::Parallel 2.51 with LWP 5.61, and getting no real problems. > But if you want to be safe and don't want HTTP/1.1, then get LWP 5.53 > until Marc updates LWP::Parallel. > > Kirill
