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, 3 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, 5 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
13 years, 11 months
Test Suite Changes
by Stuart Douglas
I just just merged some changes to the test suite that QE requires for EAP (see below for a link to their requirements). As a result the manner in which the tests are run has changed slightly.
Due to limitations in maven it is no longer possible to activate all tests using mvn install -DallTests, instead you should use either:
./build.sh install -DallTests - To do a full build with all tests
./integration-tests.sh -DallTests - To just run all integration tests
Running individual tests from an IDE or via mvn test -Dtest=MyTest should work as normal.
Ondej Zizka (in CC) has been the person working on these changes, so if you have any questions or comments he is the person to talk to.
Stuart
*https://docspace.corp.redhat.com/docs/DOC-74146
*https://docspace.corp.redhat.com/docs/DOC-69049
*https://github.com/jbossas/jboss-as/pull/491
14 years
System properties propagated from command line using -D, -P or --properties aren't visible in CLI and console
by Rostislav Svoboda
Hi.
CLI and web console shows only properties defined in .xml configuration files. System properties propagated from command line using -D, -P or --properties args should be visible too. It would be useful for administrators when searching for possible problems, the same applies to devels. For domain I'd like to see sysprops on each instance and separate overview for DC.
Previous versions of AS/EAP provided such overview in /web-console/SysProperties.jsp. JVM based properties like java.vendor etc. would be beneficial too.
What do you think about it? Especially Alexey, Brian and Heiko.
There is JIRA for it, see https://issues.jboss.org/browse/AS7-2162
Thanks for comments.
Rosta
14 years
Performance runtime attributes via CLI
by Francesco Marchioni
*Dear devs,
I'm wondering if there's a scheduled release for gathering performance
runtime attributes information via CLI. In particular, I'm referring to the
older JMX's "currentThreadsBusy" (Web subsystem) or the "QueueSize" (Thread
subsystem) or "concurrentCalls" (EJB3 pool).
Thanks a lot
Francesco
*
14 years
importance of model descriptions and request validation
by Alexey Loubyansky
We don't validate request properties on the server side. Not in general,
at least. It's a responsibility of handler implementations that, in a
good case, validate only property values.
There were complains from CLI users about the fact that unsupported
properties in requests (put by mistake) were simply ignored w/o a
warning. I think it makes sense to fix it in a general way on the server
side.
Anyway, I added validation in the CLI based on the model description.
So now, of course, if a model description is incomplete, the CLI won't
allow an operation request which is actually correct.
Here is one example
AS7-2432 CLI does not allow a new security-realm to be defined within
the management section of a host
Alexey
14 years
Another Failing Tests E-Mail
by Darran Lofthouse
For the past couple of days I have been unable to perform an all tests
build, I have had some failures reported but the most common issue is
the testsuite hanging.
If I generate a thread dump for the surefire process I regularly see
threads stuck as in the trace at the bottom of this e-mail.
To me it seems like there may actually be two issues here: -
1 - The hang itself.
2 - The lack of any timeout.
Is anyone else experiencing this hang?
Regards,
Darran Lofthouse.
"main" prio=10 tid=0xb6a04c00 nid=0x7c0e in Object.wait() [0xb6bd8000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x7ed2b430> (a
org.jboss.as.protocol.mgmt.ManagementRequest$ManagementFuture)
at java.lang.Object.wait(Object.java:485)
at org.jboss.threads.AsyncFutureTask.await(AsyncFutureTask.java:192)
- locked <0x7ed2b430> (a
org.jboss.as.protocol.mgmt.ManagementRequest$ManagementFuture)
at org.jboss.threads.AsyncFutureTask.get(AsyncFutureTask.java:266)
- locked <0x7ed2b430> (a
org.jboss.as.protocol.mgmt.ManagementRequest$ManagementFuture)
at
org.jboss.as.protocol.mgmt.ManagementRequest.executeForResult(ManagementRequest.java:131)
at
org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeSynch(AbstractModelControllerClient.java:127)
at
org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:92)
at
org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:82)
at
org.jboss.as.arquillian.container.ManagementClient.isServerInRunningState(ManagementClient.java:134)
at
org.jboss.as.arquillian.container.managed.ManagedDeployableContainer.startInternal(ManagedDeployableContainer.java:140)
at
org.jboss.as.arquillian.container.CommonDeployableContainer.start(CommonDeployableContainer.java:75)
14 years
