[JBoss JIRA] (WFLY-976) Multi-JSF doesn't understand new modules structure
by Stan Silvert (JIRA)
[ https://issues.jboss.org/browse/WFLY-976?page=com.atlassian.jira.plugin.s... ]
Stan Silvert commented on WFLY-976:
-----------------------------------
I've attached the CLI install file for WildFly Alpha1 and MyFaces 2.1.11. Here are detailed instructions:
Download or build the latest AS8/WildFly
Copy install-myfaces-2.1.11.cli to wildfly-8.0.0.Alpha1-SNAPSHOT/bin
start AS8/WildFly
cd to wildfly-8.0.0.Alpha1-SNAPSHOT/bin
run cli and do these two commands:
[standalone@localhost:9999 /] deploy install-myfaces-2.1.11.cli
[standalone@localhost:9999 /] /subsystem=jsf/:write-attribute(name=default-jsf-impl-slot,value=myfaces-2.1.11)
Edit modules/system/layers/base/org/jboss/weld/core/main/modules.xml and change the JSF API slot to MyFaces:
<module name="javax.faces.api" slot="myfaces-2.1.11"/>
Do the same for modules/system/layers/base/org/jboss/as/weld/main/modules.xml
restart AS8/WildFly
Let me know how it goes!
> Multi-JSF doesn't understand new modules structure
> --------------------------------------------------
>
> Key: WFLY-976
> URL: https://issues.jboss.org/browse/WFLY-976
> Project: WildFly
> Issue Type: Bug
> Components: JSF
> Reporter: Stan Silvert
> Assignee: Stan Silvert
> Attachments: install-myfaces-2.1.11.cli
>
>
> With the new modules structure, Multi-JSF is looking for JSF implementations in the root of the modules directory instead of in modules/system/layers/base. The reason is that Multi-JSF relies on the module.path property which points to the root by default.
> The workaround is to go ahead and install the new JSF impl wherever you wish and add that directory to JBOSS_MODULEPATH in the startup script.
> See https://community.jboss.org/wiki/DesignOfAS7Multi-JSFFeature#comment-11789
--
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
11 years, 8 months
[JBoss JIRA] (SECURITY-734) Slow policy evaluation with a large number of policy sets
by Anil Saldhana (JIRA)
[ https://issues.jboss.org/browse/SECURITY-734?page=com.atlassian.jira.plug... ]
Anil Saldhana commented on SECURITY-734:
----------------------------------------
[~zinal] I like github because contributions such as yours is easier to merge into the project. Thanks a lot for the contribution. :)
> Slow policy evaluation with a large number of policy sets
> ---------------------------------------------------------
>
> Key: SECURITY-734
> URL: https://issues.jboss.org/browse/SECURITY-734
> Project: PicketBox
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Affects Versions: picketbox_xacml_2.0.8.Final
> Environment: RedHat Linux 6.0, WebSphere Application Server 7.0
> Reporter: Maxim Zinal
> Assignee: Anil Saldhana
> Fix For: picketbox_xacml_2.0.9.Final
>
> Attachments: fix-734.patch
>
>
> We suffer a performance problem in the evaluation of large XACML configuration. We use JBoss (Sun?) XACML library to process a large number of policy sets (over 2400 policy set files) using "deny-override" combining algorithm.
> Initially the number of policies was relatively small, but it increased with time, leading to performance degradation, with 100% CPU (single)core consumption.
> After running a code sample under Java profiler, we found that 99% of time is spent in method PolicySetFinderModule.findPolicy(URI, int, VersionConstraints, PolicyMetaData).
> This method walks through a list of AbstractPolicy objects, comparing an ID of each object with it's first argument. In our configuration the number of such objects is relatively large, leading to slow execution with high CPU consumption.
> We suggest replacing the list of AbstractPolicy with a HashMap. Our experiments show that total evaluation time reduces ~50 times with a HashMap over List implementation.
--
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
11 years, 8 months
[JBoss JIRA] (SECURITY-734) Slow policy evaluation with a large number of policy sets
by Anil Saldhana (JIRA)
[ https://issues.jboss.org/browse/SECURITY-734?page=com.atlassian.jira.plug... ]
Anil Saldhana updated SECURITY-734:
-----------------------------------
Fix Version/s: picketbox_xacml_2.0.9.Final
Affects Version/s: picketbox_xacml_2.0.8.Final
> Slow policy evaluation with a large number of policy sets
> ---------------------------------------------------------
>
> Key: SECURITY-734
> URL: https://issues.jboss.org/browse/SECURITY-734
> Project: PicketBox
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Affects Versions: picketbox_xacml_2.0.8.Final
> Environment: RedHat Linux 6.0, WebSphere Application Server 7.0
> Reporter: Maxim Zinal
> Assignee: Anil Saldhana
> Fix For: picketbox_xacml_2.0.9.Final
>
> Attachments: fix-734.patch
>
>
> We suffer a performance problem in the evaluation of large XACML configuration. We use JBoss (Sun?) XACML library to process a large number of policy sets (over 2400 policy set files) using "deny-override" combining algorithm.
> Initially the number of policies was relatively small, but it increased with time, leading to performance degradation, with 100% CPU (single)core consumption.
> After running a code sample under Java profiler, we found that 99% of time is spent in method PolicySetFinderModule.findPolicy(URI, int, VersionConstraints, PolicyMetaData).
> This method walks through a list of AbstractPolicy objects, comparing an ID of each object with it's first argument. In our configuration the number of such objects is relatively large, leading to slow execution with high CPU consumption.
> We suggest replacing the list of AbstractPolicy with a HashMap. Our experiments show that total evaluation time reduces ~50 times with a HashMap over List implementation.
--
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
11 years, 8 months
[JBoss JIRA] (SECURITY-734) Slow policy evaluation with a large number of policy sets
by Anil Saldhana (JIRA)
[ https://issues.jboss.org/browse/SECURITY-734?page=com.atlassian.jira.plug... ]
Anil Saldhana resolved SECURITY-734.
------------------------------------
Resolution: Done
> Slow policy evaluation with a large number of policy sets
> ---------------------------------------------------------
>
> Key: SECURITY-734
> URL: https://issues.jboss.org/browse/SECURITY-734
> Project: PicketBox
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Affects Versions: picketbox_xacml_2.0.8.Final
> Environment: RedHat Linux 6.0, WebSphere Application Server 7.0
> Reporter: Maxim Zinal
> Assignee: Anil Saldhana
> Fix For: picketbox_xacml_2.0.9.Final
>
> Attachments: fix-734.patch
>
>
> We suffer a performance problem in the evaluation of large XACML configuration. We use JBoss (Sun?) XACML library to process a large number of policy sets (over 2400 policy set files) using "deny-override" combining algorithm.
> Initially the number of policies was relatively small, but it increased with time, leading to performance degradation, with 100% CPU (single)core consumption.
> After running a code sample under Java profiler, we found that 99% of time is spent in method PolicySetFinderModule.findPolicy(URI, int, VersionConstraints, PolicyMetaData).
> This method walks through a list of AbstractPolicy objects, comparing an ID of each object with it's first argument. In our configuration the number of such objects is relatively large, leading to slow execution with high CPU consumption.
> We suggest replacing the list of AbstractPolicy with a HashMap. Our experiments show that total evaluation time reduces ~50 times with a HashMap over List implementation.
--
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
11 years, 8 months
[JBoss JIRA] (SECURITY-734) Slow policy evaluation with a large number of policy sets
by Maxim Zinal (JIRA)
[ https://issues.jboss.org/browse/SECURITY-734?page=com.atlassian.jira.plug... ]
Maxim Zinal commented on SECURITY-734:
--------------------------------------
Created a pull request. How strange and ugly that git is, uh... :(
Poor Linux developers.
> Slow policy evaluation with a large number of policy sets
> ---------------------------------------------------------
>
> Key: SECURITY-734
> URL: https://issues.jboss.org/browse/SECURITY-734
> Project: PicketBox
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Environment: RedHat Linux 6.0, WebSphere Application Server 7.0
> Reporter: Maxim Zinal
> Assignee: Anil Saldhana
> Attachments: fix-734.patch
>
>
> We suffer a performance problem in the evaluation of large XACML configuration. We use JBoss (Sun?) XACML library to process a large number of policy sets (over 2400 policy set files) using "deny-override" combining algorithm.
> Initially the number of policies was relatively small, but it increased with time, leading to performance degradation, with 100% CPU (single)core consumption.
> After running a code sample under Java profiler, we found that 99% of time is spent in method PolicySetFinderModule.findPolicy(URI, int, VersionConstraints, PolicyMetaData).
> This method walks through a list of AbstractPolicy objects, comparing an ID of each object with it's first argument. In our configuration the number of such objects is relatively large, leading to slow execution with high CPU consumption.
> We suggest replacing the list of AbstractPolicy with a HashMap. Our experiments show that total evaluation time reduces ~50 times with a HashMap over List implementation.
--
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
11 years, 8 months
[JBoss JIRA] (SECURITY-738) XACML DatabaseResourceAttributeLocator fails when used with Oracle 11g Driver
by Anil Saldhana (JIRA)
[ https://issues.jboss.org/browse/SECURITY-738?page=com.atlassian.jira.plug... ]
Anil Saldhana commented on SECURITY-738:
----------------------------------------
Please feel free to fork https://github.com/picketbox/security-xacml and submit a pull request.
> XACML DatabaseResourceAttributeLocator fails when used with Oracle 11g Driver
> -----------------------------------------------------------------------------
>
> Key: SECURITY-738
> URL: https://issues.jboss.org/browse/SECURITY-738
> Project: PicketBox
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JBossXACML
> Affects Versions: picketbox_xacml_2.0.8.Final
> Environment: EAP 6.0.1
> Reporter: Hisanobu Okuda
> Assignee: Anil Saldhana
>
> We are using the DatabaseResourceAttributeLocator in jboss-xacml 2.0.8.Final for fetching a policy attribute from an Oracle 11g database. The Oracle JDBC driver is ojdbc6 11.2.0.x. However, the locator fails with an SQLException. The complete stacktrace is attached, but the interesting part is the following:
> {code}
> Caused by: java.sql.SQLException: error occurred during batching: batch must be either executed or cleared
> at oracle.jdbc.driver.OraclePreparedStatement.executeInternal(OraclePreparedStatement.java:3435)
> at oracle.jdbc.driver.OraclePreparedStatement.executeQuery(OraclePreparedStatement.java:3493)
> at oracle.jdbc.driver.OraclePreparedStatementWrapper.executeQuery(OraclePreparedStatementWrapper.java:1491)
> at org.jboss.security.xacml.locators.attrib.DatabaseAttributeLocator.getColumnValue(DatabaseAttributeLocator.java:215)
> ... 48 more
> {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
11 years, 8 months
[JBoss JIRA] (SECURITY-734) Slow policy evaluation with a large number of policy sets
by Anil Saldhana (JIRA)
[ https://issues.jboss.org/browse/SECURITY-734?page=com.atlassian.jira.plug... ]
Anil Saldhana commented on SECURITY-734:
----------------------------------------
[~zinal] please feel free to fork https://github.com/picketbox/security-xacml and submit a pull request.
> Slow policy evaluation with a large number of policy sets
> ---------------------------------------------------------
>
> Key: SECURITY-734
> URL: https://issues.jboss.org/browse/SECURITY-734
> Project: PicketBox
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Environment: RedHat Linux 6.0, WebSphere Application Server 7.0
> Reporter: Maxim Zinal
> Assignee: Anil Saldhana
> Attachments: fix-734.patch
>
>
> We suffer a performance problem in the evaluation of large XACML configuration. We use JBoss (Sun?) XACML library to process a large number of policy sets (over 2400 policy set files) using "deny-override" combining algorithm.
> Initially the number of policies was relatively small, but it increased with time, leading to performance degradation, with 100% CPU (single)core consumption.
> After running a code sample under Java profiler, we found that 99% of time is spent in method PolicySetFinderModule.findPolicy(URI, int, VersionConstraints, PolicyMetaData).
> This method walks through a list of AbstractPolicy objects, comparing an ID of each object with it's first argument. In our configuration the number of such objects is relatively large, leading to slow execution with high CPU consumption.
> We suggest replacing the list of AbstractPolicy with a HashMap. Our experiments show that total evaluation time reduces ~50 times with a HashMap over List implementation.
--
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
11 years, 8 months
[JBoss JIRA] (JGRP-1618) missingMessageReceived() never called in NAKACK resulting in memory leak
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1618?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-1618.
----------------------------
Resolution: Won't Fix
See my comment on the case
> missingMessageReceived() never called in NAKACK resulting in memory leak
> ------------------------------------------------------------------------
>
> Key: JGRP-1618
> URL: https://issues.jboss.org/browse/JGRP-1618
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 2.8.1, 2.12.2
> Environment: Java 6
> Reporter: Harry Mark
> Assignee: Bela Ban
> Fix For: 3.2.9, 3.3
>
> Attachments: NakReceiverWindow.java
>
>
> We are using JGroups 2.8.1 and encountered a memory leak where it eventually ran out of CMS Old Gen memory. The heap dump revealed that the problem was in the xmit_stats ConcurrentHashMap of org.jgroups.protocols.pbcast.NAKACK.
> After much analysis here's what we found: when the system is under load, messages can start arriving out of order. When the receiver receives a higher sequence number than expected, it requests the sender retransmit the missing messages with the lower sequence numbers. The sender sends the missing message, however the bug in the NakReceiverWindow meant that the missing message was never purged from the Map that tracks missing messages (xmit_stats) because missingMessageReceived() was never invoked. Over time this Map grows and starts using up CMS Old Gen; the only way it would get reduced was when a server left the cluster and the missing messages were purged for that server.
> In JMX, the MissingMsgsReceived attribute of jgroups:cluster=*,protocol=NAKACK,type=protocol was always zero, confirming that it never purged any received "missing messages".
> When I looked at the most recent GA version 3.2.8 of NakReceiverWindow.java , it has the corrected logic that ensures that missingMessageReceived() is called. I checked the the most recent 2.x, which is 2.12.2, and found it also has the same bug in the logic as 2.8.1. This bug may apply to other 2.x but I did not check.
> Attached is the fixed NakReceiverWindow.java for 2.8.1.
> After applying the patch, the memory leak went away.
--
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
11 years, 8 months
[JBoss JIRA] (JGRP-1618) missingMessageReceived() never called in NAKACK resulting in memory leak
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1618?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1618:
--------------------------------
Hi Harry,
excellent analysis, you really did dig through the code didn't you !
However, I'm afraid I don't support 2.8.x or 2.12.x any longer, see [1] for reasons. I suggest you use this patch in a local build of 2.8.x and upgrade to a more recent version at some later point in time.
I also don't see any implementations of missingMessageReceived() in master. Besides, NakReceiverWindow has been replaced by Table and is only used in NAKACK. Note that NAKACK has been superceeded by NAKACK2, see my blog post on the diffs.
Had this been a bug that's also present in master or the 3.2 branch, I'd have fixed it, but xmit_stats was removed some time ago.
[1] https://community.jboss.org/docs/DOC-14454
> missingMessageReceived() never called in NAKACK resulting in memory leak
> ------------------------------------------------------------------------
>
> Key: JGRP-1618
> URL: https://issues.jboss.org/browse/JGRP-1618
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 2.8.1, 2.12.2
> Environment: Java 6
> Reporter: Harry Mark
> Assignee: Bela Ban
> Fix For: 3.2.9, 3.3
>
> Attachments: NakReceiverWindow.java
>
>
> We are using JGroups 2.8.1 and encountered a memory leak where it eventually ran out of CMS Old Gen memory. The heap dump revealed that the problem was in the xmit_stats ConcurrentHashMap of org.jgroups.protocols.pbcast.NAKACK.
> After much analysis here's what we found: when the system is under load, messages can start arriving out of order. When the receiver receives a higher sequence number than expected, it requests the sender retransmit the missing messages with the lower sequence numbers. The sender sends the missing message, however the bug in the NakReceiverWindow meant that the missing message was never purged from the Map that tracks missing messages (xmit_stats) because missingMessageReceived() was never invoked. Over time this Map grows and starts using up CMS Old Gen; the only way it would get reduced was when a server left the cluster and the missing messages were purged for that server.
> In JMX, the MissingMsgsReceived attribute of jgroups:cluster=*,protocol=NAKACK,type=protocol was always zero, confirming that it never purged any received "missing messages".
> When I looked at the most recent GA version 3.2.8 of NakReceiverWindow.java , it has the corrected logic that ensures that missingMessageReceived() is called. I checked the the most recent 2.x, which is 2.12.2, and found it also has the same bug in the logic as 2.8.1. This bug may apply to other 2.x but I did not check.
> Attached is the fixed NakReceiverWindow.java for 2.8.1.
> After applying the patch, the memory leak went away.
--
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
11 years, 8 months