Agent / Server Communications Options

Lukas Krejci lkrejci at redhat.com
Mon Aug 5 15:54:29 UTC 2013


Hello,

sorry for this slipping through the cracks. I think nobody had an immediate answer because this is one of the features that would be *very* nice to have yet carries along a serious risk (because it affects one of the most core parts of RHQ) and has actually not been asked for in the community (until now ;) ). We just thought it'd be great for some more restricted network topologies but because we saw no demand we basically didn't want to break what's been working for us for quite some time.

That said, if you want to start working on it, you can easily do that in your own forked repository and we will try to help you as much as we can on the "rhq" IRC channel on freenode and/or on this list. Unfortunately we're not on github yet (there's a plan for it and we want to move as soon as time allows) so merging/reviewing changes will be a bit more cumbersome, but that's nothing that can't be solved (for example I could mirror our codebase in my own github account which you could fork, or we could be a bit hardcore and do code reviews through email and git-request-pull or git-format-patch ;) ). Just bear in mind that we need to be quite strict about backwards compatibility so your changes should not touch any of our public facing APIs (which really they should not, I think) for them to be accepted upstream, if you so wished. 

Also take a look at https://docs.jboss.org/author/display/RHQ/Contributions. You'd need to sign a CLA to get your changes accepted but that's nothing unusual.

As for the code you should probably start looking at - it all boils down to the fact that we have infrastructure in place that can create transparent proxies to allow calling methods on a remote object (including reading/writing streams). This facility is then used throughout the codebase to communicate between agent and server. Note though that the code assumes the communication is bidirectional so you'd have to work around that fact somehow.

The org.rhq.enterprise.communications.command.client.ClientRemotePojoFactory in the $RHQ_CHECKOUT/modules/enterprise/comm module is the thing that creates the proxies and the ClientCommandSender is the thing that then facilitates the communication itself. We also use the ClientCommandSender directly to add more fun so your best bet would be to try and keep the APIs of at least these two classes so that other code doesn't have to be drastically changed.

Note also that I am no expert in this lowest level of our codebase so the above might be completely wrong ;)

Looking forward to talking to you!

Lukas

----- Original Message ----- 

> From: "Van Dillon" <vandillon at gmail.com>
> To: rhq-devel at lists.fedorahosted.org
> Sent: Monday, August 5, 2013 2:44:19 PM
> Subject: Agent / Server Communications Options

> Hi everyone,

> At the end of last month I posted a question to this list. Perhaps the post
> was missed because I didn't receive an answer. If, on the other hand, I am
> posting to the wrong list, please accept my apologies and I will post the
> question on the rhq-users list instead.

> Here is the body of the post:

> >>
> I'm new to RHQ and am interested in using it in several different ways. Some
> of the ways I want to use it require the agent to be on platforms that do
> not have a public IP address. I read the Design Documentation wiki entries:
> "Design-Agent-to-Server Unidirectional Communications" and
> "Design-Agent-Server Communications 3", both of
> which indicate that you guys have put some serious thought into adding this
> ability to RHQ.

> Is this feature being added to the roadmap anytime soon? If not, is there a
> way to hook our own handlers into the agent and server communications
> layers?
> <<

> I'm interested in getting involved in the development of this feature if it's
> still being considered.

> Thanks,

> Van Dillon

> _______________________________________________
> rhq-devel mailing list
> rhq-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel


More information about the rhq-devel mailing list