feasability of a jboss/jopr solution

[scphantm]

im planning out a pretty complicated system. the end result that i need to have is a central management server behind a firewall. then im going to have several hundred workstations across the country that each will be running jboss. those workstations will all be behind firewalls. they will be able to communicate to the server thru their firewalls, but the server will not have access to them directly. the firewalls that the customers have will block it. so the client will have to do a pooling system, where it connects to the server, uploads the metrics data, check for updates, download those updates and update itself.

will jopr do this or do i need to write one?

thanks

[mazz]

You want uni-directional flow of data between agent->server. We've talked for a long time about wanting to support your exact use-case.

Jopr does not have this capability (yet).

If you are interested and willing to do some work (which you'd have to do anyway, plus more, if you want to write an entire central management solution yourself) we can discuss with you possible design enhancements to the core RHQ engine (Jopr's upstream project) to do what you want.

Perhaps we can give you some ideas on how to implement this in the RHQ core and you can look into implementing it and contribute it back to the community. We'd incorporate it into RHQ/Jopr at which time you'd then also pick up all the functionality that Jopr provides (without having to design and code it up yourself).

If interested, let us know. I started a new design page here:

http://support.rhq-project.org/display/RHQ/Agent-to-Server+Unidirectional+Communications

[scphantm]

i would be interested in working on this. i need it and have to do it anyways so what the hell. i just found out that jopr exists today. where do i find some info on how its built, how it works, protocols, etc so i can get started learning the code and how it all works and how it needs to be modified.

also a direct line to the original developers would be nice, something a little faster than forums, IM would be cool.

thanks

[mazz]

where do i find some info on how its built, how it works, protocols, etc

