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
11 years, 2 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
11 years, 3 months
Testsuite update
by Ondřej Žižka
Hi everyone,
as was discussed on this list, the current testsuite harness had some
problems fulfilling even basic requirements for various use cases,
including but not limited to:
* Using from IDE through pure maven
* -DallTests vs. individial modules vs. distinctive groups vs. even
overlaying groups
* Configuring AS using kind of hierarchical templates
* Imposing certain test groups order
* Invoking only some steps of the testsuite
* Running same tests with different AS configuration
etc etc.
I've been working on an updated concept, which is currently at
https://github.com/OndraZizka/jboss-as/commits/TS-modules-tmp .
I would like you to review it, run it, and send me some comments.
cd testsuite/integration
mvn clean install -f pom2.xml -DallTests -fae
mvn clean install -f pom2.xml -Dts.iiop
(There are 2 pom.xml's so I can compare two harnesses easily.)
The scripts are not updated yet so they do not work.
CLI and OSGi tests fail. To be sorted out.
The big news are:
* Execution split to modules
* Code and resources remained in the same location
* Added few system properties which provide paths to important
directories - see https://docs.jboss.org/author/display/AS71/AS+7
+Testsuite+Test+Developer+Guide
* Work directory is now in target/workdir
These cahnges exposed some issues in test code which need to be fixed -
hardcoded relative paths.
Since there were no system properties to use, there was no other way,
but from now on please use those properties, and fix your existing
tests.
(This would happen anyway because some tests clutter workdir (which
happens to be module's root dir) with various temp files.)
Thanks,
Ondra
11 years, 7 months
Access to public API jars from (remote) client applications
by Jaikiran Pai
I'm writing up the documentation for invoking remote EJBs from a
(really) remote application like standalone Java applications. One of
the things that we have to decide about is how we want the users to
access some of our public API jars (I'm not calling this "client" jars
since one of the previous discussions around this suggested that it
would confuse things). Right now we don't have a way where users can
*easily* add these public API jars to their classpath. Some of the
requirements that I can think of are:
1) These jars must be available at a well known location within the AS
distribution. i.e. the users shouldn't have to drill down into
individual module path to find the jars.
2) The jar names shouldn't contain the version names (since that will
require changes to client scripts if some API jar version changes)
3) Modular environment on the client side is not a requirement. i.e. the
client application should just be able add these jars to their classpath
and use them
4) IDE and build tool requirements should be taken into account
separately. i.e. a "bom" or some other IDE specific way of getting
access to these API jars _shouldn't_ be the only way of referencing
these jars.
5) Identifying the public API jars
Thoughts? Is this something that we could target for 7.1 Beta1?
-Jaikiran
11 years, 8 months
Wrong SecurityManagement/AuthenticationManager
by Dieter Tengelmann
Hi,
I've configured my security-domain with cache-type="default" in the
standalone.xml, an instance of JBossCachedAuthenticationManager is
initialized correctly via JNDIBasedSecurityManagement, but my
application is permanently authenticating via the JAAS login module. I
realized that "JBossAuthenticationManager" is used in all EJB parts,
only the JBOSS web realm is using the
JBossCachedAuthenticationManager...
JBossSecurityContext.getAuthenticationManager() delivers via
"DefaultSecurityManagement" an instance of
JbossAuthenticationManager
Is there a workaround for me to receive/set the correct
AuthenticationManager till you fix this bug? Not using the cache
causes some serious problems in my application...
Best regards,
Dieter Tengelmann
11 years, 9 months
patching is problematic
by Bill Burke
I just had another user submit a bug when they tried to upgrade resteasy
with AS7 and didn't know they had to edit a module.xml file.
Can we make this easier for users? i.e. a wildcard
resteasy-jaxrs-*.jar? Or have it load every jar in the directory by
default? Or something?
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
11 years, 9 months
Clustered invocation design
by David M. Lloyd
There are at least two basic paths we can follow for clustered
invocation based on the current architecture. The right choice is going
to depend primarily upon the expected use cases, which I am not in a
position to properly judge.
Option 1: Clustered Invocation Transport
----------------------------------------
In this option, we introduce a new "LAN" transport type for invocation
on the cluster. The transport would use direct TCP connections or UDP
messages (or both, depending on request size) to convey the invocation.
The characteristics of this option are as follows:
- Security: reliance on physical network security only (no TLS or
authentication)
- Latency is very low, even to new nodes
- Topology changes can be conveyed as separate asynchronous messages
- Invocations from external networks would happen through a proxy node,
with Remoting being bridged to the LAN, to perform security functions
Option 2: Load-balanced Remoting Connections
--------------------------------------------
In this option, we rely on the client to establish one or more Remoting
connection(s) to one or more of the nodes of the cluster. Logic in the
client will be used to determine what connection(s) to use for what
clusters. We have the option of automatically connecting as topology
changes or requiring the user to set up the connections in advance.
Note that automatic connection cannot work in the case of
user-interactive authentication. Characteristics:
- Security: full authentication and TLS supported
- Latency is low once the connection is established, however there is
some overhead involved in authentication and security negotiation
- Topology changes should be asynchronous notifications
- Each connection has to be separately authenticated
- Automatically establishing connections is not presently supported, so
we'd need a bit of infrastructure for that. Deal with user-interactive
authentication. Deal with connection lifecycle management. Deal with
configuration. This will be a point of fragility
Summary
-------
For both options, we have to determine an appropriate load-balancing
strategy. The choice of direction will affect how our clustering and
transaction interceptors function. We also have to suss out the logic
around dealing with conflicting or wrongly-ordered topology updates;
hopefully our existing policies will continue to apply.
--
- DML
11 years, 10 months
No validation of deployment descriptors
by Thomas Diesler
Folks,
this is related to
[AS7-2854 <https://issues.jboss.org/browse/AS7-2854>] JSR88 does
not validate deployment descriptors
I wonder whether it is the correct approach to validate the DDs in the
JSR88 layer. It seems more natural/correct to validate the DDs in the
subsystem that consumes the deployment. The behaviour I would expect is
that the (invalid) deployment reaches the server, fails during deploy
and that the deployment failure is communicated back to the jsr88 layer.
Thoughts?
cheers
-thomas
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
JBoss OSGi Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
11 years, 10 months
Attributes versus attributes
by David M. Lloyd
In our management model we have the terms "resources" and "attributes",
where resources are more or less defined as collections of attributes
with an address.
In our configuration file, we use XML which includes "elements" and
"attributes". I've noticed that in many cases, subsystems have taken it
as implied that a management attribute must be mapped directly to an XML
attribute. However, this is not the case.
In particular, our subsystem root XML elements should NOT have
attributes on the <subsystem> element. Due to the way that the XML
namespace is declared, attributes on this XML element are hard to see
and it may be confusing for users.
It is OK (and recommended even) to use nested XML elements for
management attributes. In particular we should always do this:
1) When declaring a subsystem top-level management attribute
2) When a nested management resource could, now or in the future, have
more than one or two attributes
Stylistically, often the only time you should really have more than one
XML attribute on an element is when you are dealing with a compound
value such as a time unit where you have the unit and the quantity, and
that sort of thing.
If you have created a subsystem element with top-level XML attributes,
please take a moment to fix it so we can have a clean configuration file
for CR1. Thanks.
P.S. don't make me bust out the "git annotate"!
--
- DML
11 years, 10 months
