Skip to main content

Ideas for MMC

7 replies [Last post]
ivelin
Offline
Joined: 2003-07-13
Points: 0

In the last few weeks, Bartek and I went through a good amount of pain chasing after bugs related to edge cases involving competing threads, transactions and distributed cache access. We've made a lot of progress and we learned a few lessons.

Several tools proved valuable to track the issues:

1 - ability to dump the stack trace of all threads which are involved in transactions. There is a method that does that: TransactionManagerImpl.displayOngoingSleeTransactions()

When a locking exception occurs, the information it provides along with the tx thread dump allows us to see which code sequences run into competition and eventually deadlock.

2 - ability to dump the pending events in the Event Router queue. This is useful in cases where the queue gets filled up with redundant events due to application error or some other reason.

1 and 2 would be useful features to have in the MMC.

Ivelin

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
eduardomartins
Offline
Joined: 2005-10-10
Points: 0

I'm sorry, I forgot to dump my ideas for MMC:

1) List all activities, and provide means to interact (test for idle, kill, etc).
2) List all ACI Names and Timer Tasks, and provide means to interact (remove, schedule, etc).
3) Cluster management
4) File dialogs for deployable units management (deploy, …)
5) Service update: new.install(),old.deactivate(),new.activate(),old.uninstall()

If those are not enough for now please let me know.

mranga
Offline
Joined: 2003-06-06
Points: 0

An excellent bug fix and a good idea. Locking exceptions were a true pain in the batooties.

Slee SBBs are a pain to debug and some developer friendly features may be of use:

If I were a SBB developer it might be nice to add:

1. CPU consumption metrics for different Services so that if there's a CPU hog it can be identified. For this some bytecode rewriting is necessary. Its not terribly hard to do - identify Basic blocks (blocks without branches) and put callouts to a CPU monitor at the end of each basic block. It should be possible to limit the damage caused by SBBs which get stuck in infinite loops. Jean and I worked on stuff like that years ago.

2. Memory resources. I supose one could look at VM heap size at the end of every Sbb event handler execution and see if heap is growing.

3. Is it possible to build an Sbb debugger? I dont know if its part of a Management Console project. However it may be nice to have remote debugging capability (?)

Ranga

ivelin
Offline
Joined: 2003-07-13
Points: 0

Re: Ranga's suggestions.
1&2 would be great to have. CPU&Memory consumption metrics for Services and SBBs.

#3 (remote debugging) is already possible with any sophisticated Java debugger such as the one that comes with the Eclipse IDE. Do you mean a different kind of debugging?

Ivelin

stezak
Offline
Joined: 2006-05-16
Points: 0

Very nice and interesting features, Ivelin.

I hazard a work plan for MMC developing in the next future.
I am finishing core changes for supporting resource adaptor jmx management compliant with 1.1 specifications. After this, MMC will be enriched of such capabilities. Remaining management features will next be covered: profile management, alarms and trace. Probably for alarms, and notifications in general, some ad-hoc server push mechanisms must be implemented, unfortunatly GWT (google web toolkit - the library used by MMC for user interface logic) does not yet support that.

All this should mark the end of the management features defined by jslee, and time will be good for start thinking of other (non standard) features. What Ivelin has proposed is an excellent starting point. More value could be added by deeper features such as cpu and memory usage and other statistic infos for services and sbbs for example.

For any idea or suggestion about MMC features, this is the right place, so please post.

Stefano

mranga
Offline
Joined: 2003-06-06
Points: 0

This is a very crucial usability piece for the SLEE.

I'm not implying we should copy it but Rhino from OC may be a good place to look for inspiration. You can get an evaluation copy.

mranga
Offline
Joined: 2003-06-06
Points: 0

The MMC is the "Mobicents Management Console" I assume .

Message was edited by: mranga

ivelin
Offline
Joined: 2003-07-13
Points: 0

yes. MMC = Mobicents Management Console