Futurescale, Inc. PureMVC Home

The PureMVC Framework Code at the Speed of Thought


Over 10 years of community discussion and knowledge are maintained here as a read-only archive.

New discussions should be taken up in issues on the appropriate projects at https://github.com/PureMVC

Pages: 1 2 3 [4] 5
Print
Author Topic: Pipes - A PureMVC AS3 MultiCore Utility  (Read 61418 times)
dan_drg1
Newbie
*
Posts: 1


View Profile Email
« Reply #45 on: April 16, 2009, 11:40:29 »

First off, thank you Cliff for PureMVC and Pipes, I think it's fantastic.

I am doing a module based app written in AIR and Flash/AS3, using the Multicore PureMVC and Pipes. There is a shell which loads and unloads modules. Only one module is loaded at a time, designed to simulate navigating from one module to another.

My question regards the unloading of modules and memory. As I'm running the "finished" AIR app, I've got the Activity Monitor open. I load and unload modules, and watch the memory usage increase until it reaches a plateau. The more (individual) modules I load and unload, the higher the memory plateau reaches.

Each module in itself is properly cleaned up after unloading - I have tested this by repeat loading / unloading the same module, with no memory increase. What seems to happen is that each module I load is kept in memory, seemingly out of my control.

What I had wanted to do was free the memory of all but the shell & loaded module. As you can imagine, if each module has a memory overhead of 20-30MB (Activity Monitor / "Real Memory"), there only need be a few modules loaded and unloaded before the memory usage becomes an issue.

Is there a solution for this? Am I missing something?

Thank you kindly for any feedback,
Dan
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #46 on: April 16, 2009, 01:48:49 »

There is an excellent tutorial about garbage collection and pipes written by Simon Bailey. You'll find a like to it on the menu on the Pipes utility's Trac site. He has shown that it is completely possible to manage loading and unloading of modules using pipes without accumulating memory overhead. Searche these forums for pipes +GC and you'll find a recent post by me, exaustively covering this topic.

-=Cliff>   
Logged
fmjrey
Newbie
*
Posts: 7


View Profile Email
« Reply #47 on: April 27, 2010, 12:42:58 »

Any reason why we don't have such methods on IPipeAware?

:
function disconnectInputPipe(name:String):Void;
function disconnectOutputPipe(name:String):Void;

These would be useful when a module needs to be disconnected but still kept on the side for later reuse.
For example, one application could have a 3D rendering module and a 2D rendering module. Only one of them would need to be active, but because the user can switch between 2D and 3D at any time, it's best to keep each version of the module at hand.
Unless someone can suggest me a better approach than the above 2 methods...
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #48 on: April 27, 2010, 02:11:28 »

IPipeAware defines the minimum necessary methods to get a module plumbed. Once the pipes are connected, you can send a message directly to the JunctionMediator in the core to tell it to disconnect a given pipe.

-=Cliff>
Logged
tinwatchman
Jr. Member
**
Posts: 10


View Profile Email
« Reply #49 on: March 27, 2012, 07:25:06 »

Hello -

Currently trying to figure out Pipes. Had one or two questions, if anyone has a moment:

1) While I think I understand the basic way the Multicore and Pipes system works, what I don't quite understand is how the Pipes objects are supposed to find each other without using the facade. (Since the facade/core system for each module exists separately from one another, correct? Without realizing that they each exist?) Could anyone explain to me how that particular part of the system works?

2) Another thing I found puzzling were the Message objects. Why are those necessary? I understand that we're adding the priority and queue system, but why not just extend the core Notification object class?

Thank you very much for your time.
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #50 on: March 27, 2012, 08:33:29 »

what I don't quite understand is how the Pipes objects are supposed to find each other without using the facade

A core (expressed as an Application or Module in Flex) is connected to another core by Pipes.

As with actual real-world plumbing, Pipes meet at Junctions. Inside each core is a JunctionMediator that holds the Junction for the core. All the input and output Pipes for the core meet at this Junction.

The core itself should implement an interface called IPipeAware. That interface requires two methods called acceptInputPipe() and acceptOutputPipe().

The 'shell' core (the application) is typically responsible for the plumbing. That doesn't always have to be the case, it is the most logical place, since at least the first other core will have to be instantiated within the Shell's code.

