Change Agent configurations via the UI

There would be a UI that you could use to change the configuration of your Agents.

Upgrading Agents via the UI

Here again, there would be a UI that would allow you to easily migrate your Agents from a prior version to a more recent one.

Add/Remove instrumentation without restarting the JVM

Right now, you can add a new or change a PBD file without restarting your JVM. But any extension that requires touching something the "ext" directory requires a restart. We would remove this limitation.

View/Control the Agent overhead on your application

You would see an estimation of the resource usage of the Agent, which would help you tune its configuration to suit your overhead requirements.

An internet repository of Agent extensions

There would be a website listing Agent extensions for custom applications/frameworks (such as Mule ESB, PeopleSoft, Amdocs, Oracle Service Bus, Struts 2, etc..) that you could download and add to your Agents.

Select amongst different "overhead/risk" profiles

When you create your first Agent configuration, you would have a choice between several options (super safe/low overhead for Production, medium instrumentation for more visibility, full instrumentation for dev/troubleshooting).

We need *your* input!

Here is a survey that will allow you to tell us which of these features are the most important for you. You have 100$ to spend, and you get to invest them into the features you really need. You can even spend money on an "other" feature and explain to us what you need.

Thx for your feedback. Just to add my thoughts on this, the Ideas on the community site are a great source of requirements, however most of the time they are quite situational and often try to address specific product pain points, which we clearly need to do as much as we can, but they rarely ask us to implement significant new functionalities, which at the end of the day will make a bigger difference for our users.

So these surveys are there to help us prioritize these “new features” that we believe to be important but that customers did not think to create ideas for.

I’ll take an example. Let’s say there’s an Idea for “ActiveMQ” support on the community. And maybe also other ideas to better support ESBS and Messaging Platforms.

What we would typically do is try to abstract these requirements into a broader set, so for example having a productized support for all JMS implementations would answer all these ideas at once. You won’t see an Idea on the community site for a “Better JMS support” on the community site, only its local customer manifestations.