[ https://issues.jboss.org/browse/JGRP-1844?page=com.atlassian.jira.plugin.... ] Rich DiCroce edited comment on JGRP-1844 at 9/29/15 5:40 PM: ------------------------------------------------------------- I have a project with a (probably rare) use case that requires participation in multiple independent channels. Shared transport is useful for reducing resource usage in this case. Fork channels are not an acceptable substitute because each channel has different participants, and fork channels have the limitation that the fork's view is always the same as the main channel's view. So if shared transport is to be deprecated and removed, some accommodation should be made to deal with the above. Perhaps by changing fork channels such that their view is a subset of the main view. Fork allows "asymmetric" clusters where fork channels may be present on some members but not others, but that is currently not reflected in the fork's view. That means there's no way to easily determine which members are actually participating in the fork. This feels very strange to me, especially since fork channels do have their own addresses. It seems like it should be the other way around: rather than inheriting membership but not address, the fork channel should inherit address but not membership. EDIT: I was wrong about the address, that is indeed the same on both the fork and the main. I must've been looking at the wrong channels. But the point about the view still stands. was (Author: rcd): I have a project with a (probably rare) use case that requires participation in multiple independent channels. Shared transport is useful for reducing resource usage in this case. Fork channels are not an acceptable substitute because each channel has different participants, and fork channels have the limitation that the fork's view is always the same as the main channel's view. So if shared transport is to be deprecated and removed, some accommodation should be made to deal with the above. Perhaps by changing fork channels such that their view is a subset of the main view. Fork allows "asymmetric" clusters where fork channels may be present on some members but not others, but that is currently not reflected in the fork's view. That means there's no way to easily determine which members are actually participating in the fork. This feels very strange to me, especially since fork channels do have their own addresses. It seems like it should be the other way around: rather than inheriting membership but not address, the fork channel should inherit address but not membership. -- This message was sent by Atlassian JIRA (v6.4.11#64026)