-
1. Re: feasability of a jboss/jopr solution
mazz Apr 4, 2009 5:41 PM (in response to scphantm)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 -
2. Re: feasability of a jboss/jopr solution
scphantm Apr 4, 2009 6:21 PM (in response to 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 -
3. Re: feasability of a jboss/jopr solution
mazz Apr 4, 2009 11:09 PM (in response to scphantm)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 jopr-dev@lists.jboss.org (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. -
4. Re: feasability of a jboss/jopr solution
pilhuhn Apr 5, 2009 5:14 AM (in response to scphantm)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. -
5. Re: feasability of a jboss/jopr solution
scphantm Apr 6, 2009 8:46 AM (in response to 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.
-
6. Re: feasability of a jboss/jopr solution
mazz Apr 6, 2009 9:06 AM (in response to scphantm)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 :) -
7. Re: feasability of a jboss/jopr solution
scphantm Apr 6, 2009 9:18 AM (in response to 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? -
8. Re: feasability of a jboss/jopr solution
pilhuhn Apr 6, 2009 9:24 AM (in response to scphantm)Set the MAVEN_OPTS:
snert: hrupp$ echo $MAVEN_OPTS
-Xmx640m -
9. Re: feasability of a jboss/jopr solution
mazz Apr 6, 2009 9:25 AM (in response to scphantm)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. -
10. Re: feasability of a jboss/jopr solution
ghinkle Apr 17, 2009 6:06 PM (in response to scphantm)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 -
11. Re: feasability of a jboss/jopr solution
scphantm May 29, 2009 9:32 PM (in response to 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.
-
12. Re: feasability of a jboss/jopr solution
scphantm May 29, 2009 9:35 PM (in response to scphantm)what dev branch is the new remoting system in? i would like to take a close look at it.
-
13. Re: feasability of a jboss/jopr solution
joe.marques May 30, 2009 12:39 AM (in response to scphantm)The remote API is being developed in trunk.