Preventing merge commits
by Jason T. Greene
If you want to prevent merge commits from ever entering a particular
branch of yours, say master, just do this:
git config branch.master.mergeoptions --ff-only
--
Jason T. Greene
JBoss AS Lead / EAP Platform Architect
JBoss, a division of Red Hat
13 years, 7 months
Limiting Server Thread Usage
by Jason T. Greene
Moving to a new thread.
The big problem we run into with this is that almost every application
of a thread pool that we have needs to be highly tailored to its usage
to get the most optimal performance. So we end up with quite a few
different pools and it becomes difficult to impose a server wide limit.
There however some potential strategies we could take. Although I am
unsure as to how the overall effectiveness would be:
1. Sharing idle threads between pools
2. Force everything to go through a special blocking thread factory via
instrumentation of java.lang.Thread. Any attempt to allocate over the
max would lead to thread reclamation attempts and finally blocking until
a timeout is reached.
3. Some kind of auto-tuning weighting model. If the max total threads is
N, force all thread pools to use a percentage of N, potentially based on
establishing current config value divided by combined total.
One thing I wonder though is if cloud providers are "barking up the
wrong tree"? It seems a better limitation of an application is raw CPU
clock time and max memory usage. How they split that time into threads
doesn't really affect the scalability of the physical server, it's all
virtual process performance (who cares if someone wastes time context
switching?).
On 9/14/11 10:39 AM, Scott Stark wrote:
> The other big cross cutting concern is controlling the total number of
> threads in use by the application server. When running under a
> constrained environment that uses something like pam_limits module to
> control how many process(==java threads) a user can have, it is
> difficult to know what the server max thread usage is right now.
>
--
Jason T. Greene
JBoss AS Lead / EAP Platform Architect
JBoss, a division of Red Hat
13 years, 9 months
"driver-name" attribute while creating the JDBC driver
by Jaikiran Pai
I was trying out creation of a JDBC driver through the management
operation. Initially I used this operation:
[standalone@localhost:9999 /]
/subsystem=datasources/jdbc-driver=mysql-5-driver:add(driver-module-name=mysql,
driver-class-name=com.mysql.jdbc.Driver)
Note that it _doesn't_ specify the "driver-name" attribute. However, it
failed with:
{
"outcome" => "failed",
"failure-description" => "JBAS014749: Operation handler failed: No
child 'driver-name' exists",
"rolled-back" => true
}
(the error message isn't clear by the way, but that's a different matter).
I then had to change the operation to explicitly specify the driver-name
attribute:
[standalone@localhost:9999 /]
/subsystem=datasources/jdbc-driver=mysql-5-driver:add(driver-name=mysql-5-driver,
driver-class-name=com.mysql.jdbc.Driver, driver-module-name=mysql)
That worked fine.
But why is this operation unlike other "add" operations which use the
value before the ":" as the name of the new resource? By the way, I even
tried this command:
[standalone@localhost:9999 /]
/subsystem=datasources/jdbc-driver=foo:add(driver-name=bar,
driver-class-name=com.mysql.jdbc.Driver, driver-module-name=mysql)
Note that I use "foo" as the resource name for the add operation and
"bar" as the driver-name attribute value. This creates a driver named
"bar" in the standalone.xml:
<driver name="bar" module="mysql">
<driver-class>com.mysql.jdbc.Driver</driver-class>
</driver>
and there's no reference to "foo" anywhere. So what's the significance
of using it in the operation?
-Jaikiran
13 years, 12 months
Configuration changes
by Kabir Khan
domain.xml and standalone-XXX.xml are now generated from templates and subsystem snippets (apart from standalone-minimal.xml). I've verified as best I can that we're generating good configs but please see build/src/main/resources/configuration/ReadMe.txt and take a moment to verify your subsystem configurations look the way you want and let me know if there are any problems.
I have left the old configurations in build/src/main/resources/configuration/retired-delete-once-stable for now, with http://issues.jboss.org/browse/AS7-3853 to remind me to delete them in the not too distant future. The old configs don't get used at all, they are just there as a handy reference in case of inconsistencies.
14 years
Re: [jboss-as7-dev] System property replacement in deployment descriptors
by Oleg Kulikov
Hi Jaikiran,
Can you explain more details about your vision of the property replacement
task. In general it is interested how deep it should be shared between
different substems where xml descriptors are used. Should it be a common
parsing utility with description which properies allow expressions or it
may be just a simple utility method shared between parsing methods?
-- Oleg.
14 years
Getting rid of test JMS destinations
by Brian Stansberry
Hi Pete,
In EAP 6 the test/topic and test/queue destinations are removed from
standalone-xxx.xml (and domain.xml). We'd like to do the same in
upstream in 7.1.1 or 7.2[1].
For 7.1.1 can any quickstarts that use these destinations be modified to
set up their own destinations?
--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
14 years
Detecting deployment location errors for xml files using a JEE schema
by Paul Robinson
A common problem I see again and again is when people miss-spell the
filenames of XML artefacts that live in the META-INF and WEB-INF
directories of a JEE archive. I also see people (myself included)
putting these artefacts in the wrong location, For example, putting the
beans.xml file in the META-INF of a .war when it belongs in the WEB-INF.
This can cause a big headache as it looks like you have created the
right artifact, but it is not taking effect. It would be great if we
could detect this type of thing and warn the developer at deploy time.
There seems to be a move towards using marker files (beans.xml,
faces-config.xml) to enable technologies, so this issue could become
more prevalent.
One solution, I was thinking about, is to check the schema type of all
the XML files in the META-INF and WEB-INF directories. For each schema
that we recognize (http://java.sun.com/xml/ns/persistence for example),
we check that it's file name is correct and it is in a location where it
will be processed.
Does this sound like a sensible thing for us to do?
Paul.
--
Paul Robinson
Web service transactions lead
paul.robinson(a)redhat.com
JBoss, a Division of Red Hat
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham (USA), Brendan Lane (Ireland), Matt Parson
(USA), Charlie Peters (USA)
14 years
