I am trying to compile Webhuddle from CVS and see that java/com/sts/webmeet/server/ejb/UploadManagerSessionBean.java v 1.18 just is not compilable because of multiple errors related to fresh PDF processing code. Some of the errors are trivial like missing iFileSize parameter in handlePdf() invocation, some aren't.
Downgrading this file to 1.17 helps. At least, it can be compiled.
Can anyone fix this major bug?
Does fixed one (1.19) work?
PS. Alexey, does WebHuddle work with cyrillics - то есть, по-русски?
At least, the new code had been compiled without errors. Unfortunately, I am not able to test it's functionality right now. Thank you!
As to Russian and Cyrillics: I did not check it too at this stage of deployment.
And the current state is bad enough: when I create new meeting, sometimes I enter it properly as the moderator, and sometimes everything dies with "client not found" log record at the server side and inactive Webhuddle panel at the client side. A classic non-deterministic behavior.
2008-06-16 17:35:29,685 DEBUG [com.sts.webmeet.server.LiveConference] renaming client: 919614930a000003005f8245c85b8f6a 9196096c0a00000300a53948d8ed9332
2008-06-16 17:35:29,686 ERROR [com.sts.webmeet.server.ThreadedOutboundConnectionServer] renameClient: client 9196096c0a00000300a53948d8ed9332 not found
2008-06-16 17:36:11,727 INFO [com.sts.webmeet.server.ThreadedOutboundConnectionServer] error in broadcastObject: client 9196096c0a00000300a53948d8ed9332 not found
As far as I understand, this error is very far from UploadManagerSession.
The server environment is Debian Linux with Sun Java SDK 1.5.0_14-b03.
Thanks for the post. Do you get the same problem when using webhuddle.com?
Short reply: the "client not found" problem resides at my side :-)
The only reason for me to use CVS instead of 0.4.9 is "webhuddle.property.ssl.required=false" feature. I do not want to create extra ports on the gate machine, and I am trying to forward access through Apache and ajp13, same as I do now for several other Java-based services like Dovecot and OpenXchange.
Yesterday I made the problem deterministic. "Indirect" ajp13 access works fine if I had been connected to my Webhuddle directly from same client before indirect ajp13 access. Nothing strange, taking in account that the Webhuddle internal database contains the client IP.
I'll report further details - and, I hope, solution or ideas for solution.
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.