[jboss-jira] [JBoss JIRA] (JGRP-653) Streaming API for large messages

[Bela Ban (JIRA)]

    [ https://issues.jboss.org/browse/JGRP-653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12743340#comment-12743340 ] 

Bela Ban commented on JGRP-653:
-------------------------------

I guess we could revisit this when we've changed to NIO2 in the transport. A new StreamableJChannel would be a selector with 1 SelectableChannel for all multicasts and 1 SelectableChannels per unicast sender. The NIO channels would be registered with the selector automatically and de-registered, e.g. when a member leaves.
SelectionKey.attachment() would contain information about the source, e.g. whether it is a multicast or unicast channel, the sender's address etc.
Header information would have to be embedded into the stream itself by the application.
Message flags are more tricky, perhaps a seperate OOB SelectableChannel per member would be needed ? Or a flag would have to be embedded into the stream as well...
                
> Streaming API for large messages
> --------------------------------
>
>                 Key: JGRP-653
>                 URL: https://issues.jboss.org/browse/JGRP-653
>             Project: JGroups
>          Issue Type: Feature Request
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.x
>
>         Attachments: JGroupsInputStream.java, JGroupsOutputStream.java, StreamTest.java
>
>
> For large messages, to load the entire payload into memory might be bad because the payload might be bigger than the max memory available. It would be useful to have an API which allows for use of input and output streams, so that large payloads can be read iteratively by a user and streamed out to the cluster via the underlying channel breaking the data in the input stream into chunks, which are fed into the input stream on the receivers side.
> Issues: we have to have 1 input stream per sender on the receiver side, because a stream is always defined between 2 parties (sender, receiver). Maybe something like NIO, where we register interest in a stream, are notified of new streams ('accept()') and get notified when data on any of the stream is available, would be beneficial.
> Demo is attached

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira