powered by Jive Software

Large Messages problem

So I’'ve got this problem where a piece of software of mine that sends large Messages on a regular basis dies with a “No response from server” message when it tries to send a message again.

And after that, if I log onto the Jive Messenger page and look at the “Room Summary” section, I see that user still logged into the MUC! I then have to manually Destroy Room through the Jive web page and destroy the room before I restart the program. And sometimes the user itself stays on (I check using the Sessions page) even though I terminated the Java process which had the user. Destroying the room and closing that user’'s connection through Jive makes the webpage really slow for about a minute or two.

In more detail, I have a program that polls a webcam’‘s image every 10 seconds and posts it to a MUC as a Smack property (e.g., Packet.setProperty(), Packet.getProperty()). This allows many people to view the image from the webcam, because otherwise it just wouldn’'t be able to handle the bandwidth. The image is a 640x480 JPEG, but low quality so it ends up being about 22KB.

This is really strange, and the behavior is kinda unpredictable. Sometimes, the java process dies with an OutOfMemoryError. Sometimes, the XMPPConnection is closed:

java.net.SocketException: Software caused connection abort: socket write error

Thread (Suspended (breakpoint at line 93 in MyPeer))

MyPeer.connectionClosedOnError(Exception) line: 93

PacketReader.notifyConnectionError(Exception) line: 206

PacketWriter.writePackets() line: 224

PacketWriter.access$000(PacketWriter) line: 34

PacketWriter$1.run() line: 59

/code

I have had no other similar issues with Jive–ever. If anyone has any ideas, please reply. Thanks ahead of time.

How are you sending the message, the JPEG that is, compressing it, encoding it, or anything? Are you seeing any error in messenger? We might need to find aother solution to acomplish what you are hoping to acomplish. Is there any progress on the pub-sub for Messenger? I think that would be useful in this instance.

Alex

How are you sending the message, the JPEG that is,

compressing it, encoding it, or anything? Are you

seeing any error in messenger? We might need to find

aother solution to acomplish what you are hoping to

acomplish. Is there any progress on the pub-sub for

Messenger? I think that would be useful in this

instance.

I’‘m not compressing or encoding the JPEG or anything. I’'m just getting it via HTTP and post it. One thing I noticed though, is that StringUtils.decodeBase64 on the ImageIcon can take up to 10 seconds (at least in debug mode in Eclipse, but still this is a fast machine).

Nothing interesting in the logs, unfortunately, although I just have the default logging on. There’'s just “Logging off…” packets.

What do you mean by “pub-sub for Messenger”?

Thanks for the help! I’‘m surprised no one else has tried sending hugs packets across using Jive/Smack. I didn’'t think I had such an unconventional use for it.

I too am having difficulty with larger messages. On the other side of the coin I’'m compressing the content, using a base 64 encoding then sending images as a message extension.

The best solution I can think of currently, without having to delve to deeply into Messenger or Smack, would be to setup a seperate data stream between the server and the clients. I don’'t know how your setup currently is but in my mind the solution would be much quicker and desirable then sending the data over the XML stream. It would be possible for the server to inform clients of the ip and port to connect to forward the pictures.

Though, in noodlez case, you said you are getting the picture via http? Why don’'t you instead then just forward the hyperlink for the webcam at the beginning of the chat and have each client update every minute or so?

Alex

The best solution I can think of currently, without

having to delve to deeply into Messenger or Smack,

would be to setup a seperate data stream between the

server and the clients. I don’'t know how your setup

currently is but in my mind the solution would be

much quicker and desirable then sending the data over

the XML stream. It would be possible for the server

to inform clients of the ip and port to connect to

forward the pictures.

I see… are you thinking of something like JEP-0047: In-Band Bytestreams (IBB)? I’‘m also just curious as to why Messenger or Smack can’'t handle large packets. Perhaps this is a limitation of Java?

Though, in noodlez case, you said you are getting the

picture via http? Why don’'t you instead then just

forward the hyperlink for the webcam at the beginning

of the chat and have each client update every minute

or so?

Ah, yes. The webcam runs an internal little HTTP server, and I have thought of doing that. But then I might run into the same problem: the webcam won’‘t be able to handle the bandwidth of the five, maybe even 10 clients that are running my program. I tried before, and it’'s a cheap webcam and it just crashes. Reading from it once every second (only one HTTP connection to the webcam) and posting to a MUC would put no pressure on the webcam, and I can have a zillion clients.

Anyways, thanks for the response, AWenckus.

Actualy, I was refering to the SOCKS5 Bytestreams:

http://www.jabber.org/jeps/jep-0065.html

Alex

Actualy, I was refering to the SOCKS5 Bytestreams:

http://www.jabber.org/jeps/jep-0065.html

Ah… are there any plans to implement this? I believe it would require a SOCKS proxy, so I would be more in favor of Inband Bytestream (JEP 47), since I don’'t think it requires anything external.

A seperate proxy is not required as either of the parties in the file transfer can act as a proxy. The only problem you would possibly run into would be if either of the parties are behind a firewall or their IPs need to be NATed to reach one another. Which I guess would all depend upon your current deployment.

Alex

Does Smack have support for SOCKS5 Bytestreams? Is it in the works, maybe?

Thanks!

It is in the works.

Alex