With one or more IPipeAware Modules in hand, a piece of code may create Pipes and plumb the cores  easily by invoking those two interface methods. Those methods send off a notification heard by the core's JunctionMediator which takes care of attaching the Pipe to the local Junction.

Of course you can check out the PipeWorks demo which plumbs a bunch of RSS reader modules and also implements a plumbed logger:
http://trac.puremvc.org/Demo_AS3_MultiCore_Flex_PipeWorks

And for a real world example, check out the source of the Sea of Arrows custom music player app:
http://seaofarrows.com/srcview/

In the latter, start your investigation with a look at some key classes:
com.seaofarrows.musicplayer.common.view.components.PipeAwareModule
com.seaofarrows.musicplayer.modules.playlist.PlaylistModule
com.seaofarrows.musicplayer.modules.playlist.view.PlaylistJunctionMediator
com.seaofarrows.musicplayer.shell.controller.PlumbCommand

Another thing I found puzzling were the Message objects. Why are those necessary? I understand that we're adding the priority and queue system, but why not just extend the core Notification object class?
Messages and Notifications are not used in the same manner, so there really was no value in extending Notification.

Messages don't have a name property because they will always be custom classes.

You never receive a Message and then broadcast it to the rest of the core as a Notification. For the same reason we don't just retrieve a foreign Facade and send a Notification to its core, in a system using third-party Modules, you could not control the namespace of the Notification. A third-party could end up sending a Notification of the same name as something you're using in your core, and foul things up.

So it was a very explicit decision to keep Messages and Notifications separate to make their usage clear: Messages for inter-core communications, Notifications for intra-core communications.

-=Cliff>
« Last Edit: March 27, 2012, 08:38:13 by puremvc » Logged
tinwatchman
Jr. Member
**
Posts: 10


View Profile Email
« Reply #51 on: March 27, 2012, 08:44:03 »

/* The 'shell' core (the application) is typically responsible for the plumbing. That doesn't always have to be the case, it is the most logical place, since at least the first other core will have to be instantiated within the Shell's code. */

Ahhh, I see. So the main Application still has some unique responsibilities, despite the interchangeability of cores. I get it now. Thank you.

/* You never receive a Message and then broadcast it to the rest of the core as a Notification. For the same reason we don't just retrieve a foreign Facade and send a Notification to its core, in a system using third-party Modules, you could not control the namespace of the Notification. A third-party could end up sending a Notification of the same name as something you're using in your core, and foul things up. */

I see. So you coded this system so that people could exchange and use each others' modules, if need be. That makes sense, then.

Again, thank you very much for your time.
Logged
tinwatchman
Jr. Member
**
Posts: 10


View Profile Email
« Reply #52 on: April 05, 2012, 10:09:19 »

Hello, again -

So I was just wondering - about the header property you have on the Message object. What were you using that for in the project you created Pipes for? Just curious.

Thanks.
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #53 on: April 05, 2012, 11:04:53 »

I'm not sure whether I was using it in the Sea of Arrows player or not.

The Message header is meant to carry any meta-data about the message for the recipient in the same way that email headers tell an email client extra stuff about the message, such as its character set, who the intended recipient is, who sent it, etc.

-=Cliff>


« Last Edit: April 05, 2012, 12:30:11 by puremvc » Logged
tinwatchman
Jr. Member
**
Posts: 10


View Profile Email
« Reply #54 on: April 05, 2012, 11:52:45 »

Gotcha. So did you have a particular role for it in mind, or was it just a "in case I need it" sort of thing?
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #55 on: April 05, 2012, 12:29:52 »

It was really modeled after an email message, the parts of which make a lot of sense to me. Headers allows us to transmit 'out-of-band' information about the message without fiddling with or understanding the body.

For instance, you might have an image processing module. You send it an image in the body, but tell the core what to do with it by passing parameters in the header like this:

:
var header:Object = { operation:'blur', type:'gaussian', xAmount:'20', yAmount:'100' };
var body:Object = BitmapData(myImage);
var message:Message = new Message( Message.NORMAL, header, body );
« Last Edit: April 05, 2012, 12:33:21 by puremvc » Logged
tinwatchman
Jr. Member
**
Posts: 10


