[JBoss JIRA] (WFLY-6699) Custom principal is lost during remote ejb authentication
by Vlado Pakan (JIRA)
[ https://issues.jboss.org/browse/WFLY-6699?page=com.atlassian.jira.plugin.... ]
Vlado Pakan closed WFLY-6699.
-----------------------------
Resolution: Won't Fix
Downstream issue fixed by customer implementation.
> Custom principal is lost during remote ejb authentication
> ---------------------------------------------------------
>
> Key: WFLY-6699
> URL: https://issues.jboss.org/browse/WFLY-6699
> Project: WildFly
> Issue Type: Bug
> Components: EJB, Security
> Affects Versions: 10.0.0.Final
> Reporter: Vlado Pakan
> Assignee: Vlado Pakan
> Original Estimate: 1 week, 2 days
> Remaining Estimate: 1 week, 2 days
>
> A custom principal (instead of the JBoss provided SimplePrincipal class) is used to store the authenticated username in a custom login module. The custom principal class is lost when attempting to retrieve it from the subject from within a secured EJB. The custom principal is only lost if it is used to store the username instead of using the JBoss provided SimplePrincipal class. Other instances of the custom principal class are passed along successfully if they are storing something besides the username (SSN, CustomerID, etc).
> It looks like this is happening due to a change (introduced in 6.4.6) in the org.jboss.as.security.service.SimpleSecurityManager.authenticate method
> @@ -445,8 +408,11 @@ public class SimpleSecurityManager implements ServerSecurityManager
> { auditPrincipal = unauthenticatedIdentity.asPrincipal(); subject.getPrincipals().add(auditPrincipal); authenticated = true; + }
> else
> { + subject.getPrincipals().add(principal); }
> This change was associated with bz-921217.
> This only happens when the EJB is accessed from a remote standalone client. If the EJB is accessed from a secured web app (locally), then the custom principal is not lost.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (JGRP-2086) FD_SOCK is keep trying to create a new socket to the killed server
by Osamu Nagano (JIRA)
[ https://issues.jboss.org/browse/JGRP-2086?page=com.atlassian.jira.plugin.... ]
Osamu Nagano commented on JGRP-2086:
------------------------------------
This test scenario is to kill a set of servers, not a crash of a host. So FD_HOST is not triggered. I can't reproduce it too but the user is still reporting it several times. What kind of info should be collected to investigate this issue? Maybe we can ask them for it.
> FD_SOCK is keep trying to create a new socket to the killed server
> ------------------------------------------------------------------
>
> Key: JGRP-2086
> URL: https://issues.jboss.org/browse/JGRP-2086
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.3
> Environment: JDG 6.6.0 (jgroups-3.6.3.Final-redhat-4.jar)
> Reporter: Osamu Nagano
> Assignee: Bela Ban
> Fix For: 3.6.11, 4.0
>
>
> In most cases FD_SOCK can detect a killed server immediately. But for unknown reason, FD_SOCK is keep trying to create a new socket to the killed server. As a consequence, installing a new cluster view is delayed until FD_ALL is triggered.
> m04_n007_server.log is showing the behaviour. There is 28 nodes (4 machines (m03, ..., m06) and 7 nodes (n001, ..., n007) on each) and all nodes on m03 are killed at the same time on 15:07:34,543. FD_SOCK is keep trying to connect to a killed node saying "socket address for m03_n001/clustered could not be fetched, retrying".
> {noformat}
> [n007] 15:07:39,543 TRACE [org.jgroups.protocols.FD_SOCK] (Timer-8,shared=udp) m04_n007/clustered: broadcasting SUSPECT message (suspected_mbrs=[m03_n005/clustered, m03_n007/clustered])
> [n007] 15:07:39,544 TRACE [org.jgroups.protocols.FD_SOCK] (INT-20,shared=udp) m04_n007/clustered: received SUSPECT message from m04_n007/clustered: suspects=[m03_n005/clustered, m03_n007/clustered]
> [n007] 15:07:39,546 TRACE [org.jgroups.protocols.FD_SOCK] (FD_SOCK pinger,m04_n007/clustered) m04_n007/clustered: socket address for m03_n001/clustered could not be fetched, retrying
> [n007] 15:07:40,546 DEBUG [org.jgroups.protocols.FD_SOCK] (FD_SOCK pinger,m04_n007/clustered) m04_n007/clustered: ping_dest is m03_n001/clustered, pingable_mbrs=[m03_n001/clustered, m03_n002/clustered, m03_n003/clustered, m03_n004/clustered, m03_n006/clustered, m06_n001/clustered, m06_n002/clustered, m06_n003/clustered, m06_n004/clustered, m06_n005/clustered, m06_n006/clustered, m06_n007/clustered, m05_n001/clustered, m05_n002/clustered, m05_n003/clustered, m05_n004/clustered, m05_n005/clustered, m05_n006/clustered, m05_n007/clustered, m04_n001/clustered, m04_n002/clustered, m04_n003/clustered, m04_n004/clustered, m04_n005/clustered, m04_n006/clustered, m04_n007/clustered]
> [n007] 15:07:41,546 TRACE [org.jgroups.protocols.FD_SOCK] (FD_SOCK pinger,m04_n007/clustered) m04_n007/clustered: socket address for m03_n001/clustered could not be fetched, retrying
> [n007] 15:07:42,546 DEBUG [org.jgroups.protocols.FD_SOCK] (FD_SOCK pinger,m04_n007/clustered) m04_n007/clustered: ping_dest is m03_n001/clustered, pingable_mbrs=[m03_n001/clustered, m03_n002/clustered, m03_n003/clustered, m03_n004/clustered, m03_n006/clustered, m06_n001/clustered, m06_n002/clustered, m06_n003/clustered, m06_n004/clustered, m06_n005/clustered, m06_n006/clustered, m06_n007/clustered, m05_n001/clustered, m05_n002/clustered, m05_n003/clustered, m05_n004/clustered, m05_n005/clustered, m05_n006/clustered, m05_n007/clustered, m04_n001/clustered, m04_n002/clustered, m04_n003/clustered, m04_n004/clustered, m04_n005/clustered, m04_n006/clustered, m04_n007/clustered]
> [n007] 15:07:43,547 TRACE [org.jgroups.protocols.FD_SOCK] (FD_SOCK pinger,m04_n007/clustered) m04_n007/clustered: socket address for m03_n001/clustered could not be fetched, retrying
> ...
> [n007] 15:10:53,700 DEBUG [org.jgroups.protocols.FD_ALL] (Timer-26,shared=udp) haven't received a heartbeat from m03_n005/clustered for 200059 ms, adding it to suspect list
> {noformat}
> From the TRACE log, you can find an address cache of FD_SOCK has only 23 members.
> {noformat}
> [n007] 14:40:50,471 TRACE [org.jgroups.protocols.FD_SOCK] (FD_SOCK pinger,m04_n007/clustered) m04_n007/clustered: got cache from m03_n005/clustered: cache is {
> m04_n006/clustered=172.20.66.34:9945,
> m05_n005/clustered=172.20.66.35:9938,
> m06_n004/clustered=172.20.66.36:9931,
> m03_n007/clustered=172.20.66.33:9952,
> m05_n001/clustered=172.20.66.35:9910,
> m06_n005/clustered=172.20.66.36:9938,
> m05_n006/clustered=172.20.66.35:9945,
> m03_n005/clustered=172.20.66.33:9938,
> m05_n004/clustered=172.20.66.35:9931,
> m04_n003/clustered=172.20.66.34:9924,
> m04_n007/clustered=172.20.66.34:9952,
> m05_n002/clustered=172.20.66.35:9917,
> m05_n003/clustered=172.20.66.35:9924,
> m04_n004/clustered=172.20.66.34:9931,
> m06_n001/clustered=172.20.66.36:9910,
> m06_n007/clustered=172.20.66.36:9952,
> m04_n005/clustered=172.20.66.34:9938,
> m04_n001/clustered=172.20.66.34:9910,
> m05_n007/clustered=172.20.66.35:9952,
> m06_n002/clustered=172.20.66.36:9917,
> m06_n006/clustered=172.20.66.36:9945,
> m04_n002/clustered=172.20.66.34:9917,
> m06_n003/clustered=172.20.66.36:9924}
> {noformat}
> While pingable_mbrs has all 28 members which is from the current available cluster view.
> {noformat}
> [n007] 14:40:50,472 DEBUG [org.jgroups.protocols.FD_SOCK] (FD_SOCK pinger,m04_n007/clustered) m04_n007/clustered: ping_dest is m03_n005/clustered, pingable_mbrs=[
> m03_n005/clustered,
> m03_n007/clustered,
> m03_n001/clustered,
> m03_n002/clustered,
> m03_n003/clustered,
> m03_n004/clustered,
> m03_n006/clustered,
> m06_n001/clustered,
> m06_n002/clustered,
> m06_n003/clustered,
> m06_n004/clustered,
> m06_n005/clustered,
> m06_n006/clustered,
> m06_n007/clustered,
> m05_n001/clustered,
> m05_n002/clustered,
> m05_n003/clustered,
> m05_n004/clustered,
> m05_n005/clustered,
> m05_n006/clustered,
> m05_n007/clustered,
> m04_n001/clustered,
> m04_n002/clustered,
> m04_n003/clustered,
> m04_n004/clustered,
> m04_n005/clustered,
> m04_n006/clustered,
> m04_n007/clustered]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (JGRP-2043) Improve performance of Message#readHeader
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2043?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-2043 at 7/12/16 3:17 AM:
---------------------------------------------------------
This correlates with what Ralf observed in Munich: populate ClassConfigurator map with {{id|Constructor}} pairs rather than {{id|Class}} pairs.
was (Author: belaban):
This correlates with what Ralf observed in Munich: popupate ClassConfigurator map with {{id|Constructor}} pairs rather than {{id|Class}} pairs.
> Improve performance of Message#readHeader
> -----------------------------------------
>
> Key: JGRP-2043
> URL: https://issues.jboss.org/browse/JGRP-2043
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Sanne Grinovero
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 4.0
>
>
> A CPU hot spot highlighed by profiling via JFR:
> {noformat}Stack Trace Sample Count Percentage(%)
> java.lang.reflect.Constructor.newInstance(Object[]) 71 2.392
> java.lang.Class.newInstance() 71 2.392
> org.jgroups.Message.readHeader(DataInput) 71 2.392
> {noformat}
> I'd have expected the reflective constructor to perform well on a recent JVM, but apparently it's not in this case. A theory is that the {{Class}} type being unknown makes this code harder to optimise; needs to be looked into.
> It might be possible to patch the {{ClassConfigurator}} to provide instances of the required {{Header}} type rather than returning the class, and optimise that instead.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (JGRP-2043) Improve performance of Message#readHeader
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2043?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2043:
--------------------------------
[~sannegrinovero] Do you have the JMH test so I can try to reproduce this?
When warming up the JVM reflective, constructor and method-handle creations are about the same speed in my test...
> Improve performance of Message#readHeader
> -----------------------------------------
>
> Key: JGRP-2043
> URL: https://issues.jboss.org/browse/JGRP-2043
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Sanne Grinovero
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 4.0
>
>
> A CPU hot spot highlighed by profiling via JFR:
> {noformat}Stack Trace Sample Count Percentage(%)
> java.lang.reflect.Constructor.newInstance(Object[]) 71 2.392
> java.lang.Class.newInstance() 71 2.392
> org.jgroups.Message.readHeader(DataInput) 71 2.392
> {noformat}
> I'd have expected the reflective constructor to perform well on a recent JVM, but apparently it's not in this case. A theory is that the {{Class}} type being unknown makes this code harder to optimise; needs to be looked into.
> It might be possible to patch the {{ClassConfigurator}} to provide instances of the required {{Header}} type rather than returning the class, and optimise that instead.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (DROOLS-1226) Eclipse Plugin not working with Eclipse Neon 4.6
by Ganesh Subbanarasimhan (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1226?page=com.atlassian.jira.plugi... ]
Ganesh Subbanarasimhan commented on DROOLS-1226:
------------------------------------------------
I am a newbie to both Drools and Eclipse. It is not a great start. It will be great if this could be fixed. Thanks
> Eclipse Plugin not working with Eclipse Neon 4.6
> ------------------------------------------------
>
> Key: DROOLS-1226
> URL: https://issues.jboss.org/browse/DROOLS-1226
> Project: Drools
> Issue Type: Bug
> Components: eclipse plugin
> Affects Versions: 6.4.0.Final
> Reporter: Bernhard Mayer
> Assignee: Robert (Bob) Brodt
>
> The eclipse integration plugin stopped working properly with Eclipse Neon 4.6.
> When editing rules in the rules editor of a Drools Project the following error is produced for *any* rule:
> {panel:title=Error Message}
> Rule Compilation error Only a type can be imported. com.sample.DroolsTest.Message resolves to a package
> Only a type can be imported. org.drools.core.spi.KnowledgeHelper resolves to a package
> KnowledgeHelper cannot be resolved to a type
> org.kie.api.runtime.rule.FactHandle cannot be resolved to a type
> java.lang.Exception cannot be resolved to a type
> org.kie.api.runtime.rule.RuleContext cannot be resolved to a type
> {panel}
> The Plugin works fine with Eclipse Mars 4.5 and earlier releases.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months