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, 2 months
Graceful Shutdown (Revision 2)
by Jason T. Greene
*EDITED*
We've worked out the rough outline of how graceful shutdown will work in
AS7.
The process of graceful shutdown actually is reflected by a number of
states:
1. Running - all services acting normally
2. Suspending - services refuse new "permits" (see below), existing
permits are allowed to be retained (and threads running under such a
permit may still acquire new permits)
3. Suspended - no permits are present and none may be issued
4. Shutting Down - our existing server stop process / reload admin mode
The following transitions are allowed:
1. Running → Suspending: Transition occurs at user request (to suspend
or gracefully shut down).
2. Suspending → Suspended: Transition occurs when all permits are cleared.
3. Suspending → Running: Transition occurs at user request (to exit
suspend mode or cancel graceful shutdown before it completes).
4. Suspended → Running: Transition occurs at user request (to exit
suspend mode).
5. Suspended → Shutting Down: Transition occurs automatically (if a
graceful shutdown was requested) or at user request (if a shut down
request of any kind is entered in the Suspended state).
6. Running → Shutting Down: Transition occurs at user request (to shut
down the server "un-gracefully").
7. Suspending → Shutting Down (User aborts a graceful shutdown)
These "permits" are issued by the "Shutdown Manager", whose job is to
manage these states. They are issued corresponding to the following events:
1. The invocation of an EJB method
2. The creation of a web session
3. A creation of a transaction
4. MessageEndpoint and WorkManager aquire permit allowing for release()
from a thirdparty to indicate connection close.
When a permit cannot be issued due to the server shutting down, a
standard exception message should be produced so that the user can see a
familiar error message regardless of what mechanism is used to access
the server.
--
- DML
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
13 years, 9 months
Re: [jboss-as7-dev] problems with deployment overlays and linking
by Brian Stansberry
Do you see value in cherry-picking his patch and adjusting the command
first? The issues you find implementing the command are what led to
these changes, so it'd be nice to know your commands work before merging
his stuff.
On 8/31/12 5:03 AM, Alexey Loubyansky wrote:
> Great. Once it's merged I'll adjust the deployment-overlay command and
> submit a pull request.
>
> Thanks,
> Alexey
>
> On 08/31/2012 05:29 AM, Stuart Douglas wrote:
>>
>> I have done up an initial implementation of this here
>> https://github.com/jbossas/jboss-as/pull/2989 .
>>
>>
>> Stuart
>>
>> On 24/08/2012, at 2:08 AM, Brian Stansberry <brian.stansberry(a)redhat.com
>> <mailto:brian.stansberry@redhat.com>> wrote:
>>
>>> On 8/23/12 3:39 AM, Emanuel Muckenhuber wrote:
>>>> On 08/23/2012 01:11 AM, Brian Stansberry wrote:
>>>>> Sorry for the slow responses on this thread.
>>>>>
>>>>> I think we should go with Stuart's approach, particularly if Alexey is
>>>>> comfortable that the CLI can support high level commands associated
>>>>> with it.
>>>>>
>>>>
>>>> Yeah, i am fine then as well - nevertheless some comments inline :)
>>>>
>>>
>>> Me too. ;)
>>>
>>>>>
>>>>> On 8/22/12 8:22 AM, Emanuel Muckenhuber wrote:
>>>>>>
>>>>>> My main concern is regarding the domain mode, since the additional
>>>>>> linking does not seem to be necessary to me and just additional steps
>>>>>> mgmt clients have to take care of.
>>>>>>
>>>>>> Whereas the deployment-scanner is a single client for standalone,
>>>>>> which
>>>>>> is under our control. So i wanted to see if we there is a way we can
>>>>>> make this work which also satisfies your use cases.
>>>>>>
>>>>>> I have two things in mind which i'll try to explain quickly:
>>>>>>
>>>>>> 1) you still link the overlays as part of the <deployment />, however
>>>>>> the deploment-scanner is aware of that and won't remove deployments
>>>>>> with
>>>>>> overlays until you use a specific invalidation marker.
>>>>>>
>>>>>
>>>>> This requires that the overlays be controlled by the scanner as well.
>>>>> Why? Because we don't persist the model resource for
>>>>> scanner-controlled
>>>>> deployments. So if a user linked a non-scanner-controlled overlay to a
>>>>> scanner controlled deployment (which seems quite rational if the
>>>>> overlay
>>>>> involves some environmental settings that never change), the link
>>>>> information will be lost on server reboot.
>>>>>
>>>>
>>>> I know, but that's an ancient limitation. I guess we could just
>>>> start to
>>>> persist stuff.
>>>>
>>>
>>> We'd have to persist some association between a deployment and a scanner
>>> (e.g. scanner="default" on the deployment element) and then use that to
>>> indicate that the server should not auto-deploy on boot but should defer
>>> to the scanner to tell it what to do. And then alter the scanner to add
>>> logic for it to reconcile the state it sees in the scan directory vs
>>> what the model shows.
>>>
>>> Doable, but a fair bit of work.
>>>
>>> I considered this before going with the "don't persist" approach. I
>>> don't recall though if there was some fundamental problem with it that
>>> I'm not remembering, or if it was solely that "don't persist" was doable
>>> within the time constraints.
>>>
>>>>>> 2) use overlay directories - this is more the file based approach,
>>>>>> Where
>>>>>> we just pick the "deployment.name + suffix" for the overlay. So there
>>>>>> would be an automatic overlay/linking done by the deployment-scanner.
>>>>>>
>>>>>
>>>>> Same issue as 1).
>>>>>
>>>>
>>>> Not really. It can automatically recreate the overlays therefore it
>>>> does
>>>> not require persistent information.
>>>>
>>>
>>> It can only recreate the association for overlays that it scans, not
>>> ones that were added via CLI/console.
>>>
>>>>>> 2.1) the overlay directory could be just a link to a virtual file (a
>>>>>> shared <deployment-overlay />) [1] - so in this case the overlays are
>>>>>> managed by the model and are not linked to the deployment lifecycle.
>>>>>>
>>>>>
>>>>> I confess I don't understand this. In particular, how does it
>>>>> fundamentally differ from what Stuart proposes in terms of how to
>>>>> organize the data?
>>>>>
>>>>
>>>> Well that is the point. It's basically the same, just that it removes
>>>> the requirement for the additional linking in the domain.
>>>>
>>>
>>> Ok, then I still don't understand it. If it solves a problem I'd like to
>>> understand. Can you explain further?
>>>
>>>>>> On 08/22/2012 01:03 AM, Stuart Douglas wrote:
>>>>>>>
>>>>>>> So what are we going to do here? Personally I much prefer the idea
>>>>>>> of having this stored in the model and linking it to a deployment,
>>>>>>> so the overlay lifecycle is not tied to that of the deployment.
>>>>>>>
>>>>>>> Another idea I had is that we could do something like define the
>>>>>>> overlays at domain level, but then define the links at server
>>>>>>> group or server level using the same name. basically something like:
>>>>>>>
>>>>>>> /deployment-overlay=myOverlay/content=WEB-INF/web.xml
>>>>>>> /deployment-overlay=myOverlay/content=WEB-INF/ejb-jar.xml
>>>>>>>
>>>>>>> /server-group=server-group1/deployment-overlay=myOverlay/deployment=test.war
>>>>>>>
>>>>>>> /server-group=server-group1/deployment-overlay=myOverlay/deployment=*.war
>>>>>>>
>>>>>>>
>>>>>>> For standalone they would just be combined, similar to what I had
>>>>>>> below:
>>>>>>>
>>>>>>>
>>>>>>> /deployment-overlay=myOverlay/content=WEB-INF/web.xml
>>>>>>> /deployment-overlay=myOverlay/content=WEB-INF/ejb-jar.xml
>>>>>>> /deployment-overlay=myOverlay/deployment=test.war
>>>>>>> /deployment-overlay=myOverlay/deployment=*.war
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Stuart
>>>>>>>
>>>>>>> On 17/08/2012, at 11:03 PM, Emanuel Muckenhuber
>>>>>>> <emuckenh(a)redhat.com <mailto:emuckenh@redhat.com>> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>> On 08/17/2012 02:52 AM, Stuart Douglas wrote:
>>>>>>>>> The big problem with this is that it does not work with the
>>>>>>>>> deployment scanner.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Yeah, the deployment-scanner is always a story for itself.
>>>>>>>> However i think we could actually make it persist information and
>>>>>>>> be aware of overlays.
>>>>>>>>
>>>>>>>> Having overlays as part of the deployment means the lifecycle is
>>>>>>>> managed together, so the deployment-scanner could define it's own
>>>>>>>> invalidation policy. May it be based on whether the content got
>>>>>>>> removed or we have a specific marker for that.
>>>>>>>>
>>>>>>>> We could also think of providing a file-based overlay solution,
>>>>>>>> managed by the deployment scanner only. In the end people use the
>>>>>>>> deployment-scanner for a reason, so perhaps not having to worry
>>>>>>>> about the model or "content" folder could be interesting. This
>>>>>>>> would not even need to access persistent information though.
>>>>>>>> Anyway just some ideas on the side.
>>>>>>>>
>>>>>>>>> It also has to be specified on every re-deploy.
>>>>>>>>
>>>>>>>> When you do a "remove" and "add" then yes. We do have specific
>>>>>>>> operations to replace the content and redeploy the deployment
>>>>>>>> without removing the information from the model.
>>>>>>>>
>>>>>>>>> I think the simplest solution here
>>>>>>>>> is to just move the links under the deployment-overlays element
>>>>>>>>> and loose the
>>>>>>>>> flexibility to link at different levels. e.g:
>>>>>>>>>
>>>>>>>>> /deployment-overlay=myOverlay/deployment=test.war
>>>>>>>>> /deployment-overlay=myOverlay/deployment=*.jar
>>>>>>>>>
>>>>>>>>
>>>>>>>> Yes, i was not really going for the simplest solution for now -
>>>>>>>> this would most likely would be it :)
>>>>>>>
>>>>>> _______________________________________________
>>>>>> jboss-as7-dev mailing list
>>>>>> jboss-as7-dev(a)lists.jboss.org <mailto:jboss-as7-dev@lists.jboss.org>
>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>>>>
>>>>>
>>>>>
>>>> _______________________________________________
>>>> jboss-as7-dev mailing list
>>>> jboss-as7-dev(a)lists.jboss.org <mailto:jboss-as7-dev@lists.jboss.org>
>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>>
>>>
>>>
>>> --
>>> Brian Stansberry
>>> Principal Software Engineer
>>> JBoss by Red Hat
>>> _______________________________________________
>>> jboss-as7-dev mailing list
>>> jboss-as7-dev(a)lists.jboss.org <mailto:jboss-as7-dev@lists.jboss.org>
>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>
>>
>>
>> _______________________________________________
>> jboss-as7-dev mailing list
>> jboss-as7-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>
--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
13 years, 10 months
rename jboss-cli.sh?
by Cheng Fang
I've been playing with jboss as7 cli and like to share my experience. I
understand that in AS7-2310, it was renamed from jboss-admin.sh to
jboss-cli.sh, so a second renaming seems disruptive, but anyway here it
goes...
First, can we remove the .sh file extension? Tools like ant, mvn and
groovy are all shell scripts but do not have the .sh extension. Users
just need to execute it, without concerning if it is written as a shell
script to binary. Having the .sh extension limits ourselves in impl
options. On Windows we continue to have .bat, which is unavoidable, but
users just need to run "jboss-cli" with .bat extension.
jboss-cli.sh is quite some typing for users, and the first TAB
completion will not enough. It takes 2 tabs to complete jboss-cli.sh
Secondly, can we remove the -cli part to further simplify the name? It
seems to be superfluous as many terminal commands are cli. IMO, a name
needs to reflect the purpose of the tool, rather than its form. By
having -cli in the name, we are again restricting it to be a cli tool.
But didn't we have a GUI form that can be launched by 'jboss-cli.sh --gui'?
I personally like the old name jboss-admin.sh better, except that it's
too long.
Cheng
13 years, 10 months
EJB Over HTTP
by Eduardo Martins
Hi everyone, I'm about to (finally) start working on EJB over HTTP, which seems to be an essential feature that we had in previous AS versions.
I don't know much yet about the previous design and implementation, but here is a doc wrt AS5 that explains it: https://community.jboss.org/wiki/EJB3OverHTTPHTTPSInJBossAS-5
The JIRA issue for this development is https://issues.jboss.org/browse/AS7-4714 , which contains already some ideas for the implementation.
So, first question, anyone knows if the old design and/or implementation was good enough to be migrated? Or perhaps someone knows if it had any issues?
In a IRC chat and in the JIRA issue, websockets and xnio were mentioned as possible foundations for the AS7 implementation, which would mean to discard previous code already at low level. What is the reasoning for this, i.e., what advantages does the adaption of either of these bring to the feature and to AS7 as a whole?
Your contribution on this feature discussion is very welcome, thanks ;-)
-- E
13 years, 10 months
problems with deployment overlays and linking
by Alexey Loubyansky
I've been prototyping a CLI command that manages deployment overlays and
got worried :)
I think, the current representation (actually, the data structure, in
other words) of the overlays and their linking in the management model
will lead to a lot of issues related to consistency of the data and
complicate management of deployments in general.
Basically, it's a many-to-many relationship between overlays and
deployments. Currently, overlays and deployments are defined separately
and linked using the "third table", each row of which consists of a link
name, overlay name and deployment name (or deployment name regex). (BTW,
I understand this design is not random, there were reasons to organize
it this way but I'd like to raise my concerns).
Which is a common practice in a relational database design but our
management model is not as sophisticated, yet :) We don't have:
- foreign key constraints (again, yet, I know Brian is going to look
into that);
- no cascade-delete;
- no queries (e.g. by node attributes).
CREATING A LINK AND LOOKING FOR IT
To create a link between an overlay and a deployment, I have to come up
with a name for it, which has to be unique, like a primary key. Well, I
chose the format overlay_name-deployment_name. Then, in CLI, I rely on
this format to search for the link(s), since searching by resource
attributes turns out to be much more complicated, although possible.
Actually, even searching using this naming format by deployment name or
an overlay name is not that smooth. So, the CLI now expects a specific
naming format. Taking into account that the CLI is not the only
management tool and that any application or user can manage things
"manually", it'd be good for all the users and tools to agree on the
naming format, which is not practical.
REMOVING A DEPLOYMENT
Until now it was about removing only the deployment. Now, not to run
into inconsistencies in the model, the "third table" has to be searched
for references and cleaned up if found.
Removing an overlay leads to the same consequences, of course, which is
unavoidable anyway. But I think we could re-organize the model to
minimize the risks or running into inconsistencies and simplify management.
ALTERNATIVE STRUCTURES
I discussed these issues with Emanuel, who agreed and had in mind
another idea to represent this in the model, which I actually find more
logical and elaborate. I'll let him follow up and describe it in details.
Thanks,
Alexey
13 years, 10 months
Build failed in Jenkins: as7-master-testsuite-ip6 #3674
by ci-builds＠redhat.com
See <http://lightning.mw.lab.eng.bos.redhat.com/jenkins/job/as7-master-testsui...>
------------------------------------------
[...truncated 21435 lines...]
[INFO] --- maven-resources-plugin:2.5:resources (default-resources) @ jboss-as-testsuite-benchmark ---
[debug] execute contextualize
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory <http://lightning.mw.lab.eng.bos.redhat.com/jenkins/job/as7-master-testsui...>
[INFO]
[INFO] --- maven-resources-plugin:2.5:copy-resources (ts.copy-jbossas.groups) @ jboss-as-testsuite-benchmark ---
[debug] execute contextualize
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory <http://lightning.mw.lab.eng.bos.redhat.com/jenkins/job/as7-master-testsui...>
[INFO]
[INFO] --- maven-resources-plugin:2.5:testResources (default-testResources) @ jboss-as-testsuite-benchmark ---
[debug] execute contextualize
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory <http://lightning.mw.lab.eng.bos.redhat.com/jenkins/job/as7-master-testsui...>
[INFO] skip non existing resourceDirectory <http://lightning.mw.lab.eng.bos.redhat.com/jenkins/job/as7-master-testsui...>
[INFO]
[INFO] --- xml-maven-plugin:1.0:transform (ts.config-as.ip) @ jboss-as-testsuite-benchmark ---
[WARNING] The directory <http://lightning.mw.lab.eng.bos.redhat.com/jenkins/job/as7-master-testsui...,> which is a base directory of a ValidationSet or TransformationSet, does not exist.
[WARNING] No files found for transformation by stylesheet <http://lightning.mw.lab.eng.bos.redhat.com/jenkins/job/as7-master-testsui...>
[INFO]
[INFO] --- xml-maven-plugin:1.0:transform (ts.config-as.trace-logging) @ jboss-as-testsuite-benchmark ---
[WARNING] The directory <http://lightning.mw.lab.eng.bos.redhat.com/jenkins/job/as7-master-testsui...,> which is a base directory of a ValidationSet or TransformationSet, does not exist.
[WARNING] No files found for transformation by stylesheet <http://lightning.mw.lab.eng.bos.redhat.com/jenkins/job/as7-master-testsui...>
[INFO]
[INFO] --- maven-compiler-plugin:2.3.2:testCompile (default-testCompile) @ jboss-as-testsuite-benchmark ---
[INFO] No sources to compile
[INFO]
[INFO] --- maven-surefire-plugin:2.11:test (default-test) @ jboss-as-testsuite-benchmark ---
[INFO] No tests to run.
[INFO] Surefire report directory: <http://lightning.mw.lab.eng.bos.redhat.com/jenkins/job/as7-master-testsui...>
-------------------------------------------------------
T E S T S
-------------------------------------------------------
Results :
Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building JBoss Application Server Test Suite: Stress Tests 7.2.0.Alpha1-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- maven-clean-plugin:2.4.1:clean (default-clean) @ jboss-as-testsuite-stress ---
[INFO] Deleting <http://lightning.mw.lab.eng.bos.redhat.com/jenkins/job/as7-master-testsui...>
[INFO]
[INFO] --- maven-enforcer-plugin:1.0:enforce (ban-bad-dependencies) @ jboss-as-testsuite-stress ---
[INFO]
[INFO] --- maven-enforcer-plugin:1.0:enforce (enforce-java-version) @ jboss-as-testsuite-stress ---
[INFO]
[INFO] --- maven-enforcer-plugin:1.0:enforce (enforce-maven-version) @ jboss-as-testsuite-stress ---
[INFO]
[INFO] --- buildnumber-maven-plugin:1.0:create-timestamp (get-build-timestamp) @ jboss-as-testsuite-stress ---
[INFO]
[INFO] --- buildnumber-maven-plugin:1.0:create (get-scm-revision) @ jboss-as-testsuite-stress ---
[INFO]
[INFO] --- maven-help-plugin:2.1.1:active-profiles (help.active-profiles) @ jboss-as-testsuite-stress ---
[INFO] Active profile report written to: <http://lightning.mw.lab.eng.bos.redhat.com/jenkins/job/as7-master-testsui...>
[INFO]
[INFO] --- maven-help-plugin:2.1.1:effective-pom (help.effective-pom) @ jboss-as-testsuite-stress ---
[INFO] Effective-POM written to: <http://lightning.mw.lab.eng.bos.redhat.com/jenkins/job/as7-master-testsui...>
[INFO]
[INFO] --- maven-help-plugin:2.1.1:effective-settings (help.effective-settings) @ jboss-as-testsuite-stress ---
[INFO] Effective-settings written to: <http://lightning.mw.lab.eng.bos.redhat.com/jenkins/job/as7-master-testsui...>
[INFO]
[INFO] --- maven-help-plugin:2.1.1:system (help.system) @ jboss-as-testsuite-stress ---
[INFO] System report written to: <http://lightning.mw.lab.eng.bos.redhat.com/jenkins/job/as7-master-testsui...>
[INFO]
[INFO] --- properties-maven-plugin:1.0-alpha-2:write-project-properties (default) @ jboss-as-testsuite-stress ---
[INFO]
[INFO] --- maven-dependency-plugin:2.3:copy (copy-annotations-endorsed) @ jboss-as-testsuite-stress ---
[INFO] Configured Artifact: org.jboss.spec.javax.annotation:jboss-annotations-api_1.1_spec:?:jar
[INFO] Copying jboss-annotations-api_1.1_spec-1.0.1.Final.jar to <http://lightning.mw.lab.eng.bos.redhat.com/jenkins/job/as7-master-testsui...>
[INFO]
[INFO] --- maven-resources-plugin:2.5:resources (default-resources) @ jboss-as-testsuite-stress ---
[debug] execute contextualize
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory <http://lightning.mw.lab.eng.bos.redhat.com/jenkins/job/as7-master-testsui...>
[INFO]
[INFO] --- maven-resources-plugin:2.5:copy-resources (ts.copy-jbossas.groups) @ jboss-as-testsuite-stress ---
[debug] execute contextualize
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory <http://lightning.mw.lab.eng.bos.redhat.com/jenkins/job/as7-master-testsui...>
[INFO]
[INFO] --- maven-resources-plugin:2.5:testResources (default-testResources) @ jboss-as-testsuite-stress ---
[debug] execute contextualize
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory <http://lightning.mw.lab.eng.bos.redhat.com/jenkins/job/as7-master-testsui...>
[INFO] skip non existing resourceDirectory <http://lightning.mw.lab.eng.bos.redhat.com/jenkins/job/as7-master-testsui...>
[INFO]
[INFO] --- xml-maven-plugin:1.0:transform (ts.config-as.ip) @ jboss-as-testsuite-stress ---
[WARNING] The directory <http://lightning.mw.lab.eng.bos.redhat.com/jenkins/job/as7-master-testsui...,> which is a base directory of a ValidationSet or TransformationSet, does not exist.
[WARNING] No files found for transformation by stylesheet <http://lightning.mw.lab.eng.bos.redhat.com/jenkins/job/as7-master-testsui...>
[INFO]
[INFO] --- xml-maven-plugin:1.0:transform (ts.config-as.trace-logging) @ jboss-as-testsuite-stress ---
[WARNING] The directory <http://lightning.mw.lab.eng.bos.redhat.com/jenkins/job/as7-master-testsui...,> which is a base directory of a ValidationSet or TransformationSet, does not exist.
[WARNING] No files found for transformation by stylesheet <http://lightning.mw.lab.eng.bos.redhat.com/jenkins/job/as7-master-testsui...>
[INFO]
[INFO] --- maven-compiler-plugin:2.3.2:testCompile (default-testCompile) @ jboss-as-testsuite-stress ---
[INFO] No sources to compile
[INFO]
[INFO] --- maven-surefire-plugin:2.11:test (default-test) @ jboss-as-testsuite-stress ---
[INFO] No tests to run.
[INFO] Surefire report directory: <http://lightning.mw.lab.eng.bos.redhat.com/jenkins/job/as7-master-testsui...>
-------------------------------------------------------
T E S T S
-------------------------------------------------------
Results :
Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO]
[INFO] JBoss Application Server: Build Configuration ..... SUCCESS [9.156s]
[INFO] JBoss Application Server: Parent Aggregator ....... SUCCESS [3.995s]
[INFO] JBoss Application Server: Domain HTTP Interface ... SUCCESS [0.489s]
[INFO] JBoss Application Server: Domain HTTP Error Context SUCCESS [1.221s]
[INFO] JBoss Application Server: Protocol Utilities ...... SUCCESS [16.296s]
[INFO] JBoss Application Server: Controller Client ....... SUCCESS [6.760s]
[INFO] JBoss Application Server: Controller Core ......... SUCCESS [34.584s]
[INFO] JBoss Application Server: Domain Management ....... SUCCESS [9.313s]
[INFO] JBoss Application Server: Domain HTTP Interface ... SUCCESS [4.387s]
[INFO] JBoss Application Server: Deployment Repository ... SUCCESS [2.613s]
[INFO] JBoss Application Server: Embedded ................ SUCCESS [4.223s]
[INFO] JBoss Application Server: Platform MBean integration SUCCESS [7.483s]
[INFO] JBoss Application Server: Process Controller ...... SUCCESS [8.123s]
[INFO] JBoss Application Server: Network ................. SUCCESS [3.813s]
[INFO] JBoss Application Server: Threading Subsystem ..... SUCCESS [9.255s]
[INFO] JBoss Application Server: Remoting Subsystem ...... SUCCESS [6.682s]
[INFO] JBoss Application Server: Server .................. SUCCESS [13.660s]
[INFO] JBoss Application Server: Subsystem Test Harness .. SUCCESS [10.409s]
[INFO] JBoss Application Server: JMX Subsystem ........... SUCCESS [20.399s]
[INFO] JBoss Application Server: Naming Subsystem ........ SUCCESS [14.218s]
[INFO] JBoss Application Server: EE ...................... SUCCESS [12.185s]
[INFO] JBoss Application Server: JacORB Subsystem ........ SUCCESS [15.345s]
[INFO] JBoss Application Server: Transaction Subsystem ... SUCCESS [8.479s]
[INFO] JBoss Application Server: Clustering Subsystem .... SUCCESS [0.556s]
[INFO] JBoss Application Server: Clustering Server API ... SUCCESS [12.608s]
[INFO] JBoss Application Server: Common code for clustering subsystems SUCCESS [4.843s]
[INFO] JBoss Application Server: JGroups Subsystem ....... SUCCESS [10.601s]
[INFO] JBoss Application Server: Infinispan Subsystem .... SUCCESS [51.163s]
[INFO] JBoss Application Server: Security Subsystem ...... SUCCESS [12.758s]
[INFO] JBoss Application Server: Connector Subsystem ..... SUCCESS [18.078s]
[INFO] JBoss Application Server: Clustered registry service SUCCESS [2.245s]
[INFO] JBoss Application Server: EJB Subsystem ........... SUCCESS [28.523s]
[INFO] JBoss Application Server: Distributed Web Session SPI SUCCESS [4.554s]
[INFO] JBoss Application Server: Clustering Server API implementation SUCCESS [4.214s]
[INFO] JBoss Application Server: Distributed Web Session Infinispan provider SUCCESS [6.819s]
[INFO] JBoss Application Server: Web Subsystem ........... SUCCESS [30.214s]
[INFO] JBoss Application Server: Web Services Subsystem .. SUCCESS [0.335s]
[INFO] JBoss Application Server: Web Services Server Integration Subsystem SUCCESS [13.614s]
[INFO] JBoss Application Server: Application Client Bootstrap SUCCESS [5.473s]
[INFO] JBoss Application Server: Config Assembly ......... SUCCESS [3.872s]
[INFO] JBoss Application Server: Command line interface .. SUCCESS [15.465s]
[INFO] JBoss Application Server: EJB Client BOM .......... SUCCESS [0.347s]
[INFO] JBoss Application Server: JMS Client BOM .......... SUCCESS [0.363s]
[INFO] JBoss Application Server: EJB and JMS client combined jar SUCCESS [4.036s]
[INFO] JBoss Application Server: Clustered Stateful Session Bean cache Infinispan provider SUCCESS [5.589s]
[INFO] JBoss Application Server: Clustered service provider registry services SUCCESS [4.567s]
[INFO] JBoss Application Server: Clustered singleton services SUCCESS [5.565s]
[INFO] JBoss Application Server: EJB Container Managed Persistence Subsystem SUCCESS [22.352s]
[INFO] JBoss Application Server: Config Admin ............ SUCCESS [7.520s]
[INFO] JBoss Application Server: Deployment Scanner ...... SUCCESS [8.324s]
[INFO] JBoss Application Server: EE Deployment ........... SUCCESS [3.872s]
[INFO] JBoss Application Server: JAXR Client ............. SUCCESS [7.860s]
[INFO] JBoss Application Server: JPA Subsystem ........... SUCCESS [0.355s]
[INFO] JBoss Application Server: JPA SPI ................. SUCCESS [7.849s]
[INFO] JBoss Application Server: JPA UTIL ................ SUCCESS [2.121s]
[INFO] JBoss Application Server: JPA Subsystem ........... SUCCESS [10.120s]
[INFO] JBoss Application Server: Weld Integration ........ SUCCESS [11.428s]
[INFO] JBoss Application Server: JAX-RS Integration ...... SUCCESS [6.956s]
[INFO] JBoss Application Server: JBoss Diagnostic Reporter SUCCESS [0.241s]
[INFO] JBoss Application Server: JDR ..................... SUCCESS [6.573s]
[INFO] JBoss Application Server: JSF Integration ......... SUCCESS [8.797s]
[INFO] JBoss Application Server: JSR-77 Subsystem ........ SUCCESS [12.349s]
[INFO] JBoss Application Server: Management Client Content SUCCESS [2.597s]
[INFO] JBoss Application Server: Host Controller ......... SUCCESS [15.386s]
[INFO] JBoss Application Server: Logging Subsystem ....... SUCCESS [11.678s]
[INFO] JBoss Application Server: Mail subsystem .......... SUCCESS [7.577s]
[INFO] JBoss Application Server: Messaging Subsystem ..... SUCCESS [17.806s]
[INFO] JBoss Application Server: ModCluster Subsystem .... SUCCESS [7.200s]
[INFO] JBoss Application Server: OSGi .................... SUCCESS [0.193s]
[INFO] JBoss Application Server: OSGi Subsystem .......... SUCCESS [8.694s]
[INFO] JBoss Application Server: OSGi ConfigurationAdmin . SUCCESS [4.241s]
[INFO] JBoss Application Server: OSGi Integration ........ SUCCESS [4.834s]
[INFO] JBoss Application Server: POJO Subsystem .......... SUCCESS [7.541s]
[INFO] JBoss Application Server: Service Archive Subsystem SUCCESS [5.899s]
[INFO] JBoss Application Server: sosreport scripts ....... SUCCESS [1.581s]
[INFO] JBoss Application Server: System JMX Module ....... SUCCESS [1.906s]
[INFO] JBoss Application Server: XTS Subsystem ........... SUCCESS [6.543s]
[INFO] JBoss Application Server: Hibernate 3.6.x JPA integration SUCCESS [7.047s]
[INFO] JBoss Application Server: Hibernate 4.0.x JPA integration SUCCESS [6.806s]
[INFO] JBoss Application Server: OpenJPA 2.x JPA integration SUCCESS [4.883s]
[INFO] JBoss Application Server: Build ................... SUCCESS [1:30.314s]
[INFO] JBoss Application Server: Arquillian .............. SUCCESS [0.100s]
[INFO] JBoss Application Server: Arquillian TestEnricher MSC SUCCESS [2.206s]
[INFO] JBoss Application Server: Arquillian Common ....... SUCCESS [3.336s]
[INFO] JBoss Application Server: Arquillian Protocol JMX . SUCCESS [2.953s]
[INFO] JBoss Application Server: Arquillian Managed Container SUCCESS [24.870s]
[INFO] JBoss Application Server: Arquillian Remote Container SUCCESS [3.085s]
[INFO] JBoss Application Server: Exported Java EE Specification APIs SUCCESS [0.139s]
[INFO] JBoss Application Server: Arquillian TestNG Integration SUCCESS [24.279s]
[INFO] JBoss Application Server: Arquillian Common Domain SUCCESS [3.455s]
[INFO] JBoss Application Server: Arquillian Remote Domain Container SUCCESS [2.544s]
[INFO] JBoss Application Server: Arquillian Managed Domain Container SUCCESS [36.966s]
[INFO] JBoss Application Server: Distribution ............ SUCCESS [8.383s]
[INFO] JBoss Application Server: Remoting Subsystem Test . SUCCESS [4.219s]
[INFO] JBoss Application Server: Validation Tests for Exported Java EE Specification APIs SUCCESS [1.708s]
[INFO] JBoss Application Server: Web Services Tests Integration Subsystem SUCCESS [2.720s]
[INFO] JBoss Application Server Test Suite: Shared ....... SUCCESS [12.258s]
[INFO] JBoss Application Server Test Suite: Aggregator ... SUCCESS [18.736s]
[INFO] JBoss Application Server Test Suite: Integration .. SUCCESS [3.141s]
[INFO] JBoss Application Server Test Suite: Integration - Smoke SUCCESS [2:41.769s]
[INFO] JBoss Application Server Test Suite: Integration - Basic SUCCESS [13:50.254s]
[INFO] JBoss Application Server Test Suite: Integration - Clustering SUCCESS [11:21.185s]
[INFO] JBoss Application Server Test Suite: Integration - IIOP SUCCESS [41.128s]
[INFO] JBoss Application Server Test Suite: Integration - XTS SUCCESS [37.895s]
[INFO] JBoss Application Server Test Suite: Integration - Multinode Tests SUCCESS [40.648s]
[INFO] JBoss Application Server Test Suite: Integration - Manual Mode Tests FAILURE [6:58.296s]
[INFO] JBoss Application Server Test Suite: Compatibility Tests SUCCESS [50.255s]
[INFO] JBoss Application Server Test Suite: Domain Mode Integration Tests SUCCESS [3:42.238s]
[INFO] JBoss Application Server Test Suite: Benchmark Tests SUCCESS [20.661s]
[INFO] JBoss Application Server Test Suite: Stress Tests . SUCCESS [3.023s]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 57:54.572s
[INFO] Finished at: Fri Aug 31 02:39:07 EDT 2012
[INFO] Final Memory: 230M/455M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:2.11:test (manualmode.surefire) on project jboss-as-ts-integ-manualmode: There are test failures.
[ERROR]
[ERROR] Please refer to <http://lightning.mw.lab.eng.bos.redhat.com/jenkins/job/as7-master-testsui...> for the individual test results.
[ERROR] -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
[ERROR]
[ERROR] After correcting the problems, you can resume the build with the command
[ERROR] mvn <goals> -rf :jboss-as-ts-integ-manualmode
Build step 'Execute shell' marked build as failure
Recording test results
13 years, 10 months
