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, 10 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, 11 months
CLI access
by Jan Lanik
Hi,
do you know how the mechanism which disables security check for CLI access from the same machine works?
I've been told that some ticket is generated by server and this ticket is then used by cli client for authentication.
I need to know where exactly is this ticket located and how to block the client from accessing it (delete ticket, restrict access..)
so that it is forced to use standard authentication as if it was run from a different machine.
The goal is to test the authentication for CLI - running it on two machines would be too complicated, so we need somehow bypass
that mechanism.
Thanks for any advice,
Jan
14 years
Questions on connecting to as71 via jmx
by Rob Stryker
Hey all:
We in JBossTools have a feature for jmx and would like to extend it's
jmx support to as71, but it seems not to be working in my most simple
main class example. I've found links on using jconsole, but no links
for raw clients. I do remember that AS3-6 required loading some custom
classes, and setting a principal and a credential.
So far, I add the following to the classpath of a new plain old java
project:
jboss-logging-3.1.0.GA.jar
jboss-marshalling-1.3.9.GA.jar
jboss-marshalling-river-1.3.9.GA.jar
jboss-remoting-3.2.2.GA.jar
jboss-sasl-1.0.0.Final.jar
remoting-jmx-1.0.0.Final.jar
xnio-api-3.0.3.GA.jar
xnio-nio-3.0.3.GA.jar
Then I write the following main method:
try {
String url = "service:jmx:remoting-jmx://localhost:1090";
Map<String, String[]> environment = new HashMap<String,
String[]>();
JMXConnector connector = JMXConnectorFactory.connect(new
JMXServiceURL(url), environment);
MBeanServerConnection connection =
connector.getMBeanServerConnection();
Set beanInfo = connection.queryNames(new ObjectName("*:*"),
null); //$NON-NLS-1$
} catch( Exception e ) {
e.printStackTrace();
}
If the server is not running, the result is the program never closes.
There are three threads, two of which are remoting endpoints, and a
DestroyJavaVM Thread. Exception is as follows:
java.lang.RuntimeException: Operation failed with status WAITING
at
org.jboss.remoting3.jmx.RemotingConnector.connect(RemotingConnector.java:155)
at
javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java:248)
at MyMain.main(MyMain.java:17)
How do I properly recognize this "RuntimeException"? Is there some
superclass I can catch, or is this it? Finally, how do I properly clean
up the connections to ensure those threads disappear?
If the server *is* running, launched via standalone.xml, the result is
identical.
Does the default as71 come with JMX enabled and exposed? If not, what
needs to be done to expose it?
Thanks again
- Rob Stryker
14 years
Overriding Deployment Descriptors
by Stuart Douglas
We have had a few requests for the ability to override deployment descriptors without having to open up a deployment archive and manually change the descriptor. I think there are two different approach that we can use to accomplish this, and I am was wondering what other people thought.
1) Allow the user to specify alternate deployment descriptors as part of the deployment process
At deployment time the user would be able to select specific deployment descriptors to override. I don't really like this approach, as it means that this information must also be provided on every re-deployment. It is also not really compatible with the deployment scanner, and would require changes to every client that does deployment to properly support it.
2) Allow the user to specify deployment descriptor overrides before a deployment takes places. These descriptors would be stored in the content repository, and the corresponding information in the model. When a deployment is performed that matches the deployment name in the model the deployment descriptors from the content repository are merged into the deployment.
e.g. to add the descriptor you would do something like:
/dd-override:my-deployment-descriptor:add(deployment="test.ear", file="test.jar/META-INF/ejb-jar.xml", content=…)
or for domain mode
/server-group=foo/dd-override:my-deployment-descriptor:add(deployment="test.ear", file="test.jar/META-INF/ejb-jar.xml", content=…)
Then when test.ear is deployed the contents if the overridden deployment descriptor will be override test.jar/META-INF/ejb-jar.xml.
2) is the approach that I prefer, as I think it gives the most flexibility.
What does everyone think?
Stuart
14 years, 1 month
Console 1.1.0 Update
by Heiko Braun
Notable changes in AS 7.1.1 at a glance:
Additional Subsystems:
- infinispan
- jgroups
- modcluster
- mail
Environment Properties:
The ability to view any system property that has been passed to the JVM when the server was started.
What's next?
In the next iteration we'll focus on accessibility issues (508 compliance), remaining translations and missing runtime operations (i.e. modcluster).
Thanks to Stan, Pavel and David for their contributions.
Regards, Heiko
14 years, 1 month
Re: [jboss-as7-dev] Breakup quickstarts into separate repos?
by Pete Muir
Adding Scott and jboss-as7-deb(a)lists.jboss.org.
No, I'm not on the jboss as internal list, not sure why we need to discuss it there?
This has come up a couple of times recently. The main issue I see is that this will result in around 80-100 git repositories, and a lot of scripting to create coordinated releases. It sounds like an admin and contribution nightmare to me.
I've thought about the problem Scott raises, and the best solution I've come up with so far is copy and paste:
git clone git://github.com/jbossas/quickstart.git ../quickstaets
cp -r ../quickstart/kitchensink/* .
git add src pom.xml
git push
which is only one more command.
We can also use a subtree merge (which is what you need to look at Scott, not submodules), but I feel this is much more complex to advise to users, as it involves explaining what a subtree merge is, over everyone knowing what a copy and paste is.
On 14 Mar 2012, at 01:00, Sande Gilda wrote:
> Did you see this? It sounds like it would be a problem to administer and release. What do you think?
>
> -------- Original Message --------
> Subject: Breakup quickstarts into separate repos?
> Date: Tue, 13 Mar 2012 17:11:25 -0400 (EDT)
> From: Scott Stark <sstark(a)redhat.com>
> To: jboss-as(a)redhat.com
>
> Would it make sense to break each quickstart into it's own repository and then integrate them back into the quickstart repository using the git submodule? What I would like to be able to do is something like the following in an openshift app repo to switch over to the quickstart:
>
> git remote add upstream -m master git://github.com/jbossas/kitchensink.git
> git pull -s recursive -X theirs upstream master
> git push
>
> There is no notion of checking out a subdirectory of a git repo. One problem I see with using submodules is that when I checkout the root project containing the submodules, the submodules content is not checked out. There is a comment in one submodule tutorial that claims later versions of git due checkout the submodule content, but with my git version 1.7.9.1 I don't see that happening.
>
>
14 years, 1 month
Naming a domain controller
by ssilvert＠redhat.com
In the first element of standalone.xml I can rename my server <server
name="George" ...
But for a domain controller, I don't see any way to give it a name. It
has no name at all. Is there any reason for this?
It would be helpful to give your domain controller a name. That way if
you have more than one you can tell which one you are talking to over
the management interface.
Stan
14 years, 1 month
Add notion of start/stop for deployments
by Thomas Diesler
Folks,
here is an update on AS7-2777 <https://issues.jboss.org/browse/AS7-2777>
I added deployment operations start/stop and the ability in the
DeploymentPlanBuilder to say
andDeploy().andNoStart()
Following the INSTALL phase there is a new ACTIVATE phase. When the
'deploy' operation is marked with StartPolicy.DEFERRED the
DeploymentPhaseService for ACTIVATE is created with initial Mode.NEVER,
which causes no execution of DUPs in ACTIVATE and beyond.
The 'start' operation, triggers continuation of DUP execution by setting
the DeploymentPhaseService for ACTIVATE to Mode.ACTIVE.
The 'stop' operation sets the DeploymentPhaseService for ACTIVATE to
Mode.NEVER
In this way start/stop can be called repeatedly
Test coverage in
[tdiesler@tdvaio smoke]$ mvn -Dtest=StandaloneDeploymentTestCase
install
Running org.jboss.as.test.smoke.osgi.StandaloneDeploymentTestCase
Tests run: 12, Failures: 0, Errors: 0, Skipped: 3, Time elapsed:
20.721 sec
https://github.com/tdiesler/jboss-as/tree/as2777
cheers
-thomas
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
JBoss OSGi Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
14 years, 1 month
Update AS config schema to 1.3
by Darran Lofthouse
Would there be any objections to a pull request going in to increment
the schema version without adding additional config?
The reason I ask is the changes I am working on are going to take a few
more days before I am ready to send them in and they involve schema
updates so the first change is enabling version 1.3 - in the meantime if
anyone else was to also need a schema update the work (actually takes a
few steps to update) would be duplicated and would most likely conflict.
Regards,
Darran Lofthouse.
14 years, 1 month
