[JBoss JIRA] (AS7-6104) jboss-cli failed to remove PostgreSQL datasource module NullPointerException OperationContextImpl.doRemove()
by Raymond Naseef (JIRA)
Raymond Naseef created AS7-6104:
-----------------------------------
Summary: jboss-cli failed to remove PostgreSQL datasource module NullPointerException OperationContextImpl.doRemove()
Key: AS7-6104
URL: https://issues.jboss.org/browse/AS7-6104
Project: Application Server 7
Issue Type: Bug
Components: Server
Affects Versions: 7.1.1.Final
Environment: Windows 7 Professional SP1
Reporter: Raymond Naseef
Assignee: Jason Greene
NullPointerException during jboss-cli remove with commands:
jboss-cli --connect command="/subsystem=datasources/jdbc-driver=postgresql-driver:add(driver-name=postgresql-driver, driver-class-name=org.postgresql.Driver, driver-module-name=org.postgresql"
* this works
jboss-cli --connect command="/subsystem=datasources/jdbc-driver=postgresql-driver:remove"
MS-DOS Console:
{
"outcome" => "failed",
"failure-description" => "JBAS014749: Operation handler failed: null",
"rolled-back" => true
}
Server Log:
23:17:42,627 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 19) JBAS014612: Operation ("remove") failed - address: ([
("subsystem" => "datasources"),
("jdbc-driver" => "postgresql-driver")
]): java.lang.NullPointerException
at org.jboss.as.controller.OperationContextImpl.doRemove(OperationContextImpl.java:298) [jboss-as-controller-7.1.1.Final.jar:7.1.1.Final]
at org.jboss.as.controller.OperationContextImpl.removeService(OperationContextImpl.java:293) [jboss-as-controller-7.1.1.Final.jar:7.1.1.Final]
at org.jboss.as.connector.subsystems.datasources.JdbcDriverRemove.performRuntime(JdbcDriverRemove.java:66)
at org.jboss.as.controller.AbstractRemoveStepHandler$1.execute(AbstractRemoveStepHandler.java:50) [jboss-as-controller-7.1.1.Final.jar:7.1.1.Final]
at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:385) [jboss-as-controller-7.1.1.Final.jar:7.1.1.Final]
at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:272) [jboss-as-controller-7.1.1.Final.jar:7.1.1.Final]
at org.jboss.as.controller.AbstractOperationContext.completeStep(AbstractOperationContext.java:200) [jboss-as-controller-7.1.1.Final.jar:7.1.1.Final]
at org.jboss.as.controller.ModelControllerImpl$DefaultPrepareStepHandler.execute(ModelControllerImpl.java:466) [jboss-as-controller-7.1.1.Final.jar:7.1.1.Final]
at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:385) [jboss-as-controller-7.1.1.Final.jar:7.1.1.Final]
at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:272) [jboss-as-controller-7.1.1.Final.jar:7.1.1.Final]
at org.jboss.as.controller.AbstractOperationContext.completeStep(AbstractOperationContext.java:200) [jboss-as-controller-7.1.1.Final.jar:7.1.1.Final]
at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:121) [jboss-as-controller-7.1.1.Final.jar:7.1.1.Final]
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:139) [jboss-as-controller-7.1.1.Final.jar:7.1.1.Final]
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:108) [jboss-as-controller-7.1.1.Final.jar:7.1.1.Final]
at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:287) [jboss-as-protocol-7.1.1.Final.jar:7.1.1.Final]
at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:487) [jboss-as-protocol-7.1.1.Final.jar:7.1.1.Final]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [rt.jar:1.7.0]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [rt.jar:1.7.0]
at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0]
at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.0.0.GA.jar:2.0.0.GA]
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 5 months
[JBoss JIRA] (AS7-5995) After deploy an application with a wrong module slot dependency the module loader does not recover
by Chao Wang (JIRA)
[ https://issues.jboss.org/browse/AS7-5995?page=com.atlassian.jira.plugin.s... ]
Chao Wang commented on AS7-5995:
--------------------------------
There is already an unload operation for modules in org.jboss.as.server.moduleservice.ServiceModuleLoader.ModuleSpecLoadListener.
but there is a bug as described in issue AS7-6103
> After deploy an application with a wrong module slot dependency the module loader does not recover
> --------------------------------------------------------------------------------------------------
>
> Key: AS7-5995
> URL: https://issues.jboss.org/browse/AS7-5995
> Project: Application Server 7
> Issue Type: Bug
> Affects Versions: 7.2.0.Alpha1
> Environment: Tested with 7.2. upstream
> commit ed2bc551a55ec6a8167a8657cbb5d8abc6e07748
> Date: Thu Nov 15 10:15:22 2012 +0100
> standalone mode, no difference whether CLI or file-system scanner
> Reporter: Wolf-Dieter Fink
> Assignee: Chao Wang
> Labels: dependency, modules
> Attachments: server.log, server.log
>
>
> If an application is deployed with a dependency and specify a slot in jboss-deployment-structure.xml:
> <module name="wfink.tools.performance" slot="1.0" export="true"/>
> the module loader will not correct load a new deployment after failing with 'JBAS018759' Caused by: org.jboss.modules.ModuleNotFoundException: Module wfink.tools.performance:1.1 is not found in local module loader.
> If after such message the application.ear contain a correct slot, or even no slot entry, the module loader fail with the message above. The slot number is the same as of the failed deployment.
> If the server is restarted the application deploy succeeds.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 5 months
[JBoss JIRA] (AS7-6103) ServiceModuleLoader can't properly unload module if it failed to load module due to wrong dependency
by Chao Wang (JIRA)
Chao Wang created AS7-6103:
------------------------------
Summary: ServiceModuleLoader can't properly unload module if it failed to load module due to wrong dependency
Key: AS7-6103
URL: https://issues.jboss.org/browse/AS7-6103
Project: Application Server 7
Issue Type: Bug
Components: Server
Affects Versions: 7.2.0.Alpha1
Reporter: Chao Wang
Priority: Critical
ServiceModuleLoader can't properly unload module if it failed to load module due to wrong dependency.
The codes below take care of unload operation.
{code:title=org.jboss.as.server.moduleservice.ServiceModuleLoader.java|borderStyle=solid}
case STOP_REQUESTED_to_STOPPING: {
log.tracef("serviceStopping: %s", controller);
ModuleSpec moduleSpec = this.moduleSpec;
try {
*Module module = loadModule(moduleSpec.getModuleIdentifier());*
*unloadModuleLocal(module);*
} catch (ModuleLoadException e) {
// ignore, the module should always be already loaded by this point,
// and if not we will only mask the true problem
}
// TODO: what if the service is restarted?
controller.removeListener(this);
break;
}
{code}
The line *unloadModuleLocal(module)* can not be reached because the previous loadModule(moduleSpec.getModuleIdentifier() will throw ModuleLoadException if module has dependency problem.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 5 months
[JBoss JIRA] (AS7-5449) when defining custom executor for connector thread priority is not optional
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/AS7-5449?page=com.atlassian.jira.plugin.s... ]
Brian Stansberry updated AS7-5449:
----------------------------------
Component/s: Domain Management
> when defining custom executor for connector thread priority is not optional
> ---------------------------------------------------------------------------
>
> Key: AS7-5449
> URL: https://issues.jboss.org/browse/AS7-5449
> Project: Application Server 7
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 7.1.2.Final (EAP)
> Reporter: Mathieu Lachance
> Assignee: Bartosz Baranowski
> Fix For: 7.2.0.Alpha1, 7.1.4.Final (EAP)
>
>
> when defining a custom executor in the threads subsystem for the connector defined in the web subsystem like :
> {code:xml}
> <subsystem xmlns="urn:jboss:domain:threads:1.1">
> <thread-factory name="ConnectorThreadFactory" group-name="ConnectorThreadPool"/>
> <unbounded-queue-thread-pool name="ConnectorThreadPool">
> <max-threads count="500"/>
> <keepalive-time time="60" unit="seconds"/>
> <thread-factory name="ConnectorThreadFactory"/>
> </unbounded-queue-thread-pool>
> </subsystem>
> <subsystem xmlns="urn:jboss:domain:web:1.1" default-virtual-server="default-host" native="false">
> <connector name="ajp" protocol="AJP/1.3" scheme="http" socket-binding="ajp" redirect-port="8443" executor="ConnectorThreadPool"/>
> </subsystem>
> {code}
> it will fail with :
> {quote}
> 17:19:06,508 ERROR [org.apache.tomcat.util.net.JIoEndpoint] (http-/0.0.0.0:8443-Acceptor-0) Error allocating socket processor: java.lang.IllegalArgumentException
> at java.lang.Thread.setPriority(Thread.java:1058) [rt.jar:1.6.0_31]
> at org.jboss.threads.JBossThreadFactory.createThread(JBossThreadFactory.java:127) [jboss-threads-2.0.0.GA.jar:2.0.0.GA]
> at org.jboss.threads.JBossThreadFactory.newThread(JBossThreadFactory.java:101) [jboss-threads-2.0.0.GA.jar:2.0.0.GA]
> at java.util.concurrent.ThreadPoolExecutor.addThread(ThreadPoolExecutor.java:672) [rt.jar:1.6.0_31]
> at java.util.concurrent.ThreadPoolExecutor.addIfUnderCorePoolSize(ThreadPoolExecutor.java:697) [rt.jar:1.6.0_31]
> at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:652) [rt.jar:1.6.0_31]
> at org.jboss.threads.JBossThreadPoolExecutor.execute(JBossThreadPoolExecutor.java:63) [jboss-threads-2.0.0.GA.jar:2.0.0.GA]
> at org.jboss.threads.DelegatingBlockingExecutorService.execute(DelegatingBlockingExecutorService.java:42) [jboss-threads-2.0.0.GA.jar:2.0.0.GA]
> at org.jboss.as.threads.ManagedExecutorService.execute(ManagedExecutorService.java:64) [jboss-as-threads-7.1.2.Final.jar:7.1.2.Final]
> at org.apache.tomcat.util.net.JIoEndpoint.processSocket(JIoEndpoint.java:1237) [jbossweb-7.0.16.Final.jar:]
> at org.apache.tomcat.util.net.JIoEndpoint$Acceptor.run(JIoEndpoint.java:325) [jbossweb-7.0.16.Final.jar:]
> at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_31]
> {quote}
> even though if documentation state that thread priority is optional :
> {code:xml}
> <xs:complexType name="thread-factory">
> <xs:annotation>
> <xs:documentation>
> <![CDATA[
> A thread factory (implementing java.util.concurrent.ThreadFactory). The "name" attribute is
> the bean name of the created thread factory. The optional "priority" attribute may be used to specify
> the thread priority of created threads. The optional "group-name" attribute specifies the name of a the
> thread group to create for this thread factory.
> The "thread-name-pattern" is the template used to create names for threads. The following patterns
> may be used:
> %% - emit a percent sign
> %t - emit the per-factory thread sequence number
> %g - emit the global thread sequence number
> %f - emit the factory sequence number
> %i - emit the thread ID
> %G - emit the thread group name
> ]]>
> </xs:documentation>
> </xs:annotation>
> <xs:attribute name="name" type="xs:string" use="required"/>
> <xs:attribute name="group-name" type="xs:string" use="optional"/>
> <xs:attribute name="thread-name-pattern" type="xs:string" use="optional"/>
> <xs:attribute name="priority" type="priority" use="optional"/>
> </xs:complexType>
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 5 months
[JBoss JIRA] (AS7-430) DomainController discovery system
by Farah Juma (JIRA)
[ https://issues.jboss.org/browse/AS7-430?page=com.atlassian.jira.plugin.sy... ]
Farah Juma commented on AS7-430:
--------------------------------
Created a pull request: https://github.com/jbossas/jboss-as/pull/3593
This allows a slave host controller to discover a master domain controller via S3. In particular, both the slave and the master can be configured with information needed to access an S3 bucket (sample configuration is shown below). When a master domain controller is started, if it has been configured to allow S3 discovery, it will write its address and port to an S3 file (jboss-domain-master-data) in the given bucket. There are now 2 remote domain controller discovery options for a slave host controller:
1. static discovery, i.e., statically configure the remote domain controller's host and port, exactly as before
2. S3 discovery, i.e., provide the <S3-discovery> configuration shown below
When a slave uses S3 discovery, it gets the remote domain controller's address and port from an S3 file in the given bucket. A slave must be configured with at least one of the two discovery options. Whenever a slave needs to connect to the master, it will now loop through all provided discovery options. (Note that when both discovery options are provided, static discovery will be attempted first. If this fails, then S3 discovery will be attempted next.)
Sample Configuration -
An optional <discovery-options> element can now be added to <remote> for a slave host controller and to <local> for the master domain controller, as follows:
Slave host controller (note: this example configures both static and S3 discovery):
{code:xml}
<remote host="${jboss.domain.master.address}" port="${jboss.domain.master.port:9999}" security-realm="ManagementRealm">
<discovery-options>
<S3-discovery>
<access-key value="s3_access_key"/>
<secret-access-key value="s3_secret_access_key"/>
<location value="s3_bucket_name"/>
</S3-discovery>
</discovery-options>
</remote>
{code}
Master domain controller:
{code:xml}
<local>
<discovery-options>
<S3-discovery>
<access-key value="s3_access_key"/>
<secret-access-key value="s3_secret_access_key"/>
<location value="s3_bucket_name"/>
</S3-discovery>
</discovery-options>
</local>
{code}
Note that right now, the only child the <discovery-options> element can have is <S3-discovery>. However, the way the discovery system has been implemented should allow other discovery options to easily be added in the future as well.
> DomainController discovery system
> ---------------------------------
>
> Key: AS7-430
> URL: https://issues.jboss.org/browse/AS7-430
> Project: Application Server 7
> Issue Type: Task
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Farah Juma
> Fix For: 7.2.0.CR1
>
>
> Mechanism(s) by which a Host Controller finds a Domain Controller so it can begin the process of integrating into the domain.
> Task includes the host.xml schema elements to configure this, the domain object model classes behind those elements, and the actual implementation of discovery from both the ServerManager and DomainController sides.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 5 months
[JBoss JIRA] (AS7-4388) Provide clustering management use cases
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/AS7-4388?page=com.atlassian.jira.plugin.s... ]
Richard Achmatowicz commented on AS7-4388:
------------------------------------------
Bela, thanks for the feedback!
Paul also suggested creation of a separate subsystem. It does have its advantages: re-enforces that the JGroups and Infinispan subsystems represent local resources only and to see the global (different) view you need to look in a different place; allows those subsystems to stay relatively uncomplicated; can be optionally included in a profile). This would probably be a more intuitive presentation of cluster information as far as the user is concerned.
As for probe, I did review all of its features (keys). Because it allows destructive operations (e.g. invoke an arbitrary operation on a protocol layer), I think we need to wait until we have some security mechanisms in place (AS8) before using it generally. But that probably does not prevent us from presenting a subset of keys for use. These could be presented as operations under /subsystem=cluster/name=session-cluster/channel=*. Also, it seems to require receiving commands by multicast, so will there not be a problem with TCP stacks? Perhaps make it available if the stack is UDP and mcast-enabled only?
> Provide clustering management use cases
> ---------------------------------------
>
> Key: AS7-4388
> URL: https://issues.jboss.org/browse/AS7-4388
> Project: Application Server 7
> Issue Type: Task
> Components: Console
> Reporter: Heiko Braun
> Assignee: Bela Ban
> Fix For: 7.2.0.CR1
>
>
> In order to prep the UI, we would need a list of typical clustering management use cases.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 5 months