Most of the developer resources exist on the RHQ dev wiki over at the RHQ project (Jopr's core engine is RHQ - RHQ is a separate, upstream project at http://support.rhq-project.org).

Read what the difference is between JBoss ON, Jopr and RHQ here:

http://www.redhat.com/docs/en-US/JBoss_ON/html/FAQs/chap-FAQs-Chapter.html#sect-FAQs-General-What_is_the_difference_between_JON_RHQ_and_jopr

So, while we tend to call it Jopr and use Jopr version numbers here, most of the time, we are technically dealing with the core RHQ engine (and it is RHQ that you want to enhance). The main RHQ dev wiki page at http://support.rhq-project.org has a section titled "Getting Started" with some links you should read. These include pages on how to learn to build and run RHQ from source - the Build Notes and the Advanced Build Notes (for what you want to do - you really only need to learn how to build RHQ using these instructions - since all the work you will need to do will only touch the RHQ engine codebase):

http://support.rhq-project.org/display/RHQ/Building+RHQ
http://support.rhq-project.org/display/RHQ/Advanced+Build+Notes

Design documentation for many pieces of the core engine is found here:

http://support.rhq-project.org/display/RHQ/Design+Documentation

The main user documentation is here (it is branded JBoss ON but is applicable to Jopr and RHQ as well):

http://www.redhat.com/docs/en-US/JBoss_ON/

Here's a set of demos you can watch to come up to speed with what Jopr can do:

http://www.redhat.com/docs/en-US/JBoss_ON/html/What_is_JBoss_ON/What_is_JBoss_ON-Demos.html
https://www.jboss.org/community/wiki/Jopr22SneakPeek

Some of the developers have blogs that we publish that talk about Jopr and RHQ functionality - you may wish to read and subscribe to these:

http://www.jboss.org/feeds/view/mazz?from=0
http://www.jboss.org/feeds/view/heikowrupp?from=0
http://www.jboss.org/feeds/view/greghinkle?from=0

For the full list of blogs, see the "JBoss ON" section here:

http://www.jboss.org/feeds/

I recommend you peruse some of those blogs - they contain some articles that explain the value-add that Jopr provides.

BTW: the Jopr project page ( http://www.jboss.org/jopr ) has some links such as the Jopr and RHQ JIRAs and the Jopr SVN.

also a direct line to the original developers would be nice, something a little faster than forums, IM would be cool.

We are always on IRC at #jopr (on freenode). Any questions can be asked there, there is usually somebody around 24x7. Many of us are on Eastern US time, but we have some folks over in Europe. And many times we are on there outside of normal business hours (as evidence by me answering you here at 11:00pm on a Saturday :)

Also, the developer mailing list would be more appropriate than this forum (this forum we are talking on now is the user forum, for user questions). The dev mailing list is [e-mail] (to subscribe, see https://lists.jboss.org/mailman/listinfo/jopr-dev). If no one is around in #jopr or you need to blast a question to the entire dev community, email questions there.

[pilhuhn]

I think there are two issues to look at for this:

* have everything that the server wants to send to the agent (which is not a reply to an agent request) queue in the server. When an agent request comes in, piggy-back the queued items on the reply of the agents request.

* Make sure to disable any server-side timeouts for those queued items so that it does not matter when they are actually sent to the agent and executed.

[scphantm]

yea, these sound like two of dozens of issues i suppose. the biggest one is i have to see if the rhq system has a server with some kind of xml-rpc or soap interface as i don't want to be building a whole new protocol. but im still in the process of getting the code and reading the docs so im still not sure exactly how much trouble im in yet.

[mazz]

We don't have a public remote API yet (looking at Web Services possibly - we've started and stopped that effort a few times now - haven't got it just right yet).

But you won't have to do this - you'll want to piggyback on the comm layer that we have already. We won't want two different protocols flowing between agent-server... we'll want to see if we can have the same remoting between agent and server, just have some kind of "uni-directional" mode that when enabled tells the server and agent that it is communicating differently.

yes, this will not be trivial :)

[scphantm]

if it was easy you probably would have done it by now. it looks like the rhq piece of it anyways is pretty mature.

one quick question on compiling. ive never used maven before (ant guy here) but it gets to a point and gives me a heap dump cuz it used up its memory. how do i get maven to use more than 60 megs?

[pilhuhn]

Set the MAVEN_OPTS:
snert: hrupp$ echo $MAVEN_OPTS
-Xmx640m

[mazz]

Yup - known issue - need to give maven alot of mem.

This is documented on the Building RHQ page (one of the links I posted on my earlier post).

http://support.rhq-project.org/display/RHQ/Building+RHQ

See the Install Maven section:

http://support.rhq-project.org/display/RHQ/Building+RHQ#BuildingRHQ-InstallMaven

specifically point #3:

Set the following environment variables in your .profile (UNIX) or System environment (Windows):

* M2_HOME=Maven2_install_dir
* MAVEN_OPTS=-Xms128M -Xmx768M -XX:PermSize=128M -XX:MaxPermSize=256M
* PATH=$M2_HOME/bin:existing_PATH

Note the MAVEN_OPTS env var you have to set with the appropriate memory settings for the maven VM.

BTW: I was once an Ant guy too :) Maven is very nice though and you don't lose the ability to use Ant - we use Ant tasks all throughout our maven module pom.xml files. Ant is used alot within Maven.

[ghinkle]

Two comments on this topic.

First the JBoss Remoting technology that we've built our agent-server communications on supports bi-directional messages over unidirectional connections via polling. I don't believe we've yet experimented with it and I'm sure its not nearly as simple as switching it on, but it'd be a place to start.


The second thing is that the remote API is planned to be finished in a release this summer. So making progress there.


-Greg

[scphantm]

i havn't forgotten this. my boss just made the application itself that we are developing a priority. it seems this remote api will be a good place to start. im going to start slowly doing my homework on this so when my boss is ready i can get started on it.

[scphantm]

what dev branch is the new remoting system in? i would like to take a close look at it.

[joe.marques]

The remote API is being developed in trunk.