[JBoss JIRA] (WFLY-3173) Default number of DIST owners is too conservative
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-3173?page=com.atlassian.jira.plugin.... ]
Radoslav Husar updated WFLY-3173:
---------------------------------
Fix Version/s: 8.0.1.Final
We want to target 8.0.1.Final ideally, especially since it's a small change.
> Default number of DIST owners is too conservative
> -------------------------------------------------
>
> Key: WFLY-3173
> URL: https://issues.jboss.org/browse/WFLY-3173
> Project: WildFly
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: Clustering
> Affects Versions: 8.0.0.Final
> Reporter: Paul Ferraro
> Assignee: Radoslav Husar
> Fix For: 8.0.1.Final
>
>
> WildFly uses DIST by default using 4 owners, which is too conservative. I think we should lower this default value to 2, which is Infinispan's default value. We'll get a nice performance bump too.
> Don't forget to create transformers to handle the default value change for old model versions.
--
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
12 years, 3 months
[JBoss JIRA] (WFLY-3144) Session replication doesn't work as expected
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-3144?page=com.atlassian.jira.plugin.... ]
Radoslav Husar updated WFLY-3144:
---------------------------------
Fix Version/s: 9.0.0.CR1
(was: 8.0.1.Final)
Unfortunately, this will make it in with the Weld 2.2 upgrade in WildFly 9.
> Session replication doesn't work as expected
> --------------------------------------------
>
> Key: WFLY-3144
> URL: https://issues.jboss.org/browse/WFLY-3144
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: CDI / Weld, Clustering, EJB
> Affects Versions: 8.0.0.Final
> Reporter: Tomas Remes
> Assignee: Radoslav Husar
> Fix For: 9.0.0.CR1
>
> Attachments: translator.zip
>
>
> I am experimenting with quite simple Stateful SessionScoped bean ( see org.jboss.weld.tests.clustering.translator.TranslatorControllerBean from attached reproducer) and actually there's not any specific exception, but the behavior is at least weird. I haven't tried with plain EJB so far. Reproducible by following steps:
> 1. Run first node with "/bin/standalone.sh -c standalone-ha.xml"
> 2. Run second node with "./bin/standalone.sh -c standalone-ha.xml -Djboss.socket.binding.port-offset=100 -Djboss.node.name=second"
> 3. Build and deploy attached reproducer
> 4. Open 127.0.0.1:8080/translator in your browser and translate something.
> 5. Open 127.0.0.1:8180/translator and note that number of translated sentences is not replicated correctly.
> This works correctly in EAP. I am running with default standalone-ha configuration on oracle's 1.7.0_45 jdk.
--
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
12 years, 3 months
[JBoss JIRA] (JGRP-1735) JChannel.startFlush() does not attempt back-off on flush collision
by Vladimir Blagojevic (JIRA)
[ https://issues.jboss.org/browse/JGRP-1735?page=com.atlassian.jira.plugin.... ]
Vladimir Blagojevic edited comment on JGRP-1735 at 4/3/14 11:32 AM:
--------------------------------------------------------------------
Rich, I investigated this report and you are correct to point out that Javadoc is incorrect. We have changed starting of FLUSH protocol to be fail-fast and have moved back-off algorithm to Util class. I will update Javadoc and documentation accordingly.
was (Author: vblagojevic):
Rich, I investigated this report and you are correct to point out that Javadoc is incorrect. We have changed starting of FLUSH protocol to be failed fast and have moved back-off algorithm to Util class. I will update Javadoc and documentation accordingly.
> JChannel.startFlush() does not attempt back-off on flush collision
> ------------------------------------------------------------------
>
> Key: JGRP-1735
> URL: https://issues.jboss.org/browse/JGRP-1735
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.4
> Reporter: Rich DiCroce
> Assignee: Vladimir Blagojevic
> Fix For: 3.5
>
>
> The Javadoc for JChannel.startFlush() says:
> {quote}
> In case of flush collisions, a random sleep time backoff algorithm is employed and the flush is reattempted for numberOfAttempts. Therefore this method is guaranteed to return after timeout x numberOfAttempts milliseconds.
> {quote}
> This does not appear to be true. I had two nodes call this method at the same time and immediately got an exception due to a flush collision. The salient part of the stack trace is:
> {noformat}
> Caused by: java.lang.Exception: Flush failed for EITSQL2-33698
> at org.jgroups.protocols.pbcast.FLUSH.up(FLUSH.java:435) [jgroups-3.4.0.Final.jar:3.4.0.Final]
> at org.jgroups.protocols.pbcast.FLUSH.up(FLUSH.java:501) [jgroups-3.4.0.Final.jar:3.4.0.Final]
> at org.jgroups.stack.Protocol.up(Protocol.java:409) [jgroups-3.4.0.Final.jar:3.4.0.Final]
> at org.jgroups.protocols.RSVP.up(RSVP.java:221) [jgroups-3.4.0.Final.jar:3.4.0.Final]
> at org.jgroups.protocols.FRAG2.up(FRAG2.java:182) [jgroups-3.4.0.Final.jar:3.4.0.Final]
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:434) [jgroups-3.4.0.Final.jar:3.4.0.Final]
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:434) [jgroups-3.4.0.Final.jar:3.4.0.Final]
> at org.jgroups.stack.Protocol.up(Protocol.java:409) [jgroups-3.4.0.Final.jar:3.4.0.Final]
> at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:294) [jgroups-3.4.0.Final.jar:3.4.0.Final]
> at org.jgroups.protocols.UNICAST3.removeAndDeliver(UNICAST3.java:796) [jgroups-3.4.0.Final.jar:3.4.0.Final]
> at org.jgroups.protocols.UNICAST3.handleBatchReceived(UNICAST3.java:752) [jgroups-3.4.0.Final.jar:3.4.0.Final]
> at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:466) [jgroups-3.4.0.Final.jar:3.4.0.Final]
> at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:662) [jgroups-3.4.0.Final.jar:3.4.0.Final]
> at org.jgroups.stack.Protocol.up(Protocol.java:409) [jgroups-3.4.0.Final.jar:3.4.0.Final]
> at org.jgroups.protocols.FD.up(FD.java:274) [jgroups-3.4.0.Final.jar:3.4.0.Final]
> at org.jgroups.stack.Protocol.up(Protocol.java:409) [jgroups-3.4.0.Final.jar:3.4.0.Final]
> at org.jgroups.stack.Protocol.up(Protocol.java:409) [jgroups-3.4.0.Final.jar:3.4.0.Final]
> at org.jgroups.stack.Protocol.up(Protocol.java:409) [jgroups-3.4.0.Final.jar:3.4.0.Final]
> at org.jgroups.protocols.TP.passBatchUp(TP.java:1422) [jgroups-3.4.0.Final.jar:3.4.0.Final]
> at org.jgroups.protocols.TP$BatchHandler.run(TP.java:1574) [jgroups-3.4.0.Final.jar:3.4.0.Final]
> ... 3 more
> {noformat}
> The Javadoc talks about "timeout" and "numberOfAttempts" as if they were method parameters, but they aren't. Were those part of an earlier version of JGroups? If they're still present, where are they? Will JGroups still retry a flush that failed due to a collision?
--
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
12 years, 3 months
[JBoss JIRA] (JGRP-1735) JChannel.startFlush() does not attempt back-off on flush collision
by Vladimir Blagojevic (JIRA)
[ https://issues.jboss.org/browse/JGRP-1735?page=com.atlassian.jira.plugin.... ]
Vladimir Blagojevic commented on JGRP-1735:
-------------------------------------------
Rich, I investigated this report and you are correct to point out that Javadoc is incorrect. We have changed starting of FLUSH protocol to be failed fast and have moved back-off algorithm to Util class. I will update Javadoc and documentation accordingly.
> JChannel.startFlush() does not attempt back-off on flush collision
> ------------------------------------------------------------------
>
> Key: JGRP-1735
> URL: https://issues.jboss.org/browse/JGRP-1735
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.4
> Reporter: Rich DiCroce
> Assignee: Vladimir Blagojevic
> Fix For: 3.5
>
>
> The Javadoc for JChannel.startFlush() says:
> {quote}
> In case of flush collisions, a random sleep time backoff algorithm is employed and the flush is reattempted for numberOfAttempts. Therefore this method is guaranteed to return after timeout x numberOfAttempts milliseconds.
> {quote}
> This does not appear to be true. I had two nodes call this method at the same time and immediately got an exception due to a flush collision. The salient part of the stack trace is:
> {noformat}
> Caused by: java.lang.Exception: Flush failed for EITSQL2-33698
> at org.jgroups.protocols.pbcast.FLUSH.up(FLUSH.java:435) [jgroups-3.4.0.Final.jar:3.4.0.Final]
> at org.jgroups.protocols.pbcast.FLUSH.up(FLUSH.java:501) [jgroups-3.4.0.Final.jar:3.4.0.Final]
> at org.jgroups.stack.Protocol.up(Protocol.java:409) [jgroups-3.4.0.Final.jar:3.4.0.Final]
> at org.jgroups.protocols.RSVP.up(RSVP.java:221) [jgroups-3.4.0.Final.jar:3.4.0.Final]
> at org.jgroups.protocols.FRAG2.up(FRAG2.java:182) [jgroups-3.4.0.Final.jar:3.4.0.Final]
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:434) [jgroups-3.4.0.Final.jar:3.4.0.Final]
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:434) [jgroups-3.4.0.Final.jar:3.4.0.Final]
> at org.jgroups.stack.Protocol.up(Protocol.java:409) [jgroups-3.4.0.Final.jar:3.4.0.Final]
> at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:294) [jgroups-3.4.0.Final.jar:3.4.0.Final]
> at org.jgroups.protocols.UNICAST3.removeAndDeliver(UNICAST3.java:796) [jgroups-3.4.0.Final.jar:3.4.0.Final]
> at org.jgroups.protocols.UNICAST3.handleBatchReceived(UNICAST3.java:752) [jgroups-3.4.0.Final.jar:3.4.0.Final]
> at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:466) [jgroups-3.4.0.Final.jar:3.4.0.Final]
> at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:662) [jgroups-3.4.0.Final.jar:3.4.0.Final]
> at org.jgroups.stack.Protocol.up(Protocol.java:409) [jgroups-3.4.0.Final.jar:3.4.0.Final]
> at org.jgroups.protocols.FD.up(FD.java:274) [jgroups-3.4.0.Final.jar:3.4.0.Final]
> at org.jgroups.stack.Protocol.up(Protocol.java:409) [jgroups-3.4.0.Final.jar:3.4.0.Final]
> at org.jgroups.stack.Protocol.up(Protocol.java:409) [jgroups-3.4.0.Final.jar:3.4.0.Final]
> at org.jgroups.stack.Protocol.up(Protocol.java:409) [jgroups-3.4.0.Final.jar:3.4.0.Final]
> at org.jgroups.protocols.TP.passBatchUp(TP.java:1422) [jgroups-3.4.0.Final.jar:3.4.0.Final]
> at org.jgroups.protocols.TP$BatchHandler.run(TP.java:1574) [jgroups-3.4.0.Final.jar:3.4.0.Final]
> ... 3 more
> {noformat}
> The Javadoc talks about "timeout" and "numberOfAttempts" as if they were method parameters, but they aren't. Were those part of an earlier version of JGroups? If they're still present, where are they? Will JGroups still retry a flush that failed due to a collision?
--
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
12 years, 3 months
[JBoss JIRA] (DROOLS-461) Memory Leak in Drools6.0.1-JavaLexer- Whenever application is restarted in websphere
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-461?page=com.atlassian.jira.plugin... ]
Mario Fusco commented on DROOLS-461:
------------------------------------
I'd need some clarification to start giving a look at this.
First of all what do you mean with "restart the application"? Redeploy probably?
Second, how did you find that the JavaLexer is leaking? Can you provide me the chain of references that is keeping it alive?
Thanks,
Mario
> Memory Leak in Drools6.0.1-JavaLexer- Whenever application is restarted in websphere
> ------------------------------------------------------------------------------------
>
> Key: DROOLS-461
> URL: https://issues.jboss.org/browse/DROOLS-461
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 6.0.1.Final
> Environment: Websphere7.0, Java
> Reporter: jacob sukumar
> Assignee: Mario Fusco
>
> Everytime we restarted the application on websphere and taking the heap dumps, we could able to see around 8MB of JavaLexer(org/drools/compiler/rule/builder/dialect/java/parser/JavaLexer) is leaking. Let us say if we restarted the application for 3 times, (8*3)24MB heap memory is leaking.
--
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
12 years, 3 months
[JBoss JIRA] (WFLY-3215) JSF 1.2 on Wildfly 8 Final - weld-core-jsf is still referencing JSF 2.2 API
by Farah Juma (JIRA)
[ https://issues.jboss.org/browse/WFLY-3215?page=com.atlassian.jira.plugin.... ]
Farah Juma commented on WFLY-3215:
----------------------------------
I took a quick look at the jboss-deployment-structure.xml file you posted [here | http://stackoverflow.com/questions/22758645/jsf-1-2-on-wildfly-8-final-we...]. The <exclude-subsystems> tag that excludes the Weld subsystem should be inside the <deployment> tag instead of inside the <sub-deployment> tags (e.g., take a look at how the resteasy subsystem is excluded in https://docs.jboss.org/author/display/AS71/Class+Loading+in+AS7). That should work around the problem if you don't need Weld.
Also, note that changing the JSF implementation doesn't require any changes to the jboss-deployment-structure.xml file. In particular, there is no need to add exclusions for the JSF main slot or dependencies on the 1.2 slot.
> JSF 1.2 on Wildfly 8 Final - weld-core-jsf is still referencing JSF 2.2 API
> ---------------------------------------------------------------------------
>
> Key: WFLY-3215
> URL: https://issues.jboss.org/browse/WFLY-3215
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JSF
> Affects Versions: 8.0.0.Final
> Reporter: Stanley Hillner
> Assignee: Farah Juma
>
> I added JSF 1.2 support by follwing [this tutorial|https://community.jboss.org/wiki/StepsToAddAnyNewJSFImplementati...] and the sample project provided by Stan Silvert works fine. But when I deploy our own app I always get the following error message:
> {noformat}
> ERROR [request] UT005023: Exception handling request to /backoffice/login.faces: java.lang.NoSuchMethodError: javax.faces.context.FacesContext.getAttributes()Ljava/util/Map;
> [exec] at org.jboss.weld.jsf.ConversationAwareViewHandler.getActionURL(ConversationAwareViewHandler.java:103)
> [exec] at javax.faces.application.ViewHandlerWrapper.getActionURL(ViewHandlerWrapper.java:147)
> [exec] at com.sun.facelets.FaceletViewHandler.getActionURL(FaceletViewHandler.java:807)
> [exec] at org.apache.myfaces.shared_tomahawk.renderkit.html.HtmlRenderer.getActionUrl(HtmlRenderer.java:77)
> [exec] at org.apache.myfaces.custom.form.HtmlFormRenderer.getActionUrl(HtmlFormRenderer.java:45)
> [exec] at org.apache.myfaces.shared_tomahawk.renderkit.html.HtmlFormRendererBase.encodeBegin(HtmlFormRendererBase.java:102)
> [exec] at org.apache.myfaces.custom.form.HtmlFormRenderer.encodeBegin(HtmlFormRenderer.java:134)
> [exec] at javax.faces.component.UIComponentBase.encodeBegin(UIComponentBase.java:816)
> [exec] at javax.faces.component.UIComponent.encodeAll(UIComponent.java:928)
> [exec] at javax.faces.component.UIComponent.encodeAll(UIComponent.java:933)
> [exec] at com.sun.facelets.FaceletViewHandler.renderView(FaceletViewHandler.java:594)
> [exec] at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:110)
> [exec] at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:100)
> [exec] at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
> [exec] at javax.faces.webapp.FacesServlet.service(FacesServlet.java:266)
> ...
> {noformat}
> This message indicates that the jsf-injection module still references a newer JSF API but not the JSF-1.2 API. I also had a look at the implementation of this module and I saw that the class ConversationAwareViewHandler which is included in the new jsf-injection module cannot work with JSF 1.2 since it calls methods from JSF 2.x.
> I also posted this issue [here|http://stackoverflow.com/questions/22758645/jsf-1-2-on-wildfly-8-fin...] and need a solution.
--
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
12 years, 3 months
[JBoss JIRA] (WFLY-3072) Support Referrals for security realms using LDAP for authentication or group loading.
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-3072?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse updated WFLY-3072:
-----------------------------------
Description:
I see the following scenarios to cover for this: -
- Authentication - A search is performed e.g against 'uid' and a referral is encountered, the URL needs to be extracted from the referral and a new connection created using the referral URL to load any additional attributes for the user, the referral URL is then used to establish the connection as the user to verify that their password is correct.
Group loading then has a couple of issues, firstly where the user was a referral.
The search for group membership information is a fresh start but now we potentially have 2 simple named and 2 distinguished names that could be referenced from the group object. We may want a config option to specify which one to actually use and even possibly use both.
Next could a group also be a referral, i.e. it contains the reference to the user as an attribute so was matched in the search but is also a referral to the true named group in another location. In this situation I suggest any iterative search takes into account the context containing the actual group definition and continues the search from there.
And then where the principal contains an attribute that references, this one should be a simple following of a referral and once followed continue the attribute loading using the new connection.
The connection manager logic is going to need reworking, ideally for a referral we should check if we have a connection definition that matches based on the URL returned otherwise we will need to try and establish a connection based on the settings of the last connection used, this probably also introduces a notion of some form of connection stack of the connections used for the current request - referrals could have us bouncing back and forth so connections should be cached and re-used where possible during authentication and group loading.
* Connection Settings *
We are going to need to support two different modes in relation to the 'java.naming.referral' property, follow and throw.
- *follow* - In this mode when the InitialDirContext encounters a referral during a search it will automatically follow it, this means automatically connecting to the server in the URL. This is fine if the remaining connection settings are valid for the alternative server e.g. same bindDN and credential. We however need to take the following into account for subsequent operations such as password validation or further queries.
- *throw* - When a referral is encountered and exception will be thrown instead, this mode should make it easier to have some more advanced referral handling logic that allows us control of which connection we subsequently use, e.g. we could not use a completely different host name to the one in the referral or use a different bind DN / credential pair.
was:
I see the following scenarios to cover for this: -
- Authentication - A search is performed e.g against 'uid' and a referral is encountered, the URL needs to be extracted from the referral and a new connection created using the referral URL to load any additional attributes for the user, the referral URL is then used to establish the connection as the user to verify that their password is correct.
Group loading then has a couple of issues, firstly where the user was a referral.
The search for group membership information is a fresh start but now we potentially have 2 simple named and 2 distinguished names that could be referenced from the group object. We may want a config option to specify which one to actually use and even possibly use both.
Next could a group also be a referral, i.e. it contains the reference to the user as an attribute so was matched in the search but is also a referral to the true named group in another location. In this situation I suggest any iterative search takes into account the context containing the actual group definition and continues the search from there.
And then where the principal contains an attribute that references, this one should be a simple following of a referral and once followed continue the attribute loading using the new connection.
The connection manager logic is going to need reworking, ideally for a referral we should check if we have a connection definition that matches based on the URL returned otherwise we will need to try and establish a connection based on the settings of the last connection used, this probably also introduces a notion of some form of connection stack of the connections used for the current request - referrals could have us bouncing back and forth so connections should be cached and re-used where possible during authentication and group loading.
> Support Referrals for security realms using LDAP for authentication or group loading.
> -------------------------------------------------------------------------------------
>
> Key: WFLY-3072
> URL: https://issues.jboss.org/browse/WFLY-3072
> Project: WildFly
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: Domain Management, Security
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Fix For: 8.0.1.Final
>
>
> I see the following scenarios to cover for this: -
> - Authentication - A search is performed e.g against 'uid' and a referral is encountered, the URL needs to be extracted from the referral and a new connection created using the referral URL to load any additional attributes for the user, the referral URL is then used to establish the connection as the user to verify that their password is correct.
> Group loading then has a couple of issues, firstly where the user was a referral.
> The search for group membership information is a fresh start but now we potentially have 2 simple named and 2 distinguished names that could be referenced from the group object. We may want a config option to specify which one to actually use and even possibly use both.
> Next could a group also be a referral, i.e. it contains the reference to the user as an attribute so was matched in the search but is also a referral to the true named group in another location. In this situation I suggest any iterative search takes into account the context containing the actual group definition and continues the search from there.
> And then where the principal contains an attribute that references, this one should be a simple following of a referral and once followed continue the attribute loading using the new connection.
> The connection manager logic is going to need reworking, ideally for a referral we should check if we have a connection definition that matches based on the URL returned otherwise we will need to try and establish a connection based on the settings of the last connection used, this probably also introduces a notion of some form of connection stack of the connections used for the current request - referrals could have us bouncing back and forth so connections should be cached and re-used where possible during authentication and group loading.
> * Connection Settings *
> We are going to need to support two different modes in relation to the 'java.naming.referral' property, follow and throw.
> - *follow* - In this mode when the InitialDirContext encounters a referral during a search it will automatically follow it, this means automatically connecting to the server in the URL. This is fine if the remaining connection settings are valid for the alternative server e.g. same bindDN and credential. We however need to take the following into account for subsequent operations such as password validation or further queries.
> - *throw* - When a referral is encountered and exception will be thrown instead, this mode should make it easier to have some more advanced referral handling logic that allows us control of which connection we subsequently use, e.g. we could not use a completely different host name to the one in the referral or use a different bind DN / credential pair.
--
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
12 years, 3 months