[JBoss JIRA] (JGRP-2088) ArrayIndexOutOfBoundsException on ClassConfigurator.get()
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2088?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2088:
--------------------------------
This is likely caused by a peer sending data in incorrect wire format (e.g. a different JGroups version). I don't want to change this, as catching the incorrect array access and returning a null class would lead to more problems further down the line.
A magic number should never be -1 or greater than the max-magic-number, so this exception does point to a problem and I want the user to see it.
> ArrayIndexOutOfBoundsException on ClassConfigurator.get()
> ---------------------------------------------------------
>
> Key: JGRP-2088
> URL: https://issues.jboss.org/browse/JGRP-2088
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.10
> Reporter: Manuel Dominguez Sarmiento
> Assignee: Bela Ban
> Fix For: 3.6.11, 4.0
>
> Attachments: jgroups.xml
>
>
> See the following stack trace:
> [ERROR] 2016-07-09 14:26:05 [UDP-multicast receiver,shared=jgroups-shared-transport] - JGRP000030: null: failed handling incoming message: java.lang.ArrayIndexOutOfBoundsException: -1
> java.lang.ArrayIndexOutOfBoundsException: -1
> at org.jgroups.conf.ClassConfigurator.get(ClassConfigurator.java:161)
> at org.jgroups.Message.readHeader(Message.java:936)
> at org.jgroups.Message.readFrom(Message.java:811)
> at org.jgroups.protocols.TP.handleSingleMessage(TP.java:1712)
> at org.jgroups.protocols.TP.receive(TP.java:1654)
> at org.jgroups.protocols.UDP$PacketReceiver.run(UDP.java:701)
> at java.lang.Thread.run(Thread.java:745)
> Stepping through the code with the debugger shows that the following line is failing at ClassConfigurator.get() with magic = -1 thus the java.lang.ArrayIndexOutOfBoundsException
> return magic < 1024 ? magicMap[magic] : (Class)magicMapUser.get(Short.valueOf(magic));
> See attached jgroups.xml for configuration. This showed up when upgrading to 3.6.10 from 3.6.8 which worked fine.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (JGRP-2088) ArrayIndexOutOfBoundsException on ClassConfigurator.get()
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2088?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-2088.
----------------------------
Resolution: Rejected
> ArrayIndexOutOfBoundsException on ClassConfigurator.get()
> ---------------------------------------------------------
>
> Key: JGRP-2088
> URL: https://issues.jboss.org/browse/JGRP-2088
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.10
> Reporter: Manuel Dominguez Sarmiento
> Assignee: Bela Ban
> Fix For: 3.6.11, 4.0
>
> Attachments: jgroups.xml
>
>
> See the following stack trace:
> [ERROR] 2016-07-09 14:26:05 [UDP-multicast receiver,shared=jgroups-shared-transport] - JGRP000030: null: failed handling incoming message: java.lang.ArrayIndexOutOfBoundsException: -1
> java.lang.ArrayIndexOutOfBoundsException: -1
> at org.jgroups.conf.ClassConfigurator.get(ClassConfigurator.java:161)
> at org.jgroups.Message.readHeader(Message.java:936)
> at org.jgroups.Message.readFrom(Message.java:811)
> at org.jgroups.protocols.TP.handleSingleMessage(TP.java:1712)
> at org.jgroups.protocols.TP.receive(TP.java:1654)
> at org.jgroups.protocols.UDP$PacketReceiver.run(UDP.java:701)
> at java.lang.Thread.run(Thread.java:745)
> Stepping through the code with the debugger shows that the following line is failing at ClassConfigurator.get() with magic = -1 thus the java.lang.ArrayIndexOutOfBoundsException
> return magic < 1024 ? magicMap[magic] : (Class)magicMapUser.get(Short.valueOf(magic));
> See attached jgroups.xml for configuration. This showed up when upgrading to 3.6.10 from 3.6.8 which worked fine.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (JGRP-2039) RpcDispatcher: async RPCs should be invoked immediately
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2039?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-2039 at 7/11/16 4:17 AM:
---------------------------------------------------------
Works as designed: when 5 RPCs which return futures are invoked, sometimes it took more than 5s for all futures to complete.
The reason was that messages in batches (even of OOB messages) were processed by a thread from the OOB thread pool one-by-one. There are 2 solutions to make this processing parallel:
# Use the Asynchronous Invocation API [1]
# Mark messages as {{OOB}} and {{DONT_BUNDLE}}. These messages are then extracted from the batch at the receiver and dispatched individually by separate OOB threads.
Unit test is {{RpcDispatcherTest.testMultipleFutures()}}
[1] http://www.jgroups.org/manual/index.html#AsyncInvocation
was (Author: belaban):
Works as designed: when 5 RPCs which return futures are invoked, sometimes it took more than 5s for all futures to complete.
The reason was that messages in batches (even of OOB messages) were processed by a thread from the OOB thread pool one-by-one. There are 2 solutions to make this processing parallel:
# one
# two
Unit test is {{RpcDispatcherTest.testMultipleFutures()}}
> RpcDispatcher: async RPCs should be invoked immediately
> -------------------------------------------------------
>
> Key: JGRP-2039
> URL: https://issues.jboss.org/browse/JGRP-2039
> Project: JGroups
> Issue Type: Bug
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0
>
>
> Invoking async RPCs in rapid succession on a method that sleeps for 5 secs should lead to getting all results after 5 secs.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (JGRP-2039) RpcDispatcher: async RPCs should be invoked immediately
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2039?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2039:
--------------------------------
Works as designed: when 5 RPCs which return futures are invoked, sometimes it took more than 5s for all futures to complete.
The reason was that messages in batches (even of OOB messages) were processed by a thread from the OOB thread pool one-by-one. There are 2 solutions to make this processing parallel:
# one
# two
Unit test is {{RpcDispatcherTest.testMultipleFutures()}}
> RpcDispatcher: async RPCs should be invoked immediately
> -------------------------------------------------------
>
> Key: JGRP-2039
> URL: https://issues.jboss.org/browse/JGRP-2039
> Project: JGroups
> Issue Type: Bug
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0
>
>
> Invoking async RPCs in rapid succession on a method that sleeps for 5 secs should lead to getting all results after 5 secs.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (WFLY-6781) Wildfly cluster's failover functionality doesn't work as expected
by Miroslav Novak (JIRA)
[ https://issues.jboss.org/browse/WFLY-6781?page=com.atlassian.jira.plugin.... ]
Miroslav Novak commented on WFLY-6781:
--------------------------------------
[~pkuruvil] Sorry for late response, I had a vacation. Thanks for trying the connection-ttl. You might be right it's Windows environment issue or VMWare networking issue among virtual machines. Maybe it would be worth to check node1 networking after power offing node2. Did it do something bad with Windows networking on node 1?
> Wildfly cluster's failover functionality doesn't work as expected
> -----------------------------------------------------------------
>
> Key: WFLY-6781
> URL: https://issues.jboss.org/browse/WFLY-6781
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 8.2.0.Final
> Reporter: Preeta Kuruvilla
> Assignee: Jeff Mesnil
> Priority: Blocker
> Attachments: domain.Node1.xml, host.Node1.xml, host.Node2.xml, server.RC.Node1.AfterFailover.log, server.RC.Node1.BeforeFailover.log, server.RC.Node2.AfterFailover.log, server.RC.Node2.BeforeFailover.log, server.SL.Node1.AfterFailover.log, server.SL.Node1.BeforeFailover.log
>
>
> Following are the testing scenarios we did and the outcome:-
> 1. Network disabling on a VM for testing failover – Not working for both Linux and Windows environment.
> 2. Power off of a VM using VMware client for testing failover – Is working on Linux environment but not working on windows environment.
> 3. Ctrl + C method to stop services on a node for testing failover – works on both linux and windows environment
> 4. Stopping server running on Node /VM using Admin Console for testing failover - works on both linux and windows environment.
> Jgroups subsystem configuration in domain.xml we have is below:-
> <subsystem xmlns="urn:jboss:domain:jgroups:2.0" default-stack="udp">
> <stack name="udp">
> <transport type="UDP" socket-binding="jgroups-udp"/>
> <protocol type="PING"/>
> <protocol type="MERGE3"/>
> <protocol type="FD_SOCK" socket-binding="jgroups-udp-fd"/>
> <protocol type="FD_ALL"/>
> <protocol type="VERIFY_SUSPECT"/>
> <protocol type="pbcast.NAKACK2"/>
> <protocol type="UNICAST3"/>
> <protocol type="pbcast.STABLE"/>
> <protocol type="pbcast.GMS"/>
> <protocol type="UFC"/>
> <protocol type="MFC"/>
> <protocol type="FRAG2"/>
> <protocol type="RSVP"/>
> </stack>
> <stack name="tcp">
> <transport type="TCP" socket-binding="jgroups-tcp"/>
> <protocol type="MPING" socket-binding="jgroups-mping"/>
> <protocol type="MERGE2"/>
> <protocol type="FD_SOCK" socket-binding="jgroups-tcp-fd"/>
> <protocol type="FD"/>
> <protocol type="VERIFY_SUSPECT"/>
> <protocol type="pbcast.NAKACK2"/>
> <protocol type="UNICAST3"/>
> <protocol type="pbcast.STABLE"/>
> <protocol type="pbcast.GMS"/>
> <protocol type="MFC"/>
> <protocol type="FRAG2"/>
> <protocol type="RSVP"/>
> </stack>
> </subsystem>
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (WFCORE-1645) Missing whitespace indent in module command help message
by Petr Kremensky (JIRA)
Petr Kremensky created WFCORE-1645:
--------------------------------------
Summary: Missing whitespace indent in module command help message
Key: WFCORE-1645
URL: https://issues.jboss.org/browse/WFCORE-1645
Project: WildFly Core
Issue Type: Bug
Components: CLI
Reporter: Petr Kremensky
Assignee: Jean-Francois Denise
Priority: Minor
https://github.com/jfdenise/wildfly-core/blob/c023b0bd21d35d8f96c5d99fe4a...
Whitespace indent is missing for --module-root-dir and --name options
{noformat}
ARGUMENTS
--module-root-dir - (optional) The absolute file path to the server's modules
directory. By default the module is added to (or removed from)
JBOSS_HOME/modules
--name - (required) the name of the module to be added or removed.
NOTE: slot is not a part of the module name.
--slot - (optional) specifies a slot which should be created or
removed. If this argument is not specified, "main" slot is
assumed.
...
{noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (WFLY-5739) Subject not populated with groups/roles when authenticated via JASPIC
by István Tóth (JIRA)
[ https://issues.jboss.org/browse/WFLY-5739?page=com.atlassian.jira.plugin.... ]
István Tóth commented on WFLY-5739:
-----------------------------------
Hello [~ggam] !
Thank you for your answer and the test case!
After looking at the problem some more, I have come to understand the following:
There are at least three mechansisms/places for storing the group/roles data:
* in JbossSecurityContext (used by most of WildFly, including EJBs)
* in the Subject's ROLES_IDENTIFIER principal (used at least by JACC, and also gets copied to to JbossSecurityContext)
* in the Undertow Account obejct (used by undertow, I guess)
JASPICallbackHandler.java in Picketbox only fills in the JbossSecurityContext.
JASPICAuthenticationMechanism.java in wildfly copies it to the Account, and optionally caches it.
My original PR tried to fix the JACC roles in picketbox's JASPICallbackHandler.java. However, due to registerSession feature, this bug cannot be fixed in Picketbox alone.
Instead of making essentially the same fix to two projects, I have tried a different approach, and chose to leave picketbox alone, and instead copy the group information to the ROLES_IDENTIFIER principal in wildfly's JASPICAuthenticationMechanism.java, where the group information is available both during full authentication, and registersession cached authentication.
I am hesitant to turn this into a pull request yet. Could you take a look at https://github.com/stoty/wildfly/commits/WFLY-5739 and tell me if it's a valid approach ?
> Subject not populated with groups/roles when authenticated via JASPIC
> ---------------------------------------------------------------------
>
> Key: WFLY-5739
> URL: https://issues.jboss.org/browse/WFLY-5739
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 10.0.0.CR4
> Reporter: Arjan t
> Assignee: Darran Lofthouse
> Labels: jacc, jaspic
> Attachments: CustomAuth.zip, picketbox.zip
>
>
> After having authenticated via JASPIC, requesting the current {{Subject}} via JACC and then using that for permission checks fails.
> For instance the following code will always set {{hasAccess}} to false given that "/protected/*" requires a role and the authenticated user is in that role:
> {code:java}
> Subject subject = (Subject) PolicyContext.getContext("javax.security.auth.Subject.container");
>
> boolean hasAccess = Policy.getPolicy().implies(
> new ProtectionDomain(
> new CodeSource(null, (Certificate[]) null),
> null, null,
> subject.getPrincipals().toArray(new Principal[subject.getPrincipals().size()])
> ),
> new WebResourcePermission("/protected/Servlet", "GET"))
> ;
> {code}
> As it appears, the problem originates from the fact that {{subject.getPrincipals()}} does not contain the roles.
> This can be traced back to {{org.jboss.security.auth.callback.JASPICallbackHandler.handleCallBack}}, where it becomes clear that the roles are only put into the "util", but not in the "authenticatedSubject":
> {code:java}
> String[] rolesArray = groupPrincipalCallback.getGroups();
> int sizeOfRoles = rolesArray != null ? rolesArray.length : 0;
>
> if( sizeOfRoles > 0 )
> {
> List<Role> rolesList = new ArrayList<Role>();
> for( int i = 0; i < sizeOfRoles ; i++ )
> {
> Role role = new SimpleRole( rolesArray[ i ] );
> rolesList.add( role );
> }
> RoleGroup roles = new SimpleRoleGroup( SecurityConstants.ROLES_IDENTIFIER, rolesList );
> // if the current security context already has roles, we merge them with the incoming roles.
> RoleGroup currentRoles = currentSC.getUtil().getRoles();
> // *** ROLES ARE ONLY SET HERE ***
> if (currentRoles != null) {
> currentRoles.addAll(roles.getRoles());
> }
> else {
> currentSC.getUtil().setRoles( roles );
> }
> }
> // *** BELOW THIS LINE ROLES ARE NOT REFERENCED ANYMORE
> // *** SUBJECT IS NOT POPULATED WITH ANY ROLE INFO
> Subject subject = groupPrincipalCallback.getSubject();
> if( subject != null )
> {
> // if the current security context already has an associated subject, we merge it with the incoming subject.
> Subject currentSubject = currentSC.getSubjectInfo().getAuthenticatedSubject();
> if (currentSubject != null) {
> subject.getPrincipals().addAll(currentSubject.getPrincipals());
> subject.getPublicCredentials().addAll(currentSubject.getPublicCredentials());
> subject.getPrivateCredentials().addAll(currentSubject.getPrivateCredentials());
> }
> currentSC.getSubjectInfo().setAuthenticatedSubject(subject);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months