| Newsgroups |
gmane.comp.java.tn5250j.general |
| Message-ID |
<[email protected]> |
Kenneth,
the switch would watch all channels for incoming or outgoing
communication. It would capture one stream of bytes and handle it. The
handling can be either processing the data itself or either dispatching
the data and continue listening. As I unserstand correctly what you have
implemented is that for each emulator session you have a thread that
listens on the sockets waiting for data to come in (this as a matter a
fact is definition of typical synchronuous IO). When data arrives parse it
and wrap the bytes in stream packet objects or commands or something. What
NIO allows you to do is have one thread listen on all sockects/channels
and get triggered when data arrives on one socket. It could then dispatch
it as it does right now and continue listening. In the meantime on another
channel data could have arrived to be dispatched etc. As mostly for all
sessions there will be one very active, this scenario would perfectly work
without much performance loss, but with much less resources.
Wim
Kenneth Pouncey <[email protected]>
Sent by: [email protected]
28/06/2005 14:27
Please respond to
[email protected]
To
[email protected]
cc
Subject
Re: [Tn5250j-general] JDK version
Wim
Thanks for the feedback.
Quoting [email protected]:
> Hello Kenneth,
>
> I remembered Patrick asking this upgrade, but not from the point of
using
> 'new' technologies like nio, I think. Rather to cleanout 1.3 specific
code
> and integrating new APIs. Probably Swing related APIs most of the times.
Ahhh. Boy misunderstood that then.
>
> As I understood NIO it mostly helps for doing async io indeed but also
> allow better scalable IO. This is however more server oriented than this
> client side project is.
Yes correct the same thing as I thought.
>So this would not directly benefit us. However a
> lot of the multithreading things that are in the code base right, would
be
> gone. You wouldn't have to start a comm-thread for every emulator but
use
> one thread on a channel as a switcher. As you mostly use one emulator
> session at the time, this wouldn't pose performance problems and do the
> same thing with less resources.
Well this is what I have been thinking about when using asynchronous but
could
not see the benefit of the single thread issue. I say this because all
the
emulator instances can interact at different times not just in one and
only one.
For instance I have a query running on one terminal and it updates the
screen
while I am on another terminal waiting for the other to finish. I can
still
work on the other terminals and the interaction is still going on in the
others.
There are also timing marks that are sent and heartbeat-keepalives that
still
have to be used between the other terminals as well.
I apoligize for my blindnes for all those out there that understand the
asynchronous better than I do but do not see how to handle this situation
in the
channel switching code. Will this work? If it will then it is an option
for me
to continue with. I would really hate to tear all of that code apart
again just
to find out it will not work. Like I said have only used the asynchronous
in a
small server part but my mind will not wrap around putting this to use on
the
client side.
Maybe I am not seeing the forest for the trees in front.
Thanks for the feedback Wim.
Regards
Kenneth
>
> HTH,
> Wim.
>
>
>
>
>
> Kenneth Pouncey <[email protected]>
> Sent by: [email protected]
> 28/06/2005 11:44
> Please respond to
> [email protected]
>
>
> To
> [email protected]
> cc
>
> Subject
> [Tn5250j-general] JDK version
>
>
>
>
>
>
>
>
> Hello all
>
> I remember a post, from Patrick I think, that was asking to move the
> emulator up
> to 1.4 and use some of the features for those greater than 1.3.
>
> I am assuming that would mean to use the NIO streams, channels and the
> such correct?
>
> If that is the case what would using the NIO help us achieve that can
not
> be
> done now? Would it be better? What would be the goal?
>
> I ask because after having used the NIO in a couple of small projects it
> really
> only helps for asynchronous correct? We really use synchronous on the
> client
> side and really do not see any speed enhancment or anything like that
when
> using
> the synchronous model.
>
> If anyone suggests the asynchronous model for doing this could they tell
> me why
> that would help. I do not see it but am open to learning the benefits
and
> the
> coding if it will help us reach a goal.
>
> Regards
>
> Kenneth
>
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> Tn5250j-general mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/tn5250j-general
>
>
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Tn5250j-general mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/tn5250j-general