Where would I get the IoBuffer object from? In
IoHandler.messageReceived()? In that case, wouldn't the IoBuffer only
represent one chunk of the data that is being streamed?
In my case, I want to read from the InputStream constantly. I guess
an alternative would be to implement my own ProtocolDecoder and have
it chunk things such that I could feed one chunked inputstream at a
time to the third party library, but this seems like a lot of work
given the alternative of just opening a socket and passing the
inputstream to the 3rd party library.
So, let's say I implemented a ProtocolDecoder that chunks the IoBuffer
into reasonable pieces that could be handled independently by the 3rd
party library. Why go to all of that extra effort when I can just
open a socket and pass it to the 3rd party library? What is MINA
offering me in this scenario?
Or am I missing the suggestion completely?
On Apr 3, 2008, at 9:50 AM, "이희승 (Trustin Lee)
<[EMAIL PROTECTED]> wrote:
Hi Jeremy,
Calling IoBuffer.asInputStream() or IoBuffer.asOutputStream() could
address your issue. Could you give them a try?
HTH,
Jeremy Haile wrote:
I'm using MINA as a server to process client connections. However,
my
application also needs to make a client connection to a server and
feed
the retrieved data to a 3rd party library. The client connection
will
be maintained 24 hours a day, so it is important that it can
reconnect
automatically in case of network failure.
The 3rd party library requires an InputStream to process data. I
originally attempted to use the StreamIoHandler with a
SocketConnector
but ran into problems and found archived messages recommending not to
use this handler.
Given that the 3rd party library requires an InputStream, is MINA the
appropriate choice? There is only one client connection, so non-
blocking
vs blocking I/O really isn't an issue. Should I simply use a socket?
If not, what does MINA really offer me over a plain socket
connection in
this case?
The only thing I can think of is exception handling event callbacks
which could assist with automatic reconnections. Of course, with the
socket I can just wrap my InputStream processing and catch all
IOExceptions - then attempt to reconnect after a short delay.
Any advice?
Thanks,
Jeremy Haile
--
Trustin Lee - Principal Software Engineer, JBoss, Red Hat
--
what we call human nature is actually human habit
--
http://gleamynode.net/
