March 2009 - jboss-dev-forums - Jboss List Archives

[Design of Messaging on JBoss (Messaging/JBoss)] - message durability tests

by timfox

When starting the server for these tests, if you limit the number of journal files it will make the tests quicker to run. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4221730#4221730 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4221730

15 years, 1 month

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Consumer max rate tests

by timfox

I'm wondering how these pass, since we haven't implemented consumer rate limiting yet View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4221729#4221729 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4221729

15 years, 1 month

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: WindowSize=1 behaviour?

by clebert.suconic＠jboss.com

>From now on: WindowSize = 1 => Buffer 1 message on the client WindowSize = 0 => No Buffering I have added a few tests for both largeMessages and regularMessages. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4221702#4221702 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4221702

15 years, 1 month

1
0
0 / 0

[Design of Management Features on JBoss] - Re: JBAS-6689 add support for activation policy metadata on

by ips

anonymous wrote : Further if I'm not changing PageSize, FullSize and DownCacheSize properties, but one of the properties which can be updated fine while the destination is running, then I should clearly not get any sort of warning or failure. To prevent the warnings from being logged by JBM, the Profile Service could do the following when updating the underlying Queue: if (queueService.getPageSize() != pageSizeManagedPropertyValue) | queueService.setPageSize(pageSizeManagedPropertyValue); | rather than just: queueService.setPageSize(pageSizeManagedPropertyValue); View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4221701#4221701 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4221701

15 years, 1 month

1
0
0 / 0

[Design of Management Features on JBoss] - JBAS-6689 add support for activation policy metadata on Mana

by charles.crouch＠jboss.com

Starting this thread to discuss how best to address the issues brought up in the http://jira.jboss.com/jira/browse/JBAS-6689. We can certainly discuss what we want to do in the future but I think the immediate priority is what can be done for the 5.1.CR1. So starting off I'm not sure adding support for activation policy to the JBAS layer and the console is not practical in the current timeframe (Scott/Emanuel can you comment on the JBAS side?). Even if support was added to JBAS as Ian describes in 6689, there is currently no way for the console to indicate that value A of a property is whats currently running and value B is what will be running after a restart. Looking at the troublesome properties... 11:11:42,488 WARN [QueueService] Clustered can only be changed when destination is stopped 11:11:42,488 WARN [QueueService] PageSize can only be changed when destination is stopped 11:11:42,488 WARN [QueueService] Cannot change the value of associated server's ObjectName after initialization! 11:11:42,488 WARN [QueueService] FullSize can only be changed when destination is stopped 11:11:42,488 WARN [QueueService] Cannot change the value of the JNDI name after initialization! 11:11:42,488 WARN [QueueService] DownCacheSize can only be changed when destination is stopped >From the above its clear that JNDI name and ObjectName should be readonly from the console perspective. In addition having looked at http://jira.jboss.com/jira/browse/JBMESSAGING-1368 and http://jira.jboss.com/jira/browse/JBMESSAGING-1235 its clear that the "Clustered" property is effectively readonly too. [In fact it worse than that since you need to make updates to the JBM_POSTOFFICE table if you want to change this value, but making something readonly is about as far as we can go right now]. That leaves PageSize, FullSize and DownCacheSize properties which require the destination to be stopped in order for the change to be successfully applied. I don't think the current situation is tenable, i.e. a user tries to change the PageSize property when the queue is running and the profile service responds back with success and when the console queries the ManagedComponent its gets the new value, which does *not* reflect what is actually running in the JBAS instance. I think the least that can be done here is to have the profile service return back failure from the update if the values we supplied it didn't actually get applied (Is it possible for the profile service to query the underlying component to check that the suggested updates have been applied?). Further if I'm not changing PageSize, FullSize and DownCacheSize properties, but one of the properties which can be updated fine while the destination is running, then I should clearly not get any sort of warning or failure. Regardless of what we ultimately end up doing in the short term I think the JBM1.4 destinations provide an excellent example of the sort of configurations we're going to need to support in the future. Cheers View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4221699#4221699 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4221699

15 years, 1 month

1
0
0 / 0

[Design of Management Features on JBoss] - Re: JBAS-6672, null values and defaults

by charles.crouch＠jboss.com

Ok, just to make sure we're all clear on the use cases the console needs to support, I've described them below. The *how* part, is up for more discussion. 1) user doesn't want to specify a particular value for a configuration property, they are happy to take the server default value (which itself may change over time). So if todays default is 20, we can't store 20 as the value of the property, since tomorrow the default may be 30, and the user has specified that they wish to always take the server default, regardless of what that is. 2) the user wants to specify a particular value for a configuration property. This is the typical scenario, e.g. a user enters in the jndiName for a datasource. 3) user wants to explicitly specify that a value is empty for a configuration property, they don't want to user the server default. For example the server default for "new-connection-sql" on a Datsource could be ";". So if the user leaves that value unset thats what the Datasource will use, however if the user explicitly sets the value to null (or empty string) then they are saying they don't want any SQL run on new connections. Thanks View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4221693#4221693 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4221693

