On Sat, Mar 01, 2003 at 01:57:45AM +0100, Frank v Waveren wrote: > Perhaps an extra clue: A concurrent fproxy FEC insert and fproxy FEC > download doesn't work either. However, killing the http connection for > the upload does allow the download to continue again, so I suspect the > download in the previous test just wasn't getting killed properly even > when all connections where closed. I suppose this is probably some > sort of lock contention issue.. I don't suppose there's a way of > convincing java to spit out all currently held locks? (preferrably in > a signal handler, but I don't know if java does those either :-) )
No way, it works here, and we wouldn't hold a lock over the ENTIRE request. There might well be a lock waiting for the actual FEC encoding/decoding though. Get a thread dump. > > -- > Frank v Waveren Fingerprint: 21A7 C7F3 > fvw@[var.cx|stack.nl|chello.nl] ICQ#10074100 1FF3 47FF 545C CB53 > Public key: hkp://wwwkeys.pgp.net/fvw at var.cx 7BD9 09C0 3AC1 6DF2 -- Matthew Toseland toad at amphibian.dyndns.org/amphibian at users.sourceforge.net Full time freenet hacker. http://freenetproject.org/ Freenet Distribution Node (temporary) at http://80-192-4-23.cable.ubr09.na.blueyonder.co.uk:8889/BeUkueBQ8L0/ ICTHUS. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20030301/df5e6c05/attachment.pgp>