View Profile Email
« Reply #56 on: April 05, 2012, 02:38:51 »

Makes sense. I just thought it was an interesting choice, putting it in Pipes but not in PureMVC's Notifications. I can see, though, how that extra functionality might come into play or be useful, given how relatively complex interactions between modules might be as opposed to internal communication within an app.

So I've spent the last week digging into Pipes. I like a lot of things about it, especially in the exact control it allows you over the flow of messages between modules.

While rooting through old posts here in the forum, I also came across the LICS project someone floated as an alternative a while back. To sum it up for the audience at home, the basic idea there is to use an observer-pattern Singleton (with a single point of contact through a Mediator or a Proxy) to pass messages back and forth between the Cores. While it technically breaks encapsulation between the modules, functionally, it should work. A coworker and I were talking over the pros and cons of each approach earlier today.

You obviously have put a great deal of thought into this issue over the years. So I was just hoping to ask your opinion. What would you see as the advantages or disadvantages of Pipes over a Singleton-based system like LICS?
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #57 on: April 05, 2012, 03:42:46 »

What would you see as the advantages or disadvantages of Pipes over a Singleton-based system like LICS?
LICS is a simpler solution, and one you might want to use in a small application where you will control all of the cores that are used. Its only disadvantage as far as I can tell lies with potential notification namespace collisions. From the LICS home page:

In order to avoid coupling between modules, it is essential that the inter-core notification names, and any classes used to carry information between them, are kept completely separate. They should be viewed as a system level set of classes, rather than on a module by module basis.

From a framework vendor perspective, I must consider it axiomatic that a modular application may use modules written by third-party vendors. That means that the application vendor and the module vendor may (read: should) be completely unaware of each others' notification namespace and unable to disturb a core by triggering a notification that it shouldn't.

This is why Pipes uses Messages rather than Notifications. It ensures that the inter-core messaging is decoupled from the intra-core messaging. It allows us to expose a a core's communication protocol as a set of custom message classes which can have whatever properties we want them to and to control the flow and processing of those messages based on metadata. As you pointed out, communication between cores may be more complex than the notes bouncing around inside a core.

Pipes is just one way of doing it. LICS is definitely reasonable approach as well.

-=Cliff>
« Last Edit: April 05, 2012, 03:47:23 by puremvc » Logged
tinwatchman
Jr. Member
**
Posts: 10


View Profile Email
« Reply #58 on: April 05, 2012, 04:18:05 »

LICS is a simpler solution, and one you might want to use in a small application where you will control all of the cores that are used.

Would you be at all concerned about performance issues with a Singleton-based approach? In other words, would you be worried that the Router singleton, or its equivalent, would become too massive/too cumbersome as more cores are added?

From a framework vendor perspective, I must consider it axiomatic that a modular application may use modules written by third-party vendors. That means that the application vendor and the module vendor may (read: should) be completely unaware of each others' notification namespace and unable to disturb a core by triggering a notification that it shouldn't.

This is why Pipes uses Messages rather than Notifications. It ensures that the inter-core messaging is decoupled from the intra-core messaging. It allows us to expose a a core's communication protocol as a set of custom message classes which can have whatever properties we want them to and to control the flow and processing of those messages based on metadata. As you pointed out, communication between cores may be more complex than the notes bouncing around inside a core.

I understand. Pipes has a number of features with regards to its messaging system that I could see being very useful. The ability to queue messages, for instance, since we don't know if and when a module is going to be available.

Thank you very much. I appreciate you taking the time to share your thoughts with me.
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #59 on: April 05, 2012, 05:40:48 »

Would you be at all concerned about performance issues with a Singleton-based approach? In other words, would you be worried that the Router singleton, or its equivalent, would become too massive/too cumbersome as more cores are added?
Not unless you subclass it and add tons of functionality to it. If its responsibility is just keeping track of cores and routing messages between them, then no, I wouldn't be worried about its Singleton nature.

If you decide to play around with both Pipes and LICS, I'd be glad to hear about your experiences and impressions.

Cheers,
-=Cliff>
Logged
Pages: 1 2 3 [4] 5
Print