15 years, 1 month

1
0
0 / 0

[Design of Management Features on JBoss] - Re: JBAS-6672, null values and defaults

by scott.stark＠jboss.org

In our discussion of this issue on Wed, I thought that it was not the admin console that was specifying the null value. Rather it was somewhere between the ManagementView and the deployers that were coming up with the value. Mostly likely its coming from population ManagedProperties from uninitialized values in the attachment by the ICFs. The main issue is we should not be taking an uninitialized value as a ManagedProperty value that was set via an admin edit. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4221645#4221645 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4221645

15 years, 1 month

1
0
0 / 0

[Design of JBoss Build System] - Build system goals

by pgier

Build System Goals This is an attempt at setting a more well defined direction for the build system within JBoss. Up until now the goals of jboss builds have been vaguely defined as "reproducible builds" and "migrate to maven". So the goal is to first figure out what reproducible builds really means and create a clear direction by opening up the discussion. Hopefully this will get everyone on the same page and make it easier to understand why certain changes take place and how the small changes fit into the bigger picture. Reproducible builds Maven in general takes the approach that release builds need to be reproducible, and snapshot builds do not. It seems clear that being able to reproduce just release builds is not enough for the needs of the JBoss projects. It should be easy to track down any build, including snapshots and determine how they were built (what svn revision, maven version, java version, etc), and use this information to re-run the same build. The ideal solution for this would allow a build to be run, on hudson for example, and deployed to the snapshots server. With nothing more than a pointer (url? artifact/groupId/version?) to the pom and the jar(s) on the snapshot server, Hudson should be able to re-run the same build using the same version of maven, java, the OS, and the same svn revision as the original build. In order to accomplish this, the first thing that needs to be done is to record the necessary information during a build (MRELEASE-352). This should be done during an early stage (validate?) of the build. The information should then be recorded somewhere that it can later be accessed, possibly as a separate file, or possibly in the jar manifest. The svn revision can be gathered from the existing buildnumber-maven-plugin. The svn revision then becomes available through a property. The second step involves changes to Hudson. Hudson would need the ability to read the build information and automatically set up an environment similar to what was used in the original build. Then the correct svn revision would be checked out and the project could be rebuilt. As a final step, Hudson would compare the generated artifacts to those in the repository and give information about whether they match. Keeping dependencies up to date and in sync during development There is a constant struggle to keep dependencies up to date while developing. The maven model of using snapshots has several problems, and doing tagged releases for every build is not practical. The ideal solution would allow the developer to easily choose between development snapshot dependencies and more stable release versions. There is currently some work being done on the versions maven plugin that might help to make it a little easier to keep dependencies up to date. There is a goal to search for newer versions of dependencies and update the pom accordingly. It would also be useful to be able to easily compare dependency versions between two projects (JBBUILD-512). This would allow component developers (ejb3 for example) to quickly compare the versions of their dependencies to those of another project such as JbossAS. In the future this type of feature might be integrated into IDE plugins. Dependency Resolution In order for builds to be completely reproducible, dependencies must be resolved in exactly the same way from one invocation to the next. This can be an issue when the artifacts are not ordered in the same way for each build. Maven is currently undergoing changes in its dependency resolution component. It is likely that changes in dependency resolution will continue for some time to come, so this requires that we must track what version of maven was used to build the application, and require that this same version be used to reproduce the same build. Maven has limited support for version ranges, but it is not practical for the pom of a released project to include any version ranges. Because if the pom does contain ranges, then any change in the repository could mean a change in the build. So either a snapshot of the repository would have to be saved, or all ranges would have to be resolved to the actual version used. Simple/reliable release process The ideal solution would be to have two options available at any given time: a completely automated release using Hudson (or a local developer workstation when needed), or a more manual step by step process that allows the developer more fine grained control over the release process. One of the problems with the current release plugin is that a "dryRun" release build is not exactly the same as a "prepare", and a "prepare"; build is not exactly the same as a "perform". And occasionally a successful dry run or prepare step can still result in a failed perform. Comments/Feedback are welcome as always! View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4221642#4221642 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4221642

15 years, 1 month

1
0
0 / 0

[Design of Management Features on JBoss] - Re: ManagedObjects for MBeans

by scott.stark＠jboss.org

The generic mbean to ManagedComponent feature I'm working on will allow the ComponentType to be specified, so it can be unique to the ManagedComponent. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4221633#4221633 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4221633

15 years, 1 month

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: intermittent failures i am seeing

by clebert.suconic＠jboss.com

It didn't fail with that change. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4221622#4221622 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4221622

15 years, 1 month

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums March 2009