[JBoss AS7 Development] - Hacking on AS7
by Jason Greene
Jason Greene [http://community.jboss.org/people/jason.greene%40jboss.com] modified the document:
"Hacking on AS7"
To view the document, visit: http://community.jboss.org/docs/DOC-15596
--------------------------------------------------------------
h4. 1. Create a github account
http://github.com http://github.com
h4. 2. Fork jboss-as into your account
http://github.com/jbossas/jboss-as http://github.com/jbossas/jboss-as
h4. 3. Clone your newly forked copy onto your local workspace
$ git clone git@github.com:[your user]/jboss-as.git
Initialized empty Git repository in /devel/jboss-as/.git/
remote: Counting objects: 2444, done.
remote: Compressing objects: 100% (705/705), done.
remote: Total 2444 (delta 938), reused 2444 (delta 938)
Receiving objects: 100% (2444/2444), 1.71 MiB | 205 KiB/s, done.
Resolving deltas: 100% (938/938), done.
$ cd jboss-as
h4. 4. Add a remote ref to upstream, for pulling future updates
git remote add upstream git://github.com/jbossas/jboss-as.git
h4. 5. Use maven (or build.sh) (make sure you use maven 3)
$ mvn install
.....
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO]
[INFO] JBoss Application Server: BOM ..................... SUCCESS [1.834s]
[INFO] JBoss Application Server: Parent Aggregator ....... SUCCESS [0.022s]
[INFO] JBoss Application Server: Domain Core ............. SUCCESS [3.051s]
[INFO] JBoss Application Server: Server Manager .......... SUCCESS [0.204s]
[INFO] JBoss Application Server: Server .................. SUCCESS [0.283s]
[INFO] JBoss Application Server: Domain Controller ....... SUCCESS [0.084s]
[INFO] JBoss Application Server: Process Manager ......... SUCCESS [0.314s]
[INFO] JBoss Application Server: Remoting ................ SUCCESS [0.390s]
[INFO] JBoss Application Server: Build ................... SUCCESS [5.696s]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
h4. 6. Pulling later updates from upstream
$ git pull --rebase upstream master
>From git://github.com/jbossas/jboss-as
* branch master -> FETCH_HEAD
Updating 3382570..1fa25df
Fast-forward
{parent => bom}/pom.xml | 70 ++++----------
build/pom.xml | 13 +--
domain/pom.xml | 10 ++
.../src/main/resources/examples/host-example.xml | 2 +-
.../resources/examples/jboss-domain-example.xml | 28 +++---
.../main/resources/schema/jboss-domain-common.xsd | 12 +--
.../main/resources/schema/jboss-domain-host.xsd | 2 +-
domain/src/main/resources/schema/jboss-domain.xsd | 17 ++--
pom.xml | 100 ++++++++++++++++++--
process-manager/pom.xml | 3 +-
10 files changed, 156 insertions(+), 101 deletions(-)
rename {parent => bom}/pom.xml (85%)
*(--rebase will automatically put move commits, if you have any, on top of the latest master, you can leave it off if you do not)*
h4. 7. Pushing pulled updates (or local commits if you aren't using topic branches) to your private github repo (origin)
$ git push
Counting objects: 192, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (44/44), done.
Writing objects: 100% (100/100), 10.67 KiB, done.
Total 100 (delta 47), reused 100 (delta 47)
To git@github.com:[your user]/jboss-as.git
3382570..1fa25df master -> master
*You might need to say -f to force the changes. Read the note on 12 though before you do it.*
h4. 8. Discuss your planned changes (if you want feedback)
* On the forums - http://community.jboss.org/en/jbossas/dev/jboss_as7_development http://community.jboss.org/en/jbossas/dev/jboss_as7_development
* On IRC - irc://irc.freenode.org/jboss-as7 or https://webchat.freenode.net/?channels=jboss-as7 (http://webchat.freenode.net/?channels=jboss-as7)
h4. 9. Make sure there is a JIRA somewhere for the enhancement/fix
http://jira.jboss.org http://jira.jboss.org
h4. 10. Create a simple topic branch to isolate that work (just a recommendation)
git checkout -b my_cool_feature
h6. Note: See tips section for how to use a nice git prompt for tracking what branch you are in!
h6. 11. Make the changes and commit one or more times (Don't forget to push)
git commit -m 'JBAS-XXXX Frunubucate the Fromungulator'
git commit -m 'JBAS-YYYY Tripple Performance of Fromungulation'
git push my_cool_feature
+Note that git push references the branch you are pushing and defaults to master, *not your working branch*.+
h4. 12. Rebase your branch against the latest master (applies your patches on top of master)
git fetch upstream
git rebase -i upstream/master
# if you have conflicts fix them and rerun rebase
# The -f, forces the push, alters history, see note below
git push -f my_cool_feature
The -i triggers an interactive update which also allows you to combine commits, alter commit messages etc. It's a good idea to make the commit log very nice for external consumption. Note that this alters history, which while great for making a clean patch, is unfriendly to anyone who has forked your branch. Therefore you want to make sure that you either work in a branch that you don't share, or if you do share it, tell them you are about to end the branch.
h4. 13. Get your changes merged into upstream
1. Make sure your repo is in sync with other unrelated changes in upstream before requesting your changes be merged into upstream by repeating step 12.
2. Email a pull request to mailto:jbossas-pull-requests@lists.jboss.org jbossas-pull-requests(a)lists.jboss.org (if I haven't subscribed the list, do it https://lists.jboss.org/mailman/listinfo/jbossas-pull-requests here) with a link to your repo, a description of the changes, and who reviewed (if any)
3. After review a maintainer will merge your patch, update/resolve issues by request, and reply when complete
4. Don't forget to switch back to master and pull the updates1. git checkout master
git pull upstream master
h4. Appendix A. Adding a new external dependency
1. Edit pom.xml and add a property of the form "version.groupId.artifactId" which contains the Maven version of the dependency. Add your dependency to the <dependencyManagement> section, and use the property for the version. If your new dependency has any transitive dependencies, be sure to <exclude> them (or if possible, update the project so that all its dependencies are of *provided* scope).
2. Add your dependency to any AS modules that require it, but only with group/artifact.
3. Edit build/pom.xml and add your dependency with only group/artifact.
4. Create a directory in build/src/modules corresponding to the *module's* name (which will differ from the Maven group/artifact name; look at other modules to get a feel for the naming scheme), with a version of "main", like this: "build/src/modules/org/jboss/foo/main".
5. Create a module.xml file inside the "main" directory. Use a module.xml from another similar module as a template.
6. Edit build/build.xml and add a <module-def> element. The name listed in the <module-def> element corresponds to the *module* name. The group/artifact listed in the nested maven-resource element(s) refer to the *Maven* group/artifact name.
7. *Important:* Make sure you did not introduce any transitive dependencies by using "mvn dependency:tree". If you did, be sure to add <exclusion>s for each of them to your dependency as described above.
Please be sure to preserve the alphabetical ordering of all POMs and the build.xml file.
h4. Appendix B. Adding a new AS submodule
1. Create the directory corresponding to the submodule and add it to the root pom.xml file. The convention is to leave off the "jboss-as-" portion, so "jboss-as-remoting" becomes "remoting".
2. Create a POM for your submodule (use another submodule as a template). Make sure all dependencies you specify do *not* include a version. The group ID should be "org.jboss.as", and the artifact ID should begin with "jboss-as-" and there should be a proper <name> for the new module.
3. Add the new submodule to the top section of the <dependencyManagement> of the top-level pom.xml. The version should be set to "${project.version}". This section is sorted alphabetically by artifact name so please preserve that ordering.
4. Add your submodule dependency to any AS modules that require it, but only with group/artifact.
5. Edit build/pom.xml and add the new submodule with only group/artifact.
6. Create a directory in build/src/modules corresponding to the submodule, with a version of "main", like this: "build/src/modules/org/jboss/as/new-subsystem/main".
7. Create a module.xml file inside the "main" directory. Use a module.xml from another subsystem as a template.
8. Edit build/build.xml and add a <module-def> element for the subsystem. Use the module name and Maven coordinates from steps 6 and 2 respectively. Use another submodule as a template.
Please be sure to preserve the alphabetical ordering of all POMs and the build.xml file.
h4. Tips & Tricks!
h4. Creating a Git status prompt in your terminal
This makes it easy to not forget what branch you are working in and quickly tell if you have changes. The following will adjust the PS1 on unix (or cygwin on Windows). Note that it assumes a compiled version of git, which is also the case for the OSX packages. If you are using the bundled rpm version, change the completion path to "/etc/bash.completion.d/git"
GIT_COMPLETION_PATH="/usr/local/git/contrib/completion/git-completion.bash"
if [ -f "$GIT_COMPLETION_PATH" ]; then
GIT_PS1_SHOWDIRTYSTATE=true
. "$GIT_COMPLETION_PATH"
ADD_PS1='$(__git_ps1)'
fi
if [[ ${EUID} == 0 ]] ; then
PS1="\[\033[01;31m\]\h\[\033[01;34m\] \w\[\033[33m\]$ADD_PS1\[\033[34m\] \$\[\033[00m\] "
else
PS1="\[\033[01;32m\]\u@\h\[\033[01;34m\] \w\[\033[33m\]$ADD_PS1\[\033[34m\] \$\[\033[00m\] "
fi
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-15596]
Create a new document in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
13 years, 6 months
[JBoss AS7 Development] - Hacking on AS7
by Jason Greene
Jason Greene [http://community.jboss.org/people/jason.greene%40jboss.com] modified the document:
"Hacking on AS7"
To view the document, visit: http://community.jboss.org/docs/DOC-15596
--------------------------------------------------------------
h4. 1. Create a github account
http://github.com http://github.com
h4. 2. Fork jboss-as into your account
http://github.com/jbossas/jboss-as http://github.com/jbossas/jboss-as
h4. 3. Clone your newly forked copy onto your local workspace
$ git clone git@github.com:[your user]/jboss-as.git
Initialized empty Git repository in /devel/jboss-as/.git/
remote: Counting objects: 2444, done.
remote: Compressing objects: 100% (705/705), done.
remote: Total 2444 (delta 938), reused 2444 (delta 938)
Receiving objects: 100% (2444/2444), 1.71 MiB | 205 KiB/s, done.
Resolving deltas: 100% (938/938), done.
$ cd jboss-as
h4. 4. Add a remote ref to upstream, for pulling future updates
git remote add upstream git://github.com/jbossas/jboss-as.git
h4. 5. Use maven (or build.sh) (make sure you use maven 3)
$ mvn install
.....
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO]
[INFO] JBoss Application Server: BOM ..................... SUCCESS [1.834s]
[INFO] JBoss Application Server: Parent Aggregator ....... SUCCESS [0.022s]
[INFO] JBoss Application Server: Domain Core ............. SUCCESS [3.051s]
[INFO] JBoss Application Server: Server Manager .......... SUCCESS [0.204s]
[INFO] JBoss Application Server: Server .................. SUCCESS [0.283s]
[INFO] JBoss Application Server: Domain Controller ....... SUCCESS [0.084s]
[INFO] JBoss Application Server: Process Manager ......... SUCCESS [0.314s]
[INFO] JBoss Application Server: Remoting ................ SUCCESS [0.390s]
[INFO] JBoss Application Server: Build ................... SUCCESS [5.696s]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
h4. 6. Pulling later updates from upstream
$ git pull --rebase upstream master
>From git://github.com/jbossas/jboss-as
* branch master -> FETCH_HEAD
Updating 3382570..1fa25df
Fast-forward
{parent => bom}/pom.xml | 70 ++++----------
build/pom.xml | 13 +--
domain/pom.xml | 10 ++
.../src/main/resources/examples/host-example.xml | 2 +-
.../resources/examples/jboss-domain-example.xml | 28 +++---
.../main/resources/schema/jboss-domain-common.xsd | 12 +--
.../main/resources/schema/jboss-domain-host.xsd | 2 +-
domain/src/main/resources/schema/jboss-domain.xsd | 17 ++--
pom.xml | 100 ++++++++++++++++++--
process-manager/pom.xml | 3 +-
10 files changed, 156 insertions(+), 101 deletions(-)
rename {parent => bom}/pom.xml (85%)
*(--rebase will automatically put move commits, if you have any, on top of the latest master)*
h4. 7. Pushing pulled updates (or local commits if you aren't using topic branches) to your private github repo (origin)
$ git push
Counting objects: 192, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (44/44), done.
Writing objects: 100% (100/100), 10.67 KiB, done.
Total 100 (delta 47), reused 100 (delta 47)
To git@github.com:[your user]/jboss-as.git
3382570..1fa25df master -> master
h4. 8. Discuss your planned changes (if you want feedback)
* On the forums - http://community.jboss.org/en/jbossas/dev/jboss_as7_development http://community.jboss.org/en/jbossas/dev/jboss_as7_development
* On IRC - irc://irc.freenode.org/jboss-as7 or https://webchat.freenode.net/?channels=jboss-as7 (http://webchat.freenode.net/?channels=jboss-as7)
h4. 9. Make sure there is a JIRA somewhere for the enhancement/fix
http://jira.jboss.org http://jira.jboss.org
h4. 10. Create a simple topic branch to isolate that work (just a recommendation)
git checkout -b my_cool_feature
h6. Note: See tips section for how to use a nice git prompt for tracking what branch you are in!
h6. 11. Make the changes and commit one or more times (Don't forget to push)
git commit -m 'JBAS-XXXX Frunubucate the Fromungulator'
git commit -m 'JBAS-YYYY Tripple Performance of Fromungulation'
git push my_cool_feature
+Note that git push references the branch you are pushing and defaults to master, *not your working branch*.+
h4. 12. Rebase your branch against the latest master (applies your patches on top of master)
git fetch upstream
git rebase -i upstream/master
# if you have conflicts fix them and rerun rebase
git push my_cool_feature
The -i triggers an interactive update which also allows you to combine commits, alter commit messages etc. It's a good idea to make the commit log very nice for external consumption. Note that this alters history, which while great for making a clean patch, is unfriendly to anyone who has forked your branch. Therefore you want to make sure that you either work in a branch that you don't share, or if you do share it, tell them you are about to end the branch.
h4. 13. Get your changes merged into upstream
1. Make sure your repo is in sync with other unrelated changes in upstream before requesting your changes be merged into upstream by repeating step 12.
2. Email a pull request to mailto:jbossas-pull-requests@lists.jboss.org jbossas-pull-requests(a)lists.jboss.org (if I haven't subscribed the list, do it https://lists.jboss.org/mailman/listinfo/jbossas-pull-requests here) with a link to your repo, a description of the changes, and who reviewed (if any)
3. After review a maintainer will merge your patch, update/resolve issues by request, and reply when complete
4. Don't forget to switch back to master and pull the updates1. git checkout master
git pull upstream master
h4. Appendix A. Adding a new external dependency
1. Edit pom.xml and add a property of the form "version.groupId.artifactId" which contains the Maven version of the dependency. Add your dependency to the <dependencyManagement> section, and use the property for the version. If your new dependency has any transitive dependencies, be sure to <exclude> them (or if possible, update the project so that all its dependencies are of *provided* scope).
2. Add your dependency to any AS modules that require it, but only with group/artifact.
3. Edit build/pom.xml and add your dependency with only group/artifact.
4. Create a directory in build/src/modules corresponding to the *module's* name (which will differ from the Maven group/artifact name; look at other modules to get a feel for the naming scheme), with a version of "main", like this: "build/src/modules/org/jboss/foo/main".
5. Create a module.xml file inside the "main" directory. Use a module.xml from another similar module as a template.
6. Edit build/build.xml and add a <module-def> element. The name listed in the <module-def> element corresponds to the *module* name. The group/artifact listed in the nested maven-resource element(s) refer to the *Maven* group/artifact name.
7. *Important:* Make sure you did not introduce any transitive dependencies by using "mvn dependency:tree". If you did, be sure to add <exclusion>s for each of them to your dependency as described above.
Please be sure to preserve the alphabetical ordering of all POMs and the build.xml file.
h4. Appendix B. Adding a new AS submodule
1. Create the directory corresponding to the submodule and add it to the root pom.xml file. The convention is to leave off the "jboss-as-" portion, so "jboss-as-remoting" becomes "remoting".
2. Create a POM for your submodule (use another submodule as a template). Make sure all dependencies you specify do *not* include a version. The group ID should be "org.jboss.as", and the artifact ID should begin with "jboss-as-" and there should be a proper <name> for the new module.
3. Add the new submodule to the top section of the <dependencyManagement> of the top-level pom.xml. The version should be set to "${project.version}". This section is sorted alphabetically by artifact name so please preserve that ordering.
4. Add your submodule dependency to any AS modules that require it, but only with group/artifact.
5. Edit build/pom.xml and add the new submodule with only group/artifact.
6. Create a directory in build/src/modules corresponding to the submodule, with a version of "main", like this: "build/src/modules/org/jboss/as/new-subsystem/main".
7. Create a module.xml file inside the "main" directory. Use a module.xml from another subsystem as a template.
8. Edit build/build.xml and add a <module-def> element for the subsystem. Use the module name and Maven coordinates from steps 6 and 2 respectively. Use another submodule as a template.
Please be sure to preserve the alphabetical ordering of all POMs and the build.xml file.
h4. Tips & Tricks!
h4. Creating a Git status prompt in your terminal
This makes it easy to not forget what branch you are working in and quickly tell if you have changes. The following will adjust the PS1 on unix (or cygwin on Windows). Note that it assumes a compiled version of git, which is also the case for the OSX packages. If you are using the bundled rpm version, change the completion path to "/etc/bash.completion.d/git"
GIT_COMPLETION_PATH="/usr/local/git/contrib/completion/git-completion.bash"
if [ -f "$GIT_COMPLETION_PATH" ]; then
GIT_PS1_SHOWDIRTYSTATE=true
. "$GIT_COMPLETION_PATH"
ADD_PS1='$(__git_ps1)'
fi
if [[ ${EUID} == 0 ]] ; then
PS1="\[\033[01;31m\]\h\[\033[01;34m\] \w\[\033[33m\]$ADD_PS1\[\033[34m\] \$\[\033[00m\] "
else
PS1="\[\033[01;32m\]\u@\h\[\033[01;34m\] \w\[\033[33m\]$ADD_PS1\[\033[34m\] \$\[\033[00m\] "
fi
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-15596]
Create a new document in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
13 years, 6 months
[JBoss Web Services Development] - CXF Policy Engine
by Richard Opalka
Richard Opalka [http://community.jboss.org/people/richard.opalka%40jboss.com] created the discussion
"CXF Policy Engine"
To view the discussion, visit: http://community.jboss.org/message/565071#565071
--------------------------------------------------------------
Hi Folks,
I'll be little bit verbose about the setup because I don't know how much Sergey is familiar with our test framework.
I just commited first JBWS-3134 related test case to the framework.
This test case allows U to reproduce the CXF Policy engine issue we've been discussing on IRC yesterday.
In order to reproduce the issue I suggest U to modify
framework/trunk/testsuite/test/java/org/jboss/test/ws/jaxws/jbws3134/AddrFeaturesViaAnn/JBWS3134TestCase.java
and comment out all test test methods except *testVerifyAddrHeadersExistForRequiredEchoPort()* one.
Then do mvn clean install of this modified framework to your local maven repository so it's picked up by CXF tests.
U will also need to configure JBossAS to be debuggable (just comment out one line in $JBOSS_HOME/bin/run.conf)
Here are the breakpoints U should set up in your IDE:
* org.apache.cxf.ws.policy.EffectivePolicy
- void chooseAlternative(PolicyEngineImpl engine, Assertor assertor) // [1]
* org.apache.cxf.ws.Policy.PolicyEngineImpl
- public synchronized AlternativeSelector getAlternativeSelector() // [2]
To run just this one test do:
* if executed first time
- [../cxf/trunk]>mvn -Ptestsuite,spring,hudson,jboss601 test -Dtest=**/jaxws/jbws3134/**/*TestCase
* if executed not first time (to save some time)
- [../cxf/trunk]>mvn -Ptestsuite,spring,hudson,jboss601 test -Dtest=**/jaxws/jbws3134/**/*TestCase -Dnoprepare
IDENTIFIED ISSUE
I've been debugging this issue and here are my investigation results:
If I set wsp:Optional="false" in
cxf/trunk/modules/testsuite/framework-tests/target/test-libs/jaxws-jbws3134-addrfeaturesviaann-endpoint.war!/WEB-INF/wsdl/EchoService.wsdl
before running test then there's only one policy alternative associated with EchoImpl - addressing.
If I set wsp:Optional="true" in
cxf/trunk/modules/testsuite/framework-tests/target/test-libs/jaxws-jbws3134-addrfeaturesviaann-endpoint.war!/WEB-INF/wsdl/EchoService.wsdl
then there're two policy alternatives created and associated with EchoImpl - addressing & empty one.
With PolicyEngineImpl used on endpoint side there's no policy AlternativeSelector configured so MinimalAlternativeSelector is instantiated and used (see [2] breakpoint in your IDE). This org.apache.cxf.ws.policy.selector.MinimalAlternativeSelector simply picks up empty assertion
if wsp:Optional="true" is specified in WSDL.
SUGGESTED SOLUTIONS?
This is the question I wanna discuss with U ;)
The problem that I see is PolicyAlternativeSelector is not taking incomming SOAP envelope content into account.
This said if some policy is optional, CXF should be able to somehow inspect incoming SOAP envelopes and pick up proper policy alternative for it.
I see there are three default AlternativeSelector implementations in CXF:
[/home/opalka][/home/opalka/THIRDPARTY/CXF/trunk/rt/ws/policy/src/main/java/org/apache/cxf/ws/policy/selector]>ls -al | grep java
FirstAlternativeSelector.java
MaximalAlternativeSelector.java
MinimalAlternativeSelector.java
But none of it is taking incoming SOAP envelope content into account thus sometimes picking up wrong policy alternative.
The question is what should do this SOAP envelope inspection. AlternativeSelector or PolicyEngine?
I see that org.apache.cxf.ws.policy.PolicyEngine have these methods:
* EffectivePolicy getEffectiveServerRequestPolicy(EndpointInfo ei, BindingOperationInfo boi)
* EffectivePolicy getEffectiveServerResponsePolicy(EndpointInfo ei, BindingOperationInfo boi, Destination d);
Should these methods inspect incomming SOAP envelope and filter out effective policy alternatives before passing them to AlternativeSelector?
Thanks in advance for your feedback.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/565071#565071]
Start a new discussion in JBoss Web Services Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
13 years, 6 months
[JBoss Cache Development] - Extracting jbosscache async listener stats
by Daniel Cullender
Daniel Cullender [http://community.jboss.org/people/cullendw] modified the document:
"Extracting jbosscache async listener stats"
To view the document, visit: http://community.jboss.org/docs/DOC-14766
--------------------------------------------------------------
We are currently using jbosscache core 3.2.1.GA and currently push literally millions of records into it. We have asynchronous listeners processing the data as it is put into the cache.
The problem is that the listeners cannot process the data quickly enough and this causes a backlog in the async queue size (which is set to a number in the millions). Increasing the Async pool size over 250 does not help either based on the various (but necessary) locks we have in place.
In order to successfully manage the backlog, we needed to monitor the cache's Async Listener's Queue size to see when it grows too large. Unfortunately, we could not find a way to access these type of stats from the cache, so we downloaded the source code and exposed these stats ourselves.
*Code Modifications*
1. We created a new immutable VO called org.jboss.cache.notifications.NotifierRuntime which holds the various statistics relating to the async listener queue and pool
2. In the org.jboss.cache.notifications.NotifierImpl class, keep a reference to the ThreadPoolExecutor which the BoundedExecutor assigns to the AsyncProcessor since this contains all the information you need to extract the queue size (along with other useful stats)
3. Expose a method on the org.jboss.cache.notifications.Notifier interface and the org.jboss.cache.Cache interface to expose a method which returns this immutable object (org.jboss.cache.notifications.NotifierRuntime) which is populated with delicious data (Our object contains minimal info, but could easily be extended to expose a whole lot more data).
These statistics have helped us manage the backlog and keep our application afloat.
To access these stats, all you need to do is invoke the getNotifierRuntime() on the org.jboss.cache.Cache interface.
I have attached the source code for anyone who has a similar requirement.
*Update*
I have updated the jbosscache-core source code for for 3.2.5.AG (please find the jar attached). I replicated the steps mentioned above and no additional steps were required.
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-14766]
Create a new document in JBoss Cache Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
13 years, 6 months
[JBoss Cache Development] - Extracting jbosscache async listener stats
by Daniel Cullender
Daniel Cullender [http://community.jboss.org/people/cullendw] modified the document:
"Extracting jbosscache async listener stats"
To view the document, visit: http://community.jboss.org/docs/DOC-14766
--------------------------------------------------------------
We are currently using jbosscache core 3.2.1.GA and currently push literally millions of records into it. We have asynchronous listeners processing the data as it is put into the cache.
The problem is that the listeners cannot process the data quickly enough and this causes a backlog in the async queue size (which is set to a number in the millions). Increasing the Async pool size over 250 does not help either based on the various (but necessary) locks we have in place.
In order to successfully manage the backlog, we needed to monitor the cache's Async Listener's Queue size to see when it grows too large. Unfortunately, we could not find a way to access these type of stats from the cache, so we downloaded the source code and exposed these stats ourselves.
*Code Modifications*
1. We created a new immutable VO called org.jboss.cache.notifications.NotifierRuntime which holds the various statistics relating to the async listener queue and pool
2. In the org.jboss.cache.notifications.NotifierImpl class, keep a reference to the ThreadPoolExecutor which the BoundedExecutor assigns to the AsyncProcessor since this contains all the information you need to extract the queue size (along with other useful stats)
3. Expose a method on the org.jboss.cache.notifications.Notifier interface and the org.jboss.cache.Cache interface to expose a method which returns this immutable object (org.jboss.cache.notifications.NotifierRuntime) which is populated with delicious data (Our object contains minimal info, but could easily be extended to expose a whole lot more data).
These statistics have helped us manage the backlog and keep our application afloat.
To access these stats, all you need to do is invoke the getNotifierRuntime() on the org.jboss.cache.Cache interface.
I have attached the source code for anyone who has a similar requirement.
*Update*
I have updated the jbosscache-core source code for for 3.2.5.AG (please find the jar attached). I replicated the steps mentioned above and no additional steps were required.
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-14766]
Create a new document in JBoss Cache Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
13 years, 6 months