[JBoss JIRA] (JBAS-9578) Enabling/Disabling a Datasource prompts for server restart
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/JBAS-9578?page=com.atlassian.jira.plugin.... ]
Steven Hawkins moved TEIID-4190 to JBAS-9578:
---------------------------------------------
Project: Application Server 3 4 5 and 6 (was: Teiid)
Key: JBAS-9578 (was: TEIID-4190)
> Enabling/Disabling a Datasource prompts for server restart
> ----------------------------------------------------------
>
> Key: JBAS-9578
> URL: https://issues.jboss.org/browse/JBAS-9578
> Project: Application Server 3 4 5 and 6
> Issue Type: Bug
> Environment: Red Hat JBoss Data Virtualization 6.2.4 on EAP patched to version 6.4.6, on Oracle Linux 6
> JBoss Developer Studio 8.1.0GA with Teiid Designer 9.0.6.Final-v20160316-1409-B1242 org.teiid.designer.feature.feature.group JBoss by Red Hat, Inc.
> 64-bit Windows 7 environment
> Reporter: Steve Tran
> Assignee: Steven Hawkins
> Attachments: Capture.PNG
>
>
> When I enable or disable a Datasource in EAP (tested only in domain mode), I get a message that prompts me to restart my server because configurations have changed. This is a new warning because it didn't do this in earlier version of EAP6.4. If I go to the topology screen, none of the servers are marked with the symbol that says it needs to be restarted. If I drill down into the specific node and server, the Datasource was marked as disabled in the UI, so I think it did actually turned off the Datasource correctly.
> I think the prompt is wrong, and should be removed. Also, this might be an EAP bug and not JDV related.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 2 months
[JBoss JIRA] (WFLY-6083) Removing of non-existent login-module finishes with outcome success
by Chao Wang (JIRA)
[ https://issues.jboss.org/browse/WFLY-6083?page=com.atlassian.jira.plugin.... ]
Chao Wang commented on WFLY-6083:
---------------------------------
Hi [~brian.stansberry] if you don't mind, I 'll close this as duplicate of WFCORE-1523
> Removing of non-existent login-module finishes with outcome success
> -------------------------------------------------------------------
>
> Key: WFLY-6083
> URL: https://issues.jboss.org/browse/WFLY-6083
> Project: WildFly
> Issue Type: Bug
> Components: Domain Management, Security
> Affects Versions: 10.0.0.Final
> Reporter: Ondrej Lukas
> Assignee: Brian Stansberry
> Priority: Minor
>
> In case when non-existent login-module is removed through Management CLI, opertation should finish with failure. However it finishes with outcome success and nothing is changed. It can be confusing since wrong command seems same as correct command.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 2 months
[JBoss JIRA] (JBJCA-1318) list driven ExceptionSorter, StaleConnectionChecker
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JBJCA-1318?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on JBJCA-1318:
------------------------------------------------
Jiří Bílek <jbilek(a)redhat.com> changed the Status of [bug 1320720|https://bugzilla.redhat.com/show_bug.cgi?id=1320720] from ON_QA to VERIFIED
> list driven ExceptionSorter, StaleConnectionChecker
> ---------------------------------------------------
>
> Key: JBJCA-1318
> URL: https://issues.jboss.org/browse/JBJCA-1318
> Project: IronJacamar
> Issue Type: Task
> Components: JDBC
> Reporter: Johnathon Lee
> Assignee: Johnathon Lee
> Priority: Minor
> Fix For: WildFly/IronJacamar 1.3.4.Final, 1.0.37.Final, 1.2.8.Final
>
>
> Configuration defined ExceptionSorter, StaleConnectionChecker.
> Using an externally (from the implementation) defined "," separated list.
> Defined via '<config-property name=prop_name >value1,value2,value3</>' in the standalone/domain configuration files.
> ie:
> set via <config-property name="FatalExceptions">10099,10100,10101</>
> set via <config-property name="StaleExceptions">10099,10100,10101</>
> Documentation updated to reflect suggested error codes for vendor based upon the current implementations.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 2 months
[JBoss JIRA] (WFLY-6592) NPE thrown during application redeployment, slaves taken offline
by Matthew Casperson (JIRA)
[ https://issues.jboss.org/browse/WFLY-6592?page=com.atlassian.jira.plugin.... ]
Matthew Casperson commented on WFLY-6592:
-----------------------------------------
Thinking about this error, I suspect this is what happens to cause it:
1. We deploy an app to a domain controller with 2 slaves
2. The deployment on one slave fails because of memory issues (not a wildfly bug, more of a regular "os doesn't have swap memory and we assigned to much to java" issue)
3. At this point the deployment of the app is rolled back, but the server that didn't run out of memory doesn't have anything to roll back, causing the NPE.
I haven't tested this theory yet, but it could be more than a coincidence.
> NPE thrown during application redeployment, slaves taken offline
> ----------------------------------------------------------------
>
> Key: WFLY-6592
> URL: https://issues.jboss.org/browse/WFLY-6592
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 10.0.0.Final
> Reporter: Matthew Casperson
> Assignee: Jason Greene
>
> We have some development Wildfly 10.0.0 servers running as slaves in a domain that frequently have WAR files redeployed. We have noticed that these slaves will often go offline after a redeployment of WAR files with the following stack trace:
> {code}
> 2016-05-06 05:05:51,306 ERROR [org.jboss.as.controller.management-operation] (Host Controller Service Threads - 1012) WFLYCTL0190: Step handler org.jboss.as.domain.controller.operations.deployment.DeploymentFullReplaceHandler@3f68226b for operation {"operation" => "full-replace-deployment","name" => "whatever.war","enabled" => true,"content" => [{"hash" => bytes { 0x5d, 0x12, 0x18, 0x2b, 0x1c, 0x86, 0x71, 0x27, 0x08, 0x3d, 0xf1, 0x75, 0x08, 0x29, 0xa6, 0x49, 0x1f, 0x16, 0xe8, 0x22 }}],"operation-headers" => {"access-mechanism" => "NATIVE","domain-uuid" => "802ab616-dd2c-4081-a79c-c4d54e14c384","push-to-servers" => undefined},"address" => [],"runtime-name" => undefined} at address [] failed handling operation rollback -- java.lang.NullPointerException: java.lang.NullPointerException
> at org.jboss.as.repository.LocalDeploymentFileRepository.deleteDeployment(LocalDeploymentFileRepository.java:59)
> at org.jboss.as.host.controller.RemoteDomainConnectionService$RemoteFileRepository.deleteDeployment(RemoteDomainConnectionService.java:756)
> at org.jboss.as.domain.controller.operations.deployment.DeploymentFullReplaceHandler$1.handleResult(DeploymentFullReplaceHandler.java:181)
> at org.jboss.as.controller.AbstractOperationContext$Step.invokeResultHandler(AbstractOperationContext.java:1384)
> at org.jboss.as.controller.AbstractOperationContext$Step.handleResult(AbstractOperationContext.java:1366)
> at org.jboss.as.controller.AbstractOperationContext$Step.finalizeInternal(AbstractOperationContext.java:1328)
> at org.jboss.as.controller.AbstractOperationContext$Step.finalizeStep(AbstractOperationContext.java:1311)
> at org.jboss.as.controller.AbstractOperationContext$Step.access$300(AbstractOperationContext.java:1185)
> at org.jboss.as.controller.AbstractOperationContext.executeResultHandlerPhase(AbstractOperationContext.java:767)
> at org.jboss.as.controller.AbstractOperationContext.executeDoneStage(AbstractOperationContext.java:753)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:680)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1344)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:392)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:217)
> at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler.internalExecute(TransactionalProtocolOperationHandler.java:247)
> at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler.doExecute(TransactionalProtocolOperationHandler.java:185)
> at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$1.run(TransactionalProtocolOperationHandler.java:138)
> at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$1.run(TransactionalProtocolOperationHandler.java:134)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:360)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:81)
> at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2$1.run(TransactionalProtocolOperationHandler.java:157)
> at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2$1.run(TransactionalProtocolOperationHandler.java:153)
> at java.security.AccessController.doPrivileged(Native Method)
> at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2.execute(TransactionalProtocolOperationHandler.java:153)
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$ManagementRequestContextImpl$1.doExecute(AbstractMessageHandler.java:363)
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:472)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {code}
> This error will usually only happen for 2 out of the 4 identically configured slaves, and seems to happen randomly, although frequently enough.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 2 months
[JBoss JIRA] (WFLY-6594) Incorrect description of group-handler/group-timeout attribute in CLI
by Chen Maoqian (JIRA)
[ https://issues.jboss.org/browse/WFLY-6594?page=com.atlassian.jira.plugin.... ]
Chen Maoqian moved JBEAP-4549 to WFLY-6594:
-------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-6594 (was: JBEAP-4549)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: JMS
(was: JMS)
Target Release: (was: 7.backlog.GA)
Affects Version/s: 10.0.0.Final
(was: 7.0.0.CR2)
> Incorrect description of group-handler/group-timeout attribute in CLI
> ---------------------------------------------------------------------
>
> Key: WFLY-6594
> URL: https://issues.jboss.org/browse/WFLY-6594
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 10.0.0.Final
> Reporter: Chen Maoqian
> Assignee: Chen Maoqian
>
> The description of group-timeout attribute in CLI says:
> bq. How long a group binding will be used, -1 means for ever. Bindings are removed after this wait elapses (only valid for LOCAL handlers).
> However the attribute is valid for both LOCAL and REMOTE handler. If you configure the attribute with REMOTE handler it specifies how often the REMOTE will notify the LOCAL that the route (group binding) was used.
> The Artemis documentation \[1\] also suggests to configure the group-timeout for REMOTE handlers.
> bq. In case you are using group-timeouts, the remote node should have a smaller group-timeout with at least half of the value on the main coordinator. This is because this will determine how often the last-time-use value should be updated with a round trip for a request to the group between the nodes.
> \[1\] https://activemq.apache.org/artemis/docs/1.1.0/message-grouping.html
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 2 months
[JBoss JIRA] (WFLY-6593) Expired/invalidated session meta-data entries not removed when using optimistic locking or READ_COMMITTED isolation
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-6593?page=com.atlassian.jira.plugin.... ]
Paul Ferraro updated WFLY-6593:
-------------------------------
Git Pull Request: (was: https://github.com/wildfly/wildfly/pull/8834)
> Expired/invalidated session meta-data entries not removed when using optimistic locking or READ_COMMITTED isolation
> -------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-6593
> URL: https://issues.jboss.org/browse/WFLY-6593
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 7.0.0.CR1
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
>
> When using optimistic locking on the web cache, data from expired sessions is not removed from the web cache by the org.wildfly.clustering.web.infinispan.session.SessionExpirationScheduler and leaks forever.
> Session seems to be invalidated correctly and isn't accessible anymore.
> After tracing the code, org.wildfly.clustering.web.infinispan.session.InfinispanSessionMetaDataFactory.remove() doesn't remove the metadata entries when "this.properties.isLockOnWrite()" returns false (which is always the case for optimistic locking). Then in org.wildfly.clustering.web.infinispan.session.InfinispanSessionFactory.remove(), the call to attributesFactory.remove(id) also gets skipped.
> We've tried to adjust the code of org.wildfly.clustering.web.infinispan.session.InfinispanSessionMetaDataFactory.remove() to the following:
> {code}
> private boolean remove(String id, Cache<SessionCreationMetaDataKey, SessionCreationMetaDataEntry<L>> creationMetaDataCache) {
> SessionCreationMetaDataKey key = new SessionCreationMetaDataKey(id);
> if (this.properties.isLockOnWrite()) {
> if (creationMetaDataCache.getAdvancedCache().withFlags(Flag.ZERO_LOCK_ACQUISITION_TIMEOUT, Flag.FAIL_SILENTLY).lock(key)) {
> creationMetaDataCache.getAdvancedCache().withFlags(Flag.IGNORE_RETURN_VALUES).remove(key);
> this.accessMetaDataCache.getAdvancedCache().withFlags(Flag.IGNORE_RETURN_VALUES).remove(new SessionAccessMetaDataKey(id));
> return true;
> }
> return false;
> } else {
> creationMetaDataCache.getAdvancedCache().withFlags(Flag.IGNORE_RETURN_VALUES).remove(key);
> this.accessMetaDataCache.getAdvancedCache().withFlags(Flag.IGNORE_RETURN_VALUES).remove(new SessionAccessMetaDataKey(id));
> return true;
> }
> }
> {code}
> With that change, the memory leaks disappears.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 2 months
[JBoss JIRA] (WFLY-6593) Expired/invalidated session meta-data entries not removed when using optimistic locking or READ_COMMITTED isolation
by Paul Ferraro (JIRA)
Paul Ferraro created WFLY-6593:
----------------------------------
Summary: Expired/invalidated session meta-data entries not removed when using optimistic locking or READ_COMMITTED isolation
Key: WFLY-6593
URL: https://issues.jboss.org/browse/WFLY-6593
Project: WildFly
Issue Type: Bug
Components: Clustering
Affects Versions: 10.0.0.Final, 10.1.0.Final
Reporter: Paul Ferraro
Assignee: Paul Ferraro
When using optimistic locking on the web cache, data from expired sessions is not removed from the web cache by the org.wildfly.clustering.web.infinispan.session.SessionExpirationScheduler and leaks forever.
Session seems to be invalidated correctly and isn't accessible anymore.
After tracing the code, org.wildfly.clustering.web.infinispan.session.InfinispanSessionMetaDataFactory.remove() doesn't remove the metadata entries when "this.properties.isLockOnWrite()" returns false (which is always the case for optimistic locking). Then in org.wildfly.clustering.web.infinispan.session.InfinispanSessionFactory.remove(), the call to attributesFactory.remove(id) also gets skipped.
We've tried to adjust the code of org.wildfly.clustering.web.infinispan.session.InfinispanSessionMetaDataFactory.remove() to the following:
{code}
private boolean remove(String id, Cache<SessionCreationMetaDataKey, SessionCreationMetaDataEntry<L>> creationMetaDataCache) {
SessionCreationMetaDataKey key = new SessionCreationMetaDataKey(id);
if (this.properties.isLockOnWrite()) {
if (creationMetaDataCache.getAdvancedCache().withFlags(Flag.ZERO_LOCK_ACQUISITION_TIMEOUT, Flag.FAIL_SILENTLY).lock(key)) {
creationMetaDataCache.getAdvancedCache().withFlags(Flag.IGNORE_RETURN_VALUES).remove(key);
this.accessMetaDataCache.getAdvancedCache().withFlags(Flag.IGNORE_RETURN_VALUES).remove(new SessionAccessMetaDataKey(id));
return true;
}
return false;
} else {
creationMetaDataCache.getAdvancedCache().withFlags(Flag.IGNORE_RETURN_VALUES).remove(key);
this.accessMetaDataCache.getAdvancedCache().withFlags(Flag.IGNORE_RETURN_VALUES).remove(new SessionAccessMetaDataKey(id));
return true;
}
}
{code}
With that change, the memory leaks disappears.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 2 months