Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 13 Next »

Warning

This is a Draft

Background Information

Let me start out by saying this proposal doesn't propose that support be dropped for IMultithreaded interfaces. This proposal does propose that they should be marked as deprecated and over time channels should be rewritten to use IChannel instead. Also, we need to make it clear that IMultithreaded* channels shouldn't be perceived as a better, faster more optimized way of developing a channel.

Drawbacks of Implementing the IMultithreaded* Interfaces

Complexity

Channels implemented as IMultithreaded* are much more complex than normal IChannels with the same features. This is a serious problem in an open source project. It is a serious barrier to collaboration, and this reason alone is enough to warrant deprecation.

No Session Replication

The static scoped state map won't be serialized and replicated so the channel will reset or display with an error once serialized and reloaded.

Potential Memory Leaks

They require the channel programmer to code the channel to remove objects from the state map when a user's session is removed. This easily results in a channel that leaks memory if implemented incorrectly.

Less Diagnostic Information

IMultithreaded* channel's also can't print out much useful information in their toString() methods to let us know what is going on when a
channel fails to render. IChannels can provide all the relevant information needed to diagnose a rendering failure including which user
the problem occurred with and what the publish/subscribe id of the channel is. The IMultithreaded* interfaces would need to be modified to have a method
toString(uid) that would take the user's session/uid as a parameter in order to print out the same useful information.

Summary

What makes this even more clear-cut for me is that we haven't written a single channel that benefits from being implemented as IMultithreaded*. It is clear that we should discourage implementation of channels as IMultithreaded*, and I think deprecating the interfaces is the clearest way to communicate this without ambiguity.

Proposal Implementation

  • Mark all IMultithreaded* interfaces in uPortal 2.5-patches and 2.6 as deprecated.
    • IMultithreadedCacheable
    • IMultithreadedChannel
    • IMultithreadedCharacterChannel
    • IMultithreadedDirectResponse
    • IMultithreadedMimeResponse
    • IMultithreadedPrivileged
  • Discourage use of these deprecated APIs and refactor the core channels to implement IChannel* .
  • These framework channels implement one of the IMultithreaded* interfaces:
  • CGroupsManager
  • CPortletAdapter
  • CWebProxy
  • CApplet
  • CGenericXSLT
  • CImage
  • CInlineFrame
  • CPersonAttributes
  • No labels