Christian Cantrell wrote:
I'm using JSO to build a component, and I'm finding it more than a
little confusing. I've posted to the JSO list, but it's pretty
quiet, so I thought I'd try my luck here.
Using JSO, I'm able to connect to my server, listen for specific
packets, and return packets successfully. The part I don't
understand is how you continuously listen for packets. In all the
example code I've found, the authors have set up an infinite loop
inside of which they call Stream.process() to process new incoming
packets, and also keep checking a Queue for new packets to send out.
This technique works fine, but it seems odd to me, and is quite
resource intensive on my development machine. Can someone explain:
1. Why is it done this way?
2. Is there another way to do it? It seems that I should simply be
able to call a method that blocks until the packets I need come in
rather than having to process packets in a tight infinite loop.
I'm also wondering if anyone can recommend any other Java XMPP
libraries I can use to build an external XMPP component if I can't
get JSO to work like I want it to.
Thanks,
Christian
Hi Christian,
One solution for this would be to invoke stream.process() when you are
sure there is some data available.
Like , if you are using some producer-consumer model , or if you are
using java's nio package.
With the former , it becomes as simple as just triggering a
stream.process() as soon as you have produced some data.
With the latter , you will need to use async io and register your
channel with a selector for read events - which will get notified when
there is data available to be read.
With your current approach , if your underlying socket is blocking
socket , then you need to worry about cpu usage in an infinite loop - it
will block until there is data available : with caveat that you will
have one thread per component session.
If you use nio , the only advantage is that you will be able to listen
for read events from multiple streams simultaneously.
Not sure if I am answering your question properly enough ...
Regards,
Mridul
