Undeploy due to server shutdown vs. explicit undeploy operation
by Thomas Diesler
Folks,
an explicit undeploy operation should remove state that otherwise needs
to survive server restart.
How can I distinguish between these two cases in a DUP?
cheers
--thomas
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
JBoss OSGi Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
11 years
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
11 years
Web Service Failures
by Stuart Douglas
It appears that all the recent web service CI failures are caused by a
JDK bug. I have filed a bug report with oracle the following details,
although it has not been confirmed and issued a bug ID yet:
Stuart
-------
The method sun.net.www.http.HttpClient#available() can throw
java.net.SocketException, which can cause the creation of the HttpClient
to fail. This will happen if there is a connection in the cache that has
timed out and the socket has been closed.
This method was added in a recent commit:
http://hg.openjdk.java.net/jdk7u/jdk7u/jdk/diff/e6dc1d9bc70b/src/share/cl...
The exception is:
Caused by: java.net.SocketException: Socket Closed
at java.net.PlainSocketImpl.getOption(PlainSocketImpl.java:286)
[rt.jar:1.6.0_38]
at java.net.Socket.getSoTimeout(Socket.java:1032) [rt.jar:1.6.0_38]
at sun.net.www.http.HttpClient.available(HttpClient.java:356)
[rt.jar:1.6.0_38]
at sun.net.www.http.HttpClient.New(HttpClient.java:273)
[rt.jar:1.6.0_38]
at sun.net.www.http.HttpClient.New(HttpClient.java:310)
[rt.jar:1.6.0_38]
at
sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnection.java:987)
[rt.jar:1.6.0_38]
at
sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:923)
[rt.jar:1.6.0_38]
at
sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:841)
[rt.jar:1.6.0_38]
at
sun.net.www.protocol.http.HttpURLConnection.getOutputStream(HttpURLConnection.java:1031)
[rt.jar:1.6.0_38]
at
org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleHeadersTrustCaching(HTTPConduit.java:1410)
The getSoTimeout() call should probably be in a try/catch block.
It appears that other people have also run into this:
http://stackoverflow.com/questions/14270311/rather-mysterious-socketexcep...
11 years, 2 months
AS7-2267 - Console Logging DMR Commands
by Jess Sightler
I'd like to take a stab at this issue, however, I have a couple of questions first:
1. The JIRA describes this as "logging DMR commands", however, I do not believe that the DMR commands would apply directly within the CLI. I believe that the syntaxes are different.
- Is this assumption correct?
- Do we have a preexisting class to convert from the ModelNode operation to a CLI command? If not, nothing immediately jumps out at me that would make this extremely hard, but I don't want to duplicate existing work.
2. I don't necessarily agree with the proposed approach in the JIRA. I think it may be easier to append this information to the status result after an operation has completed. For example, after the user saves a property, a "Save successful" message appears. I believe this is clickable to show details, and we could display the CLI commands to rerun the action within that dialog.
Is that an acceptable way to accomplish this task? Or is there some other preferred approach to implementing this in the UI?
Thanks,
--
Jess Sightler
11 years, 2 months
Transformers rejection testing PRs
by Kabir Khan
I just pushed some improvements to ModelTestUtils.checkFailedTransformedBootOperations() which tightens up the checks that the transformers actually reject ops which should not make it to the legacy slave. In some cases these were just sent across to the legacy slave controller and failing there, so it was hard to know if ops were being rejected or simply failed. I reworked the affected subsystems.
Some of you have PRs open using transformers, so please rebase those and fix any problems in the tests. If you have any problems let me know and I'll help.
---------------------------------------
Kabir Khan
Prinicipal Software Engineer
JBoss by Red Hat
11 years, 3 months
All Enterprise OSGi TCKs dependent on PR #3720
by Thomas Diesler
Hi Jason/Reviewers,
FYI - there is a dependency on PR #3720 for all Enterprise OSGi TCKs.
cheers
--thomas
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
JBoss OSGi Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
11 years, 3 months
ServiceContainer dies unexpextedly
by Thomas Diesler
Folks,
with the embedded server I see the ServiceContainer shutting down unexpectedly while activating the OSGi subsystem. This happens repeatedly (but not always) on lighting.
Any idea what could be the possible cause or in what direction to look?
cheers
--thomas
02:13:37,309 INFO [org.jboss.as] (Controller Boot Thread) JBAS015951: Admin console listening on http://127.0.0.1:9990
02:13:37,312 INFO [org.jboss.osgi.framework] (MSC service thread 1-1) JBOSGI011006: OSGi Framework - 2.1.0.CR10
02:13:37,313 INFO [org.jboss.as] (Controller Boot Thread) JBAS015874: JBoss AS 7.2.0.Alpha1-SNAPSHOT "Steropes" started in 4866ms - Started 125 of 207 services (81 services are passive or on-demand)
02:13:38,233 INFO [org.jboss.osgi.framework] (MSC service thread 1-4) JBOSGI011001: Bundle installed: jboss-as-osgi-configadmin:7.2.0.Alpha1-SNAPSHOT
02:13:38,241 INFO [org.jboss.osgi.framework] (MSC service thread 1-2) JBOSGI011001: Bundle installed: jboss-osgi-logging:1.0.0
02:13:38,232 INFO [org.jboss.osgi.framework] (MSC service thread 1-1) JBOSGI011001: Bundle installed: org.apache.felix.log:1.0.0
02:13:38,253 INFO [org.jboss.osgi.framework] (MSC service thread 1-6) JBOSGI011001: Bundle installed: org.apache.felix.configadmin:1.2.8
02:13:38,319 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-6) MSC00001: Failed to start service jbosgi.bundle."org.apache.felix.configadmin"."1.2.8".bid13.INSTALLED: org.jboss.msc.service.StartException in service jbosgi.bundle."org.apache.felix.configadmin"."1.2.8".bid13.INSTALLED: Failed to start service
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1767)
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:662)
Caused by: java.lang.IllegalStateException: Container is down
at org.jboss.msc.service.ServiceContainerImpl.install(ServiceContainerImpl.java:508)
at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:201)
at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2228)
at org.jboss.msc.service.ServiceBuilderImpl.install(ServiceBuilderImpl.java:307)
at org.jboss.osgi.framework.spi.AbstractIntegrationService.install(AbstractIntegrationService.java:52)
at org.jboss.osgi.framework.spi.BootstrapBundlesService.install(BootstrapBundlesService.java:52)
at org.jboss.as.osgi.service.BootstrapBundlesIntegration.installResolveService(BootstrapBundlesIntegration.java:171)
at org.jboss.osgi.framework.spi.BootstrapBundlesInstall$1.complete(BootstrapBundlesInstall.java:96)
at org.jboss.osgi.framework.spi.ServiceTracker.completeInternal(ServiceTracker.java:284)
at org.jboss.osgi.framework.spi.ServiceTracker.checkAndComplete(ServiceTracker.java:157)
at org.jboss.osgi.framework.spi.ServiceTracker.serviceCompleteInternal(ServiceTracker.java:276)
at org.jboss.osgi.framework.spi.ServiceTracker.synchronousListenerServiceStarted(ServiceTracker.java:141)
at org.jboss.osgi.framework.spi.ServiceTracker$SynchronousListenerServiceWrapper.startCompleted(ServiceTracker.java:350)
at org.jboss.osgi.framework.spi.ServiceTracker$SynchronousListenerServiceWrapper.start(ServiceTracker.java:331)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746)
... 3 more
02:13:38,417 INFO [org.apache.coyote.http11] (MSC service thread 1-5) JBWEB003075: Coyote HTTP/1.1 pausing on: http-/127.0.0.1:8080
02:13:38,350 INFO [org.jboss.osgi.framework] (MSC service thread 1-1) JBOSGI011005: Bundle uninstalled: jboss-as-osgi-configadmin:7.2.0.Alpha1-SNAPSHOT
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
JBoss OSGi Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
11 years, 3 months
