[JBoss JIRA] (WFCORE-1331) CLI input redirection regression
by Alexey Loubyansky (JIRA)
Alexey Loubyansky created WFCORE-1331:
-----------------------------------------
Summary: CLI input redirection regression
Key: WFCORE-1331
URL: https://issues.jboss.org/browse/WFCORE-1331
Project: WildFly Core
Issue Type: Bug
Components: CLI
Affects Versions: 2.0.7.Final
Reporter: Alexey Loubyansky
Assignee: Alexey Loubyansky
Fix For: 2.0.8.Final
The original issue WFCORE-877 was fixed but later re-introduced with the fix for WFCORE-1218.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFCORE-1330) Deployment error after reboot [WFLYSRV0137]
by ehsavoie Hugonnet (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1330?page=com.atlassian.jira.plugi... ]
ehsavoie Hugonnet commented on WFCORE-1330:
-------------------------------------------
[~wildflyer]
Could you provide :
* the command you use to deploy your application
* the log files
* do the failing applications depend on the datasource ?
* how did you created your datasource ?
Thanks
> Deployment error after reboot [WFLYSRV0137]
> -------------------------------------------
>
> Key: WFCORE-1330
> URL: https://issues.jboss.org/browse/WFCORE-1330
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 1.0.2.Final
> Environment: Ubuntu 14.04 LTS 64bit, jre-1.8.0_65
> Several deployed (JavaEE) web applications including non XA datasources that connect to a MySQL instance.
> Reporter: Tobi Tobias
> Assignee: ehsavoie Hugonnet
> Priority: Critical
>
> I have a working configuration on wildfly 9.0.2 final with several web applications (JavaEE).
> After a couple of days, I deployed another war file via jboss CLI. This application worked correctly and no deployment error occurred.
> But if I restart the server now, I get following error message:
> 10:36:01,893 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([("deployment" => "MM-Controller-0.1.0-SNAPSHOT.war")]) - failure description: "WFLYSRV0137: No deployment content with hash 966847a6f5f5bf8c3470f07ea9e65b7bbcdcd7b7 is available in the deployment content repository for deployment 'MM-Controller-0.1.0-SNAPSHOT.war'. This is a fatal boot error. To correct the problem, either restart with the --admin-only switch set and use the CLI to install the missing content or remove it from the configuration, or remove the deployment from the xml configuration file and restart."
> 10:36:01,990 FATAL [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
> I reproduced this at least 30 times - even with different jars. I always get this error. The server works fine as long as I don't reboot.
> The only way to fix the configuration is to manually remove the deployments from the standalone.xml.
> But this is not an option for me as I want to have the wildfly running as production server where I have several automatic deployments every day.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFCORE-1042) ExtensionRemoveHandler logs client mistakes
by ehsavoie Hugonnet (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1042?page=com.atlassian.jira.plugi... ]
ehsavoie Hugonnet reassigned WFCORE-1042:
-----------------------------------------
Assignee: ehsavoie Hugonnet
> ExtensionRemoveHandler logs client mistakes
> -------------------------------------------
>
> Key: WFCORE-1042
> URL: https://issues.jboss.org/browse/WFCORE-1042
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 2.0.0.CR6
> Reporter: Brian Stansberry
> Assignee: ehsavoie Hugonnet
> Priority: Minor
>
> If a user tries to remove an extension when there are still subsystems present that come from that extension, a stack trace appears in the log:
> {code}
> 01:02:23,542 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 2) WFLYCTL0013: Operation ("remove") failed - address: ([("extension" => "org.jboss.as.test.hc.extension")]): java.lang.IllegalStateException: WFLYCTL0219: An attempt was made to unregister extension org.jboss.as.test.hc.extension which still has subsystem HC registered
> at org.jboss.as.controller.extension.ExtensionRegistry.removeExtension(ExtensionRegistry.java:331) [wildfly-controller-2.0.0.CR7-SNAPSHOT.jar:2.0.0.CR7-SNAPSHOT]
> at org.jboss.as.controller.extension.ExtensionRemoveHandler.execute(ExtensionRemoveHandler.java:68) [wildfly-controller-2.0.0.CR7-SNAPSHOT.jar:2.0.0.CR7-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:890) [wildfly-controller-2.0.0.CR7-SNAPSHOT.jar:2.0.0.CR7-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:659) [wildfly-controller-2.0.0.CR7-SNAPSHOT.jar:2.0.0.CR7-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370) [wildfly-controller-2.0.0.CR7-SNAPSHOT.jar:2.0.0.CR7-SNAPSHOT]
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1336) [wildfly-controller-2.0.0.CR7-SNAPSHOT.jar:2.0.0.CR7-SNAPSHOT]
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:392) [wildfly-controller-2.0.0.CR7-SNAPSHOT.jar:2.0.0.CR7-SNAPSHOT]
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:217) [wildfly-controller-2.0.0.CR7-SNAPSHOT.jar:2.0.0.CR7-SNAPSHOT]
> {code}
> That's really just a client mistake and there's no reason to log it in the server. ExtensionRemoveHandler can catch the ISE thrown by ExtensionRegistry.removeExtension and convert it to an OperationFailedException.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFLY-6061) Deployment error after reboot [WFLYSRV0137]
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-6061?page=com.atlassian.jira.plugin.... ]
Brian Stansberry reassigned WFLY-6061:
--------------------------------------
Assignee: ehsavoie Hugonnet (was: Brian Stansberry)
[~ehugonnet] Can you have a look?
[~wildflyer] Do you see this problem with WildFly 10.0.0.CR5?
> Deployment error after reboot [WFLYSRV0137]
> -------------------------------------------
>
> Key: WFLY-6061
> URL: https://issues.jboss.org/browse/WFLY-6061
> Project: WildFly
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 1.0.2.Final
> Environment: Ubuntu 14.04 LTS 64bit, jre-1.8.0_65
> Several deployed (JavaEE) web applications including non XA datasources that connect to a MySQL instance.
> Reporter: Tobi Tobias
> Assignee: ehsavoie Hugonnet
> Priority: Critical
>
> I have a working configuration on wildfly 9.0.2 final with several web applications (JavaEE).
> After a couple of days, I deployed another war file via jboss CLI. This application worked correctly and no deployment error occurred.
> But if I restart the server now, I get following error message:
> 10:36:01,893 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([("deployment" => "MM-Controller-0.1.0-SNAPSHOT.war")]) - failure description: "WFLYSRV0137: No deployment content with hash 966847a6f5f5bf8c3470f07ea9e65b7bbcdcd7b7 is available in the deployment content repository for deployment 'MM-Controller-0.1.0-SNAPSHOT.war'. This is a fatal boot error. To correct the problem, either restart with the --admin-only switch set and use the CLI to install the missing content or remove it from the configuration, or remove the deployment from the xml configuration file and restart."
> 10:36:01,990 FATAL [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
> I reproduced this at least 30 times - even with different jars. I always get this error. The server works fine as long as I don't reboot.
> The only way to fix the configuration is to manually remove the deployments from the standalone.xml.
> But this is not an option for me as I want to have the wildfly running as production server where I have several automatic deployments every day.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFCORE-1330) Deployment error after reboot [WFLYSRV0137]
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1330?page=com.atlassian.jira.plugi... ]
Brian Stansberry moved WFLY-6061 to WFCORE-1330:
------------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-1330 (was: WFLY-6061)
Component/s: Domain Management
(was: Domain Management)
Affects Version/s: 1.0.2.Final
(was: 9.0.2.Final)
> Deployment error after reboot [WFLYSRV0137]
> -------------------------------------------
>
> Key: WFCORE-1330
> URL: https://issues.jboss.org/browse/WFCORE-1330
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 1.0.2.Final
> Environment: Ubuntu 14.04 LTS 64bit, jre-1.8.0_65
> Several deployed (JavaEE) web applications including non XA datasources that connect to a MySQL instance.
> Reporter: Tobi Tobias
> Assignee: ehsavoie Hugonnet
> Priority: Critical
>
> I have a working configuration on wildfly 9.0.2 final with several web applications (JavaEE).
> After a couple of days, I deployed another war file via jboss CLI. This application worked correctly and no deployment error occurred.
> But if I restart the server now, I get following error message:
> 10:36:01,893 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([("deployment" => "MM-Controller-0.1.0-SNAPSHOT.war")]) - failure description: "WFLYSRV0137: No deployment content with hash 966847a6f5f5bf8c3470f07ea9e65b7bbcdcd7b7 is available in the deployment content repository for deployment 'MM-Controller-0.1.0-SNAPSHOT.war'. This is a fatal boot error. To correct the problem, either restart with the --admin-only switch set and use the CLI to install the missing content or remove it from the configuration, or remove the deployment from the xml configuration file and restart."
> 10:36:01,990 FATAL [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
> I reproduced this at least 30 times - even with different jars. I always get this error. The server works fine as long as I don't reboot.
> The only way to fix the configuration is to manually remove the deployments from the standalone.xml.
> But this is not an option for me as I want to have the wildfly running as production server where I have several automatic deployments every day.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFLY-6011) Remote branch of a transaction gets rolled back incorrectly.
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-6011?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated WFLY-6011:
------------------------------------------
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1298161, https://bugzilla.redhat.com/show_bug.cgi?id=1301676 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1298161)
> Remote branch of a transaction gets rolled back incorrectly.
> -------------------------------------------------------------
>
> Key: WFLY-6011
> URL: https://issues.jboss.org/browse/WFLY-6011
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Reporter: Jason Greene
> Assignee: David Lloyd
>
> The use case is as follow:
> Client makes a call to a bean on server-1
> bean (server-1) inserts a row into table-1
> bean (server-1) calls to a bean on server-2
> bean (server-2) inserts a row into table-2
> bean (server-2) goes to sleep for 3 minutes
> periodic recovery (server-1) flags the remote branchof the transaction (on server-2) as in doubt and rolls it back.
> (server-1 log)
> {noformat}
> 11:53:37,991 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) RecoveryXids _whenFirstSeen toRecover no RecoveryOnlyEJBXAResource{receiverContext=EJBReceiverContext{clientContext=org.jboss.ejb.client.EJBClientContext@322f7790, receiver=Remoting connection EJB receiver [connection=Remoting connection <2c1ab3f6>,channel=jboss.ejb,nodename=server2]}, transactionOriginNodeIdentifier='server1'} 1452599607985 === 1452599617991
> 11:53:37,991 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) Have 1 Xids to recover on this pass.
> 11:53:37,992 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) No record found for < formatId=131077, gtrid_length=35, bqual_length=43, tx_uid=0:ffffc0a80164:-fa2e9db:5694e833:2c, node_name=server1, branch_uid=0:ffffc0a80164:-fa2e9db:5694e833:39, subordinatenodename=server2, eis_name=unknown eis name >
> 11:53:37,992 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) XAResourceOrphanFilter com.arjuna.ats.internal.jta.recovery.arjunacore.JTATransactionLogXAResourceOrphanFilter voted ABSTAIN
> 11:53:37,993 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) node name of < formatId=131077, gtrid_length=35, bqual_length=43, tx_uid=0:ffffc0a80164:-fa2e9db:5694e833:2c, node_name=server1, branch_uid=0:ffffc0a80164:-fa2e9db:5694e833:39, subordinatenodename=server2, eis_name=unknown eis name > is server1
> 11:53:37,993 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) XAResourceOrphanFilter com.arjuna.ats.internal.jta.recovery.arjunacore.JTANodeNameXAResourceOrphanFilter voted ROLLBACK
> 11:53:37,993 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) subordinate node name of < formatId=131077, gtrid_length=35, bqual_length=43, tx_uid=0:ffffc0a80164:-fa2e9db:5694e833:2c, node_name=server1, branch_uid=0:ffffc0a80164:-fa2e9db:5694e833:39, subordinatenodename=server2, eis_name=unknown eis name > is server2
> 11:53:37,993 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) Checking whether Xid < formatId=131077, gtrid_length=35, bqual_length=43, tx_uid=0:ffffc0a80164:-fa2e9db:5694e833:2c, node_name=server1, branch_uid=0:ffffc0a80164:-fa2e9db:5694e833:39, subordinatenodename=server2, eis_name=unknown eis name > exists in ObjectStore.
> 11:53:37,993 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) Looking for 0:ffffc0a80164:-fa2e9db:5694e833:2c and /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction/SubordinateAtomicAction/JCA
> 11:53:37,993 INFO [com.arjuna.ats.jta] (Periodic Recovery) ARJUNA016013: Rolling back < formatId=131077, gtrid_length=35, bqual_length=43, tx_uid=0:ffffc0a80164:-fa2e9db:5694e833:2c, node_name=server1, branch_uid=0:ffffc0a80164:-fa2e9db:5694e833:39, subordinatenodename=server2, eis_name=unknown eis name >
> {noformat}
> (server-2 log)
> {noformat}
> 11:53:37,997 TRACE [com.arjuna.ats.jta] (EJB default - 5) TransactionImple.getStatus: javax.transaction.Status.STATUS_ACTIVE
> 11:53:37,998 TRACE [com.arjuna.ats.arjuna] (EJB default - 5) BasicAction::phase2Abort() for action-id 0:ffffc0a80164:-41fcd6d0:5694e85a:34
> 11:53:37,998 TRACE [com.arjuna.ats.arjuna] (EJB default - 5) BasicAction::doAbort (XAResourceRecord < resource:XAResourceWrapperImpl@3de8e444[xaResource=org.jboss.jca.adapters.jdbc.xa.XAManagedConnection@6440856e pad=false overrideRmValue=false productName=PostgreSQL productVersion=9.4.1 jndiName=java:jboss/datasources/testJBossDS], txid:< formatId=131077, gtrid_length=35, bqual_length=43, tx_uid=0:ffffc0a80164:-fa2e9db:5694e833:2c, node_name=server1, branch_uid=0:ffffc0a80164:-41fcd6d0:5694e85a:3e, subordinatenodename=server2, eis_name=java:jboss/datasources/testJBossDS >, heuristic: TwoPhaseOutcome.FINISH_OK, product: PostgreSQL/9.4.1, jndiName: java:jboss/datasources/testJBossDS com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord@32ff4c6d >)
> 11:53:37,998 TRACE [com.arjuna.ats.jta] (EJB default - 5) XAResourceRecord.topLevelAbort for XAResourceRecord < resource:XAResourceWrapperImpl@3de8e444[xaResource=org.jboss.jca.adapters.jdbc.xa.XAManagedConnection@6440856e pad=false overrideRmValue=false productName=PostgreSQL productVersion=9.4.1 jndiName=java:jboss/datasources/testJBossDS], txid:< formatId=131077, gtrid_length=35, bqual_length=43, tx_uid=0:ffffc0a80164:-fa2e9db:5694e833:2c, node_name=server1, branch_uid=0:ffffc0a80164:-41fcd6d0:5694e85a:3e, subordinatenodename=server2, eis_name=java:jboss/datasources/testJBossDS >, heuristic: TwoPhaseOutcome.FINISH_OK, product: PostgreSQL/9.4.1, jndiName: java:jboss/datasources/testJBossDS com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord@32ff4c6d >, record id=0:ffffc0a80164:-41fcd6d0:5694e85a:3f
> 11:53:37,998 TRACE [org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService$MyXaMCF] (EJB default - 5) Unlock: HeldByCurrentThread: Yes, Locked: Yes, HoldCount: 1, QueueLength: 0
> 11:53:37,998 TRACE [org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService$MyXaMCF] (EJB default - 5) Owner: Thread[EJB default - 5,5,EJB default]
> 11:53:37,999 TRACE [com.arjuna.ats.arjuna] (EJB default - 5) BasicAction::doAbort() result for action-id (0:ffffc0a80164:-41fcd6d0:5694e85a:34) on record id: (0:ffffc0a80164:-41fcd6d0:5694e85a:3f) is (TwoPhaseOutcome.FINISH_OK) node id: (server2)
> 11:53:37,999 TRACE [com.arjuna.ats.arjuna] (EJB default - 5) BasicAction::updateState() for action-id 0:ffffc0a80164:-41fcd6d0:5694e85a:34
> 11:53:37,999 TRACE [com.arjuna.ats.jta] (EJB default - 5) SynchronizationImple.afterCompletion
> {noformat}
> bean (server-2) wake up
> bean (server-1) updates the row in table-1
> at this point the parent transaction gets committed without an error
> {noformat}
> 11:55:31,104 TRACE [com.arjuna.ats.arjuna] (EJB default - 3) BasicAction::removeChildThread () action 0:ffffc0a80164:-fa2e9db:5694e833:2c removing TSThread:1
> 11:55:31,104 TRACE [com.arjuna.ats.arjuna] (EJB default - 3) BasicAction::removeChildThread () action 0:ffffc0a80164:-fa2e9db:5694e833:2c removing TSThread:1 result = true
> 11:55:31,104 TRACE [com.arjuna.ats.arjuna] (EJB default - 3) TransactionReaper::remove ( BasicAction: 0:ffffc0a80164:-fa2e9db:5694e833:2c status: ActionStatus.COMMITTED )
> {noformat}
> client call ends
> When I look at the table in the database I see a row in table-1 but no row in table-2. I would expect to see both tables empty.
> When I switch to JTS and run the same use case it all works as expected.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFLY-6062) RolesSearch in AdvancedLdapLoginModule is doing a needless LDAP call for each individual role
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-6062?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse commented on WFLY-6062:
----------------------------------------
AdvancedLdapLoginModule issues need to be raised in the SECURITY project with Negotiation as the component.
> RolesSearch in AdvancedLdapLoginModule is doing a needless LDAP call for each individual role
> ---------------------------------------------------------------------------------------------
>
> Key: WFLY-6062
> URL: https://issues.jboss.org/browse/WFLY-6062
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Hynek Švábek
> Assignee: Darran Lofthouse
>
> There will be needless LDAP calls if we use AdvancedLdap login module.
> If a user is a member of (lets say) 100 groups, then we can get an extra 100 calls to the LDAP server.
> It can be performance problem.
> Same problem was in LdapExt login module.
> You can see this BZ https://bugzilla.redhat.com/show_bug.cgi?id=1223840
> Example from Wireshark for 2 groups:
> {code}
> * searchRequest(3) "ou=Roles,ou=AdvancedLdapLoginModuleSpecialNamesTestCasee4b1c459,OU=primary,O=eapqe,DC=JBOSS3,DC=test" wholeSubtree
> * searchResEntry(3) "CN=JBossAdmin,OU=Roles,OU=AdvancedLdapLoginModuleSpecialNamesTestCasee4b1c459,OU=primary,O=eapqe,DC=JBOSS3,DC=test" | searchResEntry(3) "CN=Slash/Char,OU=Roles,OU=AdvancedLdapLoginModuleSpecialNamesTestCasee4b1c459,OU=primary,O=eapqe,DC=JBOSS3,DC=test" | searchResDone(3) success [2 results]
> * searchRequest(4) "CN=JBossAdmin,ou=Roles,ou=AdvancedLdapLoginModuleSpecialNamesTestCasee4b1c459,OU=primary,O=eapqe,DC=JBOSS3,DC=test" baseObject
> * searchResEntry(4) "CN=JBossAdmin,ou=Roles,ou=AdvancedLdapLoginModuleSpecialNamesTestCasee4b1c459,OU=primary,O=eapqe,DC=JBOSS3,DC=test" | searchResDone(4) success [1 result]
> * searchRequest(5) "CN=Slash/Char,ou=Roles,ou=AdvancedLdapLoginModuleSpecialNamesTestCasee4b1c459,OU=primary,O=eapqe,DC=JBOSS3,DC=test" baseObject
> * searchResEntry(5) "CN=Slash/Char,ou=Roles,ou=AdvancedLdapLoginModuleSpecialNamesTestCasee4b1c459,OU=primary,O=eapqe,DC=JBOSS3,DC=test" | searchResDone(5) success [1 result]
> {code}|
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFLY-6062) RolesSearch in AdvancedLdapLoginModule is doing a needless LDAP call for each individual role
by Hynek Švábek (JIRA)
Hynek Švábek created WFLY-6062:
----------------------------------
Summary: RolesSearch in AdvancedLdapLoginModule is doing a needless LDAP call for each individual role
Key: WFLY-6062
URL: https://issues.jboss.org/browse/WFLY-6062
Project: WildFly
Issue Type: Bug
Components: Security
Reporter: Hynek Švábek
Assignee: Darran Lofthouse
There will be needless LDAP calls if we use AdvancedLdap login module.
If a user is a member of (lets say) 100 groups, then we can get an extra 100 calls to the LDAP server.
It can be performance problem.
Same problem was in LdapExt login module.
You can see this BZ https://bugzilla.redhat.com/show_bug.cgi?id=1223840
Example from Wireshark for 2 groups:
{code}
* searchRequest(3) "ou=Roles,ou=AdvancedLdapLoginModuleSpecialNamesTestCasee4b1c459,OU=primary,O=eapqe,DC=JBOSS3,DC=test" wholeSubtree
* searchResEntry(3) "CN=JBossAdmin,OU=Roles,OU=AdvancedLdapLoginModuleSpecialNamesTestCasee4b1c459,OU=primary,O=eapqe,DC=JBOSS3,DC=test" | searchResEntry(3) "CN=Slash/Char,OU=Roles,OU=AdvancedLdapLoginModuleSpecialNamesTestCasee4b1c459,OU=primary,O=eapqe,DC=JBOSS3,DC=test" | searchResDone(3) success [2 results]
* searchRequest(4) "CN=JBossAdmin,ou=Roles,ou=AdvancedLdapLoginModuleSpecialNamesTestCasee4b1c459,OU=primary,O=eapqe,DC=JBOSS3,DC=test" baseObject
* searchResEntry(4) "CN=JBossAdmin,ou=Roles,ou=AdvancedLdapLoginModuleSpecialNamesTestCasee4b1c459,OU=primary,O=eapqe,DC=JBOSS3,DC=test" | searchResDone(4) success [1 result]
* searchRequest(5) "CN=Slash/Char,ou=Roles,ou=AdvancedLdapLoginModuleSpecialNamesTestCasee4b1c459,OU=primary,O=eapqe,DC=JBOSS3,DC=test" baseObject
* searchResEntry(5) "CN=Slash/Char,ou=Roles,ou=AdvancedLdapLoginModuleSpecialNamesTestCasee4b1c459,OU=primary,O=eapqe,DC=JBOSS3,DC=test" | searchResDone(5) success [1 result]
{code}|
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months