[JBoss JIRA] (WFLY-1624) Web Console: SecurityContext facilities and integration with the core framework
by Heiko Braun (JIRA)
Heiko Braun created WFLY-1624:
---------------------------------
Summary: Web Console: SecurityContext facilities and integration with the core framework
Key: WFLY-1624
URL: https://issues.jboss.org/browse/WFLY-1624
Project: WildFly
Issue Type: Feature Request
Components: Web Console
Reporter: Heiko Braun
Assignee: Heiko Braun
We need:
- service that provides the security context per place
- gate keeper implementation that creates the secuirty context (or rejects access)
- API for declaring security related meta data (@RequiredResources([<address,...>])) used with presenter declarations
--
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
[JBoss JIRA] (WFLY-1624) Web Console: SecurityContext facilities and integration with the core framework
by Heiko Braun (JIRA)
[ https://issues.jboss.org/browse/WFLY-1624?page=com.atlassian.jira.plugin.... ]
Heiko Braun updated WFLY-1624:
------------------------------
Description:
We need:
- service that provides the security context per place
- gate keeper implementation that creates the security context (or rejects access)
- API for declaring security related meta data (@RequiredResources([<address,...>])) used with presenter declarations
was:
We need:
- service that provides the security context per place
- gate keeper implementation that creates the secuirty context (or rejects access)
- API for declaring security related meta data (@RequiredResources([<address,...>])) used with presenter declarations
> Web Console: SecurityContext facilities and integration with the core framework
> -------------------------------------------------------------------------------
>
> Key: WFLY-1624
> URL: https://issues.jboss.org/browse/WFLY-1624
> Project: WildFly
> Issue Type: Feature Request
> Components: Web Console
> Reporter: Heiko Braun
> Assignee: Heiko Braun
>
> We need:
> - service that provides the security context per place
> - gate keeper implementation that creates the security context (or rejects access)
> - API for declaring security related meta data (@RequiredResources([<address,...>])) used with presenter declarations
--
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
[JBoss JIRA] (JGRP-1644) NAKACK2 violates FIFO property
by Vadim Tsesko (JIRA)
[ https://issues.jboss.org/browse/JGRP-1644?page=com.atlassian.jira.plugin.... ]
Vadim Tsesko commented on JGRP-1644:
------------------------------------
It seems that you are right. We have rather big messages and fragmentation is necessary and at the same time many fragments are redelivered because of network flaps between datacenters.
I can test against the new version of JGroups, but I am not able to put some JAR into the project. Can you publish Maven artifact -- something like {{jgroups-3.3-SNAPSHOT}} to http://search.maven.org? I can't compile Maven artifact from {{3.3}} branch myself:
{code}
~/devel/JGroups$ mvn compile
[INFO] Scanning for projects...
[WARNING]
[WARNING] Some problems were encountered while building the effective model for org.jgroups:jgroups:bundle:3.3.2.Final
[WARNING] 'build.plugins.plugin.version' for org.apache.felix:maven-bundle-plugin is missing. @ line 242, column 21
[WARNING] 'build.plugins.plugin.version' for org.apache.maven.plugins:maven-compiler-plugin is missing. @ line 131, column 21
[WARNING] 'build.plugins.plugin.version' for org.apache.maven.plugins:maven-jar-plugin is missing. @ line 233, column 21
[WARNING]
[WARNING] It is highly recommended to fix these problems because they threaten the stability of your build.
[WARNING]
[WARNING] For this reason, future Maven versions might no longer support building such malformed projects.
[WARNING]
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building JGroups 3.3.2.Final
[INFO] ------------------------------------------------------------------------
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 0.877s
[INFO] Finished at: Tue Jul 02 14:02:26 MSK 2013
[INFO] Final Memory: 8M/127M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal on project jgroups: Could not resolve dependencies for project org.jgroups:jgroups:bundle:3.3.2.Final: Could not find artifact com.sun:tools:jar:1.6 at specified path /Library/Java/JavaVirtualMachines/jdk1.7.0_25.jdk/Contents/Home/jre/../Classes/classes.jar -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/DependencyResolutionExce...
{code}
> NAKACK2 violates FIFO property
> ------------------------------
>
> Key: JGRP-1644
> URL: https://issues.jboss.org/browse/JGRP-1644
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.3.1
> Environment: Ubuntu 12.04 LTS, kernel 3.2.0-24-generic #39-Ubuntu SMP Mon May 21 16:52:17 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux, Java 1.7.0_21
> Reporter: Vadim Tsesko
> Assignee: Bela Ban
> Fix For: 3.4
>
> Attachments: TCP-NAKACK2.png, UDP-NAKACK2-NAKACK.png
>
>
> In the [documentation documentation|http://www.jgroups.org/manual/html/protlist.html#ReliableMe...] it is stated that:
> {quote}
> NAKACK provides reliable delivery and FIFO (= First In First Out) properties for messages sent to all nodes in a cluster.
> {quote}
> and
> {quote}
> NAKACK2 was introduced in 3.1 and is a successor to NAKACK (at some point it will replace NAKACK). It has the same properties as NAKACK, but its implementation is faster and uses less memory, plus it creates fewer tasks in the timer.
> {quote}
> I have observed that sometimes multicast messages are received out of order.
> We use the following protocol stack configuration:
> {code:xml}
> <config xmlns="urn:org:jgroups"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="urn:org:jgroups http://www.jgroups.org/schema/JGroups-3.3.xsd">
> <UDP bind_addr="match-interface:$interface"
> bind_interface="$interface"
> bind_port="$unicastPort"
> ip_ttl="128"
> mcast_addr="$multicastGroup"
> mcast_port="$multicastPort"
> singleton_name="udp-transport"/>
> <PING return_entire_cache="true"
> break_on_coord_rsp="false"/>
> <MERGE3/>
> <FD_SOCK/>
> <FD_ALL/>
> <VERIFY_SUSPECT/>
> <BARRIER/>
> <pbcast.NAKACK print_stability_history_on_failed_xmit="true"/>
> <pbcast.STABLE/>
> <pbcast.GMS/>
> <MFC max_credits="8M"/>
> <FRAG2/>
> <RSVP/>
> </config>
> {code}
> As you can see, mostly we use the defaults.
> The messages are being sent from a single thread using the following code:
> {code:java}
> channel.send(new Message(null, msg))
> {code}
> Each message has size from 300 KB up to 4 MB. The message rate is 1-5 messages per second.
> We have a sequential counter inside each message being sent. Sometimes the messages are received out of order, for instance:
> {code}
> #1198
> #1199
> #1200
> #1202
> #1201
> #1203
> #1204
> {code}
> If we replace {{NAKACK2}} by {{NAKACK}} the problem disappears -- everything works as expected (FIFO).
> If we replace JGroups-based transport by ZeroMQ-based transport (actually running over EPGM and being used for a year) everything works as expected (FIFO) -- just to let you know, that there are no bugs in out message numbering logic.
--
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
[JBoss JIRA] (JGRP-1644) NAKACK2 violates FIFO property
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1644?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1644:
--------------------------------
FragTest.testOrdering() reproduces the bug. This was fixed on master and 3.3.
Can you run your test again with a JGroups JAR produced from the 3.3 or master branch, to see if JGRP-1648 fixes the issue ?
> NAKACK2 violates FIFO property
> ------------------------------
>
> Key: JGRP-1644
> URL: https://issues.jboss.org/browse/JGRP-1644
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.3.1
> Environment: Ubuntu 12.04 LTS, kernel 3.2.0-24-generic #39-Ubuntu SMP Mon May 21 16:52:17 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux, Java 1.7.0_21
> Reporter: Vadim Tsesko
> Assignee: Bela Ban
> Fix For: 3.4
>
> Attachments: TCP-NAKACK2.png, UDP-NAKACK2-NAKACK.png
>
>
> In the [documentation documentation|http://www.jgroups.org/manual/html/protlist.html#ReliableMe...] it is stated that:
> {quote}
> NAKACK provides reliable delivery and FIFO (= First In First Out) properties for messages sent to all nodes in a cluster.
> {quote}
> and
> {quote}
> NAKACK2 was introduced in 3.1 and is a successor to NAKACK (at some point it will replace NAKACK). It has the same properties as NAKACK, but its implementation is faster and uses less memory, plus it creates fewer tasks in the timer.
> {quote}
> I have observed that sometimes multicast messages are received out of order.
> We use the following protocol stack configuration:
> {code:xml}
> <config xmlns="urn:org:jgroups"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="urn:org:jgroups http://www.jgroups.org/schema/JGroups-3.3.xsd">
> <UDP bind_addr="match-interface:$interface"
> bind_interface="$interface"
> bind_port="$unicastPort"
> ip_ttl="128"
> mcast_addr="$multicastGroup"
> mcast_port="$multicastPort"
> singleton_name="udp-transport"/>
> <PING return_entire_cache="true"
> break_on_coord_rsp="false"/>
> <MERGE3/>
> <FD_SOCK/>
> <FD_ALL/>
> <VERIFY_SUSPECT/>
> <BARRIER/>
> <pbcast.NAKACK print_stability_history_on_failed_xmit="true"/>
> <pbcast.STABLE/>
> <pbcast.GMS/>
> <MFC max_credits="8M"/>
> <FRAG2/>
> <RSVP/>
> </config>
> {code}
> As you can see, mostly we use the defaults.
> The messages are being sent from a single thread using the following code:
> {code:java}
> channel.send(new Message(null, msg))
> {code}
> Each message has size from 300 KB up to 4 MB. The message rate is 1-5 messages per second.
> We have a sequential counter inside each message being sent. Sometimes the messages are received out of order, for instance:
> {code}
> #1198
> #1199
> #1200
> #1202
> #1201
> #1203
> #1204
> {code}
> If we replace {{NAKACK2}} by {{NAKACK}} the problem disappears -- everything works as expected (FIFO).
> If we replace JGroups-based transport by ZeroMQ-based transport (actually running over EPGM and being used for a year) everything works as expected (FIFO) -- just to let you know, that there are no bugs in out message numbering logic.
--
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
[JBoss JIRA] (WFLY-1623) Access Control: read-children-resources
by Heiko Braun (JIRA)
[ https://issues.jboss.org/browse/WFLY-1623?page=com.atlassian.jira.plugin.... ]
Heiko Braun commented on WFLY-1623:
-----------------------------------
hbraun: the op permissions come from the parent, but the resource permission of each child need to be taken into consideration
[11:30am] kkhan: I think it would need read permission for the parent
[11:31am] hbraun: what if: read parent=false, read-child=true?
[11:31am] kkhan: and then if you don't have access permission to the child type, you get an empty list of children
[11:31am] hbraun: ok, so it boils down from the parent ?
[11:32am] kkhan: and if you don't have read access to the child type you get a list of children, but with the resourecs not 'filled in'
[11:32am] kkhan: hbraun: I think read parent=false, read-child=true would be a configuration error
[11:32am] hbraun: i was thinking if you don't have access to the parent, you cannot execute the op in the first place, right?
[11:32am] kkhan: Yeah, I think so
[11:33am] hbraun: becasue the op handler resdides (logically) with the parent
[11:33am] hbraun: ok, then we are on the same page
> Access Control: read-children-resources
> ---------------------------------------
>
> Key: WFLY-1623
> URL: https://issues.jboss.org/browse/WFLY-1623
> Project: WildFly
> Issue Type: Clarification
> Reporter: Heiko Braun
>
> What priviledges apply to a read-children-resources operation? The ones of the parent resource or the ones for each child resource?
--
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
[JBoss JIRA] (JGRP-1648) FRAG/FRAG2: message batching can lead to incorrect ordering
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1648?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-1648.
----------------------------
Resolution: Done
Fixed on master and 3.3
> FRAG/FRAG2: message batching can lead to incorrect ordering
> -----------------------------------------------------------
>
> Key: JGRP-1648
> URL: https://issues.jboss.org/browse/JGRP-1648
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Critical
> Fix For: 3.3.3, 3.4
>
>
> The implementation of up(MessageBatch) in FRAG and FRAG2 is incorrect because messages reassmbled from fragments are re-inserted into the batch at the end rather than in the place of the fragments.
> Example: when we receive P1 P2 P3:1 P3:2 P3:3 and P4 (P3 was split into 3 fragments by sender P), then the resulting batch (see the code below) will be P1 P2 P4 P3, as the re-assembled message P3 is added to the *end* of the batch rather than re-inserted in-place.
> {code}
> public void up(MessageBatch batch) {
> for(Message msg: batch) {
> FragHeader hdr=(FragHeader)msg.getHeader(this.id);
> if(hdr != null) { // needs to be defragmented
> batch.remove(msg);
> Message assembled_msg=unfragment(msg,hdr);
> if(assembled_msg != null)
> batch.add(assembled_msg); // the newly added message will not get iterated over by the current iterator !
> }
> }
> if(!batch.isEmpty())
> up_prot.up(batch);
> }
> {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