[JBoss JIRA] (ELY-587) SSLContext integration into DirContext supplier service
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-587?page=com.atlassian.jira.plugin.sy... ]
Jan Kalina updated ELY-587:
---------------------------
Component/s: (was: Realms)
Description:
* we already have a resource to define the SSLContext
* we want use it for connection to LDAP
* new resource should return an ExceptionSupplier<DirContext>
* new resource should reference SSLContext resource / capability
was:
* we have a resource to define the SSLContext
* we want a way to wire it in so it is used for connection to LDAP
* new resource should return an ExceptionSupplier<DirContext>
* new resource should reference SSLContext resource / capability
Summary: SSLContext integration into DirContext supplier service (was: SSLContext from Elytron subsystem in LDAP realm)
> SSLContext integration into DirContext supplier service
> -------------------------------------------------------
>
> Key: ELY-587
> URL: https://issues.jboss.org/browse/ELY-587
> Project: WildFly Elytron
> Issue Type: Task
> Components: SSL
> Reporter: Jan Kalina
> Assignee: Jan Kalina
>
> * we already have a resource to define the SSLContext
> * we want use it for connection to LDAP
> * new resource should return an ExceptionSupplier<DirContext>
> * new resource should reference SSLContext resource / capability
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (JGRP-2042) Improve performance of Message#writeHeader
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2042?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2042:
---------------------------
Fix Version/s: 3.6.11
> Improve performance of Message#writeHeader
> ------------------------------------------
>
> Key: JGRP-2042
> URL: https://issues.jboss.org/browse/JGRP-2042
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Sanne Grinovero
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 3.6.11, 4.0
>
>
> The following stacktrace, taken with JFR, is highlighting a CPU consumer which could be optimised.
> {noformat}Stack Trace Sample Count Percentage(%)
> java.util.IdentityHashMap.get(Object) 66 2.224
> org.jgroups.conf.ClassConfigurator.getMagicNumber(Class) 66 2.224
> org.jgroups.Message.writeHeader(Header, DataOutput) 66 2.224
> {noformat}
> One idea could be to use an ad-hoc implementation of Map which takes advantage of the key being a {{Class}}. An interesting alternative would be to avoid the map lookup altogether, by having the Header expose a method like "writeMagicNumber(DataInput to)".
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (ELY-587) SSLContext from Elytron subsystem in LDAP realm
by Jan Kalina (JIRA)
Jan Kalina created ELY-587:
------------------------------
Summary: SSLContext from Elytron subsystem in LDAP realm
Key: ELY-587
URL: https://issues.jboss.org/browse/ELY-587
Project: WildFly Elytron
Issue Type: Task
Components: Realms, SSL
Reporter: Jan Kalina
Assignee: Jan Kalina
* we have a resource to define the SSLContext
* we want a way to wire it in so it is used for connection to LDAP
* new resource should return an ExceptionSupplier<DirContext>
* new resource should reference SSLContext resource / capability
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 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 resolved JGRP-2043.
----------------------------
Resolution: Done
The JMH test showed that average performance of header creation dropped from ~300ns (previous reflection-based approach) to ~25ns with the {{Constructable}} approach. This is almost the same as calling the constructor directly.
> 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, 9 months
[JBoss JIRA] (ELY-405) Add a KeyStore implementation backed by LDAP
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-405?page=com.atlassian.jira.plugin.sy... ]
Jan Kalina edited comment on ELY-405 at 7/13/16 7:50 AM:
---------------------------------------------------------
>From [http://www.tldp.org/HOWTO/archived/LDAP-Implementation-HOWTO/certificates...]:
* The certificationAuthority objectclass implements the authorityRevocationList, certificateRevocationList and cACertificate attributes.
* The *inetOrgPerson* objectclass supports the *usercertificate* (binary) attribute.
* You can also use the mix-in objectclass strongAuthenticationUser to add certificates to non inetOrgPerson entries.
was (Author: honza889):
>From [http://www.tldp.org/HOWTO/archived/LDAP-Implementation-HOWTO/certificates...]:
* The certificationAuthority objectclass implements the authorityRevocationList, certificateRevocationList and cACertificate attributes.
* The inetOrgPerson objectclass supports the usercertificate (binary) attribute.
* You can also use the mix-in objectclass strongAuthenticationUser to add certificates to non inetOrgPerson entries.
> Add a KeyStore implementation backed by LDAP
> --------------------------------------------
>
> Key: ELY-405
> URL: https://issues.jboss.org/browse/ELY-405
> Project: WildFly Elytron
> Issue Type: Feature Request
> Components: SSL
> Reporter: Darran Lofthouse
> Assignee: Jan Kalina
> Fix For: 2.0.0.Alpha1
>
>
> It is possible for private keys, public keys and certificates to all be stored in LDAP - this task is to create a Java KeyStore implementation that can work with this.
> LDAP most likely will take a reasonable amount of configuration so it may not be possible to be purely provider based and instead this type of KeyStore may need to be manually configured and instantiated.
> Properties could be passed in using the InputStream to initialise the KeyStore but that doesn't help where we may want to pass in factories for connecting to a remote LDAP server.
> In addition to the usual keys and certificates the entry types as used for CredentialStore should also be considered.
> The implementation should also support manipulation of the entries - in this case this may mean immediate updates to the directory.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (ELY-405) Add a KeyStore implementation backed by LDAP
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-405?page=com.atlassian.jira.plugin.sy... ]
Jan Kalina commented on ELY-405:
--------------------------------
>From [http://www.tldp.org/HOWTO/archived/LDAP-Implementation-HOWTO/certificates...]:
* The certificationAuthority objectclass implements the authorityRevocationList, certificateRevocationList and cACertificate attributes.
* The inetOrgPerson objectclass supports the usercertificate (binary) attribute.
* You can also use the mix-in objectclass strongAuthenticationUser to add certificates to non inetOrgPerson entries.
> Add a KeyStore implementation backed by LDAP
> --------------------------------------------
>
> Key: ELY-405
> URL: https://issues.jboss.org/browse/ELY-405
> Project: WildFly Elytron
> Issue Type: Feature Request
> Components: SSL
> Reporter: Darran Lofthouse
> Assignee: Jan Kalina
> Fix For: 2.0.0.Alpha1
>
>
> It is possible for private keys, public keys and certificates to all be stored in LDAP - this task is to create a Java KeyStore implementation that can work with this.
> LDAP most likely will take a reasonable amount of configuration so it may not be possible to be purely provider based and instead this type of KeyStore may need to be manually configured and instantiated.
> Properties could be passed in using the InputStream to initialise the KeyStore but that doesn't help where we may want to pass in factories for connecting to a remote LDAP server.
> In addition to the usual keys and certificates the entry types as used for CredentialStore should also be considered.
> The implementation should also support manipulation of the entries - in this case this may mean immediate updates to the directory.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (ELY-20) Where does OTP fit into realms?
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-20?page=com.atlassian.jira.plugin.sys... ]
Jan Kalina updated ELY-20:
--------------------------
Description:
Will investigate further once we have a pure LDAP impl in.
We could have an architecture where we have an LDAP server that is then referenced by an *OTP server* or we could have the two somehow combined into one.
There are also requirements related to *marking a token as used* or *token invalidation after too many bad attempts* - this may be handled within the OTP server but for stronger authentication mechanisms may need to be more involved otherwise this becomes another case of falling back to PLAIN / BASIC auth.
was:
Will investigate further once we have a pure LDAP impl in.
We could have an architecture where we have an LDAP server that is then referenced by an OTP server or we could have the two somehow combined into one.
There are also requirements related to marking a token as used or token invalidation after too many bad attempts - this may be handled within the OTP server but for stronger authentication mechanisms may need to be more involved otherwise this becomes another case of falling back to PLAIN / BASIC auth.
> Where does OTP fit into realms?
> -------------------------------
>
> Key: ELY-20
> URL: https://issues.jboss.org/browse/ELY-20
> Project: WildFly Elytron
> Issue Type: Sub-task
> Reporter: Darran Lofthouse
> Assignee: Jan Kalina
> Fix For: 1.1.0.CR1
>
>
> Will investigate further once we have a pure LDAP impl in.
> We could have an architecture where we have an LDAP server that is then referenced by an *OTP server* or we could have the two somehow combined into one.
> There are also requirements related to *marking a token as used* or *token invalidation after too many bad attempts* - this may be handled within the OTP server but for stronger authentication mechanisms may need to be more involved otherwise this becomes another case of falling back to PLAIN / BASIC auth.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 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:
--------------------------------------
I understood it as it power offing of node 2 somehow negatively affected networking on node 2. The point was that the problem is on OS or VM level.
> 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, 9 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:
--------------------------------
This solution won't be available in the 3.6 branch as JDK 8 is not the baseline there, and lambdas are not available...
The benchmark showed that using constructors or method handles doesn't yield better performance.
> 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, 9 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/13/16 6:09 AM:
---------------------------------------------------------
Turns out this is useless: if a {{MethodHandle}} is not _static_, apparently it cannot be optimized: if we store handles in a map (keyed by magic ID), then performance is about the same as using a constructor, or reflection.
The only fast way I've found so far is to create a method handle _indirectly_ via a lambda, ie.:
{code:java}
Supplier<? extends Header> supplier;
Header hdr=supplier.get();
{code}
This requires all headers to implement a Constructable interface which returns a supplier.
[1] https://github.com/belaban/PerfTests/blob/master/src/main/java/org/perfte...
was (Author: belaban):
Turns out this is useless: if a {{MethodHandle}} is not _static_, apparently it cannot be optimized: if we store handles in a map (keyed by magic ID), then performance is about the same as using a constructor, or reflection.
The only fast way I've found so far is to create a method handle _indirectly_ via a lambda, ie.:
{code:java}
Supplier<? extends Header> supplier;
Header hdr=supplier.get();
{code}
This requires all headers to implement a Creationable interface which returns a supplier.
[1] https://github.com/belaban/PerfTests/blob/master/src/main/java/org/perfte...
> 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, 9 months