Notification of shutdown commencing
by Brian Stansberry
I can't figure out a way to produce a notification of an impending
server shutdown if a user does a soft kill of the server process.
It's easy enough if shutdown is initiated by a management op; the op
handler can trigger the notification. But a soft kill triggers a
shutdown hook registered by the MSC ServiceContainer, and once that
starts, services start stopping semi-randomly and its too late to notify
anyone that that is going to start happening.
The MSC shutdown stuff isn't exposed, so there's no way to tie into
that. Adding another shutdown hook doesn't help as there's no
predictable order of execution.
--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
13 years, 1 month
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
14 years
Remote EJB invocation over HTTP(S)
by William DeCoste
Is this supported in AS7? I don't see anyway to configure Remoting to
expose HTTP (or any protocol settings) unless it's in one of the
free-form properties.
Thanks -Bill
--
Bill DeCoste
Principal Software Engineer, Red Hat
978-204-0920
wdecoste(a)redhat.com
14 years, 1 month
Characters not echoing back to terminal after running AS7 testsuite
by Brian Stansberry
A number of people are reporting that after building the current
upstream master and running the testsuite, the terminal used to do that
no longer echos characters you type back to the screen.
Just wanted to let you know we're aware of the issue and are working it,
with a pretty good idea as to the root cause.
Some solutions people have used to get a normally functioning terminal
after this happens:
1) The Reset command from the Terminal menu.
2) Running 'stty sane' from the command line
3) Open a new terminal. ;)
--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
14 years, 1 month
Component Freeze Today!
by Jason T. Greene
Just a reminder. All components for 7.1.2 are to be frozen today.
Sometime in the evening (US timezone), all updates will not be applied
until we tag 7.1.2 the following Monday.
Thanks,
--
Jason T. Greene
JBoss AS Lead / EAP Platform Architect
JBoss, a division of Red Hat
14 years, 1 month
Freeze Warning (Monday) & Upcoming Branching
by Jason T. Greene
Monday is our last day for component updates on 7.1.2 (EAP Only). We
will create a 7.1.2-prerelease tag, and then the official tag on May 7th
(Monday). We can still merge high priority AS specific fixes between
those dates, but anything requiring a component update will have to be
held off.
Please contact me anyway if an "emergency" update needs to occur. It
will likely cause a delay, so the sooner I know the better.
After May 7th we will be branching 7.1.x and master which will become
the 7.2 tree. I will send another email about how this affects our pull
request process.
Thanks!
--
Jason T. Greene
JBoss AS Lead / EAP Platform Architect
JBoss, a division of Red Hat
14 years, 1 month
Fwd: [jboss-l10n] The translation for AS 7 has started!
by Heiko Braun
Begin forwarded message:
> From: Angela Garcia Cardenas <agarcia(a)redhat.com>
> Subject: [jboss-l10n] The translation for AS 7 has started!
> Date: April 27, 2012 5:53:18 AM GMT+02:00
> To: jboss-l10n(a)lists.jboss.org
>
> Hi All!
>
> The translation for AS 7 has started!
>
> Brazilian Portuguese is finished!!!
>
> Spanish is half way through!
>
> German, French and Traditional Chinese are on the way!! and we need you to help us to bring the best of JBoss out there in your language so that everyone can take advantage of it!!!
>
> It is really easy to start contributing just follow this short Getting Started Guide (https://community.jboss.org/docs/DOC-16540?uniqueTitle=false) and you will be ready to start translating in no time!
>
> Cheers,
>
> Angela Garcia
> _______________________________________________
> jboss-l10n mailing list
> jboss-l10n(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-l10n
14 years, 1 month
Apache Xerces, XML Sec and JDK
by Anil Saldhana
Hi all,
the JDK incorporates JAXP and JSR 105 (XML Signature API). For this
reason, you can always write code to be based on the JDK, over the
latest xerces or xml security (santurio).
But in reality, from what I have read on the web, the JDK
implementations of JAXP and XML Signatures always lags behind what is in
xerces and santurio by at least a couple of versions.
Since JSR 106 (XML Encryption API) never went anywhere in the JCP, users
have to use apache xmlsec to get xmlenc.
What I want to highlight here is that we should prefer Apache xerces and
santurio over the JDK internal implementation.
Regards,
Anil
14 years, 1 month
Working with MSC Services from a org.jboss.as.controller.AbstractRemoveStepHandler
by David Bosschaert
Hi all,
I came upon an apparent deadlock when working with MSC services in the
AbstractRemoveStepHandler.performRuntime()
My code is like this:
performRuntime(OperationContext context, ModelNode operation, ModelNode
model) {
sr = context.getServiceRegistry(true);
...
which will hang under certain circumstances inside getServiceRegistry()
What I'm trying to do here is obtain an MSC service inside the
performRuntime() so I can make some calls on it.
The stack trace is below [1]. I'm a little confused about the fact that
it says 'locked 78fb1b0' and then a few lines up says 'waiting on
78fb1b0' in the same thread.
Is this a bug? Or should I be interacting with services in a different
way from here?
I'm also attaching the full threaddump.txt in case someone is
interested. I noticed that another thread is also doing something wrt to
removing a resource, but I don't understand why that should block a
service registry lookup.
Thanks,
David
[1] "management-handler-thread - 2" prio=5 tid=0000000001a41000
nid=0xb30e3000 in Object.wait() [00000000b30e2000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <00000000078fd1b0> (a
org.jboss.as.controller.ContainerStateMonitor)
at java.lang.Object.wait(Object.java:485)
at
org.jboss.as.controller.ContainerStateMonitor.await(ContainerStateMonitor.java:153)
- locked <00000000078fd1b0> (a
org.jboss.as.controller.ContainerStateMonitor)
at
org.jboss.as.controller.ModelControllerImpl.awaitContainerMonitor(ModelControllerImpl.java:428)
at
org.jboss.as.controller.OperationContextImpl.awaitContainerMonitor(OperationContextImpl.java:373)
at
org.jboss.as.controller.OperationContextImpl.getServiceRegistry(OperationContextImpl.java:226)
at
org.jboss.as.configadmin.parser.ConfigAdminExtension.getConfigAdminService(ConfigAdminExtension.java:48)
at
org.jboss.as.configadmin.parser.ConfigurationRemove.performRuntime(ConfigurationRemove.java:48)
at
org.jboss.as.controller.AbstractRemoveStepHandler$1.execute(AbstractRemoveStepHandler.java:50)
at
org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:385)
at
org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:272)
at
org.jboss.as.controller.AbstractOperationContext.completeStep(AbstractOperationContext.java:200)
at
org.jboss.as.controller.ModelControllerImpl$DefaultPrepareStepHandler.execute(ModelControllerImpl.java:466)
at
org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:385)
at
org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:272)
at
org.jboss.as.controller.AbstractOperationContext.completeStep(AbstractOperationContext.java:200)
at
org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:121)
at
org.jboss.as.controller.ModelControllerImpl$1.execute(ModelControllerImpl.java:304)
at
org.jboss.as.controller.ModelControllerImpl$1.execute(ModelControllerImpl.java:294)
at
org.jboss.as.configadmin.service.ConfigAdminServiceImpl.removeConfiguration(ConfigAdminServiceImpl.java:150)
at
org.jboss.as.configadmin.parser.ConfigurationRemove.performRuntime(ConfigurationRemove.java:50)
at
org.jboss.as.controller.AbstractRemoveStepHandler$1.execute(AbstractRemoveStepHandler.java:50)
at
org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:385)
at
org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:272)
at
org.jboss.as.controller.AbstractOperationContext.completeStep(AbstractOperationContext.java:200)
at
org.jboss.as.controller.ModelControllerImpl$DefaultPrepareStepHandler.execute(ModelControllerImpl.java:466)
at
org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:385)
at
org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:272)
at
org.jboss.as.controller.AbstractOperationContext.completeStep(AbstractOperationContext.java:200)
at
org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:121)
at
org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:139)
at
org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:108)
at
org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:287)
at
org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:487)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:680)
at org.jboss.threads.JBossThread.run(JBossThread.java:122)
14 years, 1 month
