[JBoss JIRA] (WFLY-8488) Usage of JGroups JDBC_PING attempts to delete row too late
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-8488?page=com.atlassian.jira.plugin.... ]
Radoslav Husar commented on WFLY-8488:
--------------------------------------
[~meetoblivion] The configuration is wrong. You need to use data-source="..." to establish model dependency. Here is an example configuration:
{code:xml}
<subsystem xmlns="urn:jboss:domain:jgroups:4.1">
<channels default="ee">
<channel name="ee" stack="tcp"/>
</channels>
<stacks>
<stack name="tcp">
<transport type="TCP" socket-binding="jgroups-tcp"/>
<jdbc-protocol type="JDBC_PING" data-source="ExampleDS"/>
<protocol type="MERGE3"/>
<protocol type="FD_SOCK"/>
<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="MFC"/>
<protocol type="FRAG2"/>
</stack>
</stacks>
</subsystem>
{code}
I cannot reproduce the CLI issue with nightly build not 11.0.0.Alpha1. The expected output is:
{noformat}
[standalone@localhost:9990 /] /subsystem=jgroups/stack=tcp/protocol=JDBC_PING:add(data-source=ExampleDS,add-index=0
{
"outcome" => "success",
"response-headers" => {
"operation-requires-reload" => true,
"process-state" => "reload-required"
}
}
[standalone@localhost:9990 /] :reload
{
"outcome" => "success",
"result" => undefined
}
{noformat}
> Usage of JGroups JDBC_PING attempts to delete row too late
> ----------------------------------------------------------
>
> Key: WFLY-8488
> URL: https://issues.jboss.org/browse/WFLY-8488
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.1.0.Final
> Reporter: John Ament
> Assignee: Paul Ferraro
>
> I was recently working on spinning up a Keycloak cluster. We're deployed to AWS, can't leverage UDP and wanted to have a discovery mechanism that was easy to use, so tried out JDBC_PING. While I got the cluster running, when shutting down a node I would receive an exception on the console when attempting to remove the node from the cluster. It attempts to do a delete on the row in the database after the DataSource has been shut down.
> In my setup, I'm pointing JGroups at the same DataSource as Keycloak, I'm not using the properties approach. I can switch to the properties approach, but I would prefer a single pool rather than multiple connections.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 6 months
[JBoss JIRA] (WFCORE-2896) Revisit CLI Ctrl-C handling
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2896?page=com.atlassian.jira.plugi... ]
Jean-Francois Denise updated WFCORE-2896:
-----------------------------------------
Description:
Ctrl-C typed in the CLI behaviour:
- If auto-connect is enabled (-c option). If prompt occurs for credentials, typing Ctrl-C should exit the CLI process
- As soon as we have reached the CLI prompt, any prompting is bound to a command execution (eg: connect, reload, ...), in that case Ctrl-C shouldn't exit the process. It should interrupt the command
- Ctrl-C typed for long running command should only interrupt the command.
- Ctrl-C typed when pausing long output should only interrupt output pause.
was:
Ctrl-C typed-in in the CLI behaviour:
- If auto-connect is enabled (-c option). If prompt occurs for credentials, typing Ctrl-C should exit the CLI process
- As soon as we have reached the CLI prompt, any prompting is bound to a command execution (eg: connect, reload, ...), in that case Ctrl-C shouldn't exit the process. It should interrupt the command
- Ctrl-C typed for long running command should only interrupt the command.
- Ctrl-C typed when pausing long output should only interrupt output pause.
> Revisit CLI Ctrl-C handling
> ---------------------------
>
> Key: WFCORE-2896
> URL: https://issues.jboss.org/browse/WFCORE-2896
> Project: WildFly Core
> Issue Type: Enhancement
> Components: CLI
> Reporter: Jean-Francois Denise
> Assignee: Jean-Francois Denise
>
> Ctrl-C typed in the CLI behaviour:
> - If auto-connect is enabled (-c option). If prompt occurs for credentials, typing Ctrl-C should exit the CLI process
> - As soon as we have reached the CLI prompt, any prompting is bound to a command execution (eg: connect, reload, ...), in that case Ctrl-C shouldn't exit the process. It should interrupt the command
> - Ctrl-C typed for long running command should only interrupt the command.
> - Ctrl-C typed when pausing long output should only interrupt output pause.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 6 months
[JBoss JIRA] (WFCORE-2896) Revisit CLI Ctrl-C handling
by Jean-Francois Denise (JIRA)
Jean-Francois Denise created WFCORE-2896:
--------------------------------------------
Summary: Revisit CLI Ctrl-C handling
Key: WFCORE-2896
URL: https://issues.jboss.org/browse/WFCORE-2896
Project: WildFly Core
Issue Type: Enhancement
Components: CLI
Reporter: Jean-Francois Denise
Assignee: Jean-Francois Denise
Ctrl-C typed-in in the CLI behaviour:
- If auto-connect is enabled (-c option). If prompt occurs for credentials, typing Ctrl-C should exit the CLI process
- As soon as we have reached the CLI prompt, any prompting is bound to a command execution (eg: connect, reload, ...), in that case Ctrl-C shouldn't exit the process. It should interrupt the command
- Ctrl-C typed for long running command should only interrupt the command.
- Ctrl-C typed when pausing long output should only interrupt output pause.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 6 months
[JBoss JIRA] (WFCORE-2732) Elytron - it should also be possible to store OTP algorithm on security realm level
by Yeray Borges (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2732?page=com.atlassian.jira.plugi... ]
Yeray Borges reassigned WFCORE-2732:
------------------------------------
Assignee: Yeray Borges (was: Darran Lofthouse)
> Elytron - it should also be possible to store OTP algorithm on security realm level
> -----------------------------------------------------------------------------------
>
> Key: WFCORE-2732
> URL: https://issues.jboss.org/browse/WFCORE-2732
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Josef Cacek
> Assignee: Yeray Borges
> Priority: Critical
>
> It should be possible to store OTP algorithm name on security realm level too.
> Using of the OTP SASL mechanism requires modifiable realm and currently only ldap-realm integration is finished.
> The ldap-realm now requires to store the algorithm name into an LDAP attribute together with the rest of OTP configuration (seed, hash, sequence), but this can be limiting (or space vasting) when the algorithm is the same for all users in the realm. There should be a possibility to configure the OTP algorithm name also on the realm level and share it for users. Make it an alternative for {{ldap-realm.identity-mapping.otp-credential-mapper.algorithm-from}} configuration.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 6 months
[JBoss JIRA] (WFLY-8488) Usage of JGroups JDBC_PING attempts to delete row too late
by Stian Thorgersen (JIRA)
[ https://issues.jboss.org/browse/WFLY-8488?page=com.atlassian.jira.plugin.... ]
Stian Thorgersen commented on WFLY-8488:
----------------------------------------
Does this mean JDBC_PING is not working at all on WildFly 11 Alpha? If so should this not be fixed before WildFly 11 Final is released?
> Usage of JGroups JDBC_PING attempts to delete row too late
> ----------------------------------------------------------
>
> Key: WFLY-8488
> URL: https://issues.jboss.org/browse/WFLY-8488
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.1.0.Final
> Reporter: John Ament
> Assignee: Paul Ferraro
>
> I was recently working on spinning up a Keycloak cluster. We're deployed to AWS, can't leverage UDP and wanted to have a discovery mechanism that was easy to use, so tried out JDBC_PING. While I got the cluster running, when shutting down a node I would receive an exception on the console when attempting to remove the node from the cluster. It attempts to do a delete on the row in the database after the DataSource has been shut down.
> In my setup, I'm pointing JGroups at the same DataSource as Keycloak, I'm not using the properties approach. I can switch to the properties approach, but I would prefer a single pool rather than multiple connections.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 6 months
[JBoss JIRA] (WFLY-8431) Race conditions in JASPIC registration code
by István Tóth (JIRA)
[ https://issues.jboss.org/browse/WFLY-8431?page=com.atlassian.jira.plugin.... ]
István Tóth commented on WFLY-8431:
-----------------------------------
The link to the getFactory() fix PR is
https://github.com/jboss/jboss-jaspi-api_spec/pull/4
> Race conditions in JASPIC registration code
> -------------------------------------------
>
> Key: WFLY-8431
> URL: https://issues.jboss.org/browse/WFLY-8431
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 10.1.0.Final
> Environment: Centos 7 x86_64, with the included Java 8 environment
> Reporter: István Tóth
> Assignee: Darran Lofthouse
> Attachments: GetFactoryTestCase.java
>
>
> javax.security.auth.message.config.AuthConfigFactory and
> org.jboss.security.auth.message.config.JBossAuthConfigFactory
> have race conditions.
> 1. javax.security.auth.message.config.AuthConfigFactory#getFactory() has a race condition. The checking and creation of the _factory object is not atomic.
> I think the best and simplest solution would be to simply make the getFactory() method synchronized. (The same method in the Glassfish implmentation is synchronized)
> 2. The keyTo*Map fields of the org.jboss.security.auth.message.config.JBossAuthConfigFactory are not thread safe.
> Nearly all methods of this class manipulate these, without any synchronization.
> In this case I believe that changing those from HashMaps to ConcurrentHashMaps should be enough to avoid the worst of the races, while incurring a negligible performance penalty.
> The methods that modify the maps should also be made synchronized, or rewritten to use the
> atomic ConcurrentHashMaps operations.
> A possible workaround is to add a synchronized(AuthConfigFactory.class) block around the JASPIC initialization code, where the JBossAuthConfigFactory methods are called. Of course this only works if every webapp on the server can be modified this way.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 6 months
[JBoss JIRA] (WFLY-8868) per application Expressions
by Juergen Weber (JIRA)
[ https://issues.jboss.org/browse/WFLY-8868?page=com.atlassian.jira.plugin.... ]
Juergen Weber updated WFLY-8868:
--------------------------------
Description:
Wildfly supports Expression Substitution in descriptors [1]. These expressions are server global.
This should be enhanced to support application scoped expressions:
${this:aProperty}
It would be especially useful for Message Driven Beans, as an ActivationConfigProperty can only be set in a descriptor or via an annotation, but not in application code, so ActivationConfigProperties are effectively fixed.
Then you could deploy the same Message Driven Bean multiple times with a different name:
myMDB1.ear
myMDB2.ear
having
<activation-config-property-value>${this:queuename}</activation-config-property-value>
and define
<application-properties>
<application name="myMDB_DEV_QUEUE_1.ear">
<property name="queuename" value="DEV_QUEUE_1"/>
</application>
<application name="myMDB_DEV_QUEUE_2.ear">
<property name="queuename" value="DEV_QUEUE_2"/>
</application>
</application-properties>
whereas for production the queuename properties would be different.
[1] https://docs.jboss.org/author/display/WFLY10/Expressions
was:
Wildfly supports Expression Substitution in descriptors [1]. These expressions are server global.
This should be enhanced to support application scoped expressions:
{{${this:aProperty}}}
It would be especially useful for Message Driven Beans, as an ActivationConfigProperty can only be set in a descriptor or via an annotation, but not in application code, so ActivationConfigProperties are effectively fixed.
Then you could deploy the same Message Driven Bean multiple times with a different name:
myMDB1.ear
myMDB2.ear
having
{{<activation-config-property-value>${this:queuename}</activation-config-property-value>}}
and define
{{<application-properties>
<application name="myMDB_DEV_QUEUE_1.ear">
<property name="queuename" value="DEV_QUEUE_1"/>
</application>
<application name="myMDB_DEV_QUEUE_2.ear">
<property name="queuename" value="DEV_QUEUE_2"/>
</application>}}
</application-properties>
whereas for production the queuename properties would be different.
[1] https://docs.jboss.org/author/display/WFLY10/Expressions
> per application Expressions
> ---------------------------
>
> Key: WFLY-8868
> URL: https://issues.jboss.org/browse/WFLY-8868
> Project: WildFly
> Issue Type: Feature Request
> Reporter: Juergen Weber
> Assignee: Jason Greene
>
> Wildfly supports Expression Substitution in descriptors [1]. These expressions are server global.
> This should be enhanced to support application scoped expressions:
> ${this:aProperty}
> It would be especially useful for Message Driven Beans, as an ActivationConfigProperty can only be set in a descriptor or via an annotation, but not in application code, so ActivationConfigProperties are effectively fixed.
> Then you could deploy the same Message Driven Bean multiple times with a different name:
> myMDB1.ear
> myMDB2.ear
> having
> <activation-config-property-value>${this:queuename}</activation-config-property-value>
> and define
> <application-properties>
> <application name="myMDB_DEV_QUEUE_1.ear">
> <property name="queuename" value="DEV_QUEUE_1"/>
> </application>
> <application name="myMDB_DEV_QUEUE_2.ear">
> <property name="queuename" value="DEV_QUEUE_2"/>
> </application>
> </application-properties>
> whereas for production the queuename properties would be different.
> [1] https://docs.jboss.org/author/display/WFLY10/Expressions
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 6 months
[JBoss JIRA] (WFLY-8868) per application Expressions
by Juergen Weber (JIRA)
Juergen Weber created WFLY-8868:
-----------------------------------
Summary: per application Expressions
Key: WFLY-8868
URL: https://issues.jboss.org/browse/WFLY-8868
Project: WildFly
Issue Type: Feature Request
Reporter: Juergen Weber
Assignee: Jason Greene
Wildfly supports Expression Substitution in descriptors [1]. These expressions are server global.
This should be enhanced to support application scoped expressions:
{{${this:aProperty}}}
It would be especially useful for Message Driven Beans, as an ActivationConfigProperty can only be set in a descriptor or via an annotation, but not in application code, so ActivationConfigProperties are effectively fixed.
Then you could deploy the same Message Driven Bean multiple times with a different name:
myMDB1.ear
myMDB2.ear
having
{{<activation-config-property-value>${this:queuename}</activation-config-property-value>}}
and define
{{<application-properties>
<application name="myMDB_DEV_QUEUE_1.ear">
<property name="queuename" value="DEV_QUEUE_1"/>
</application>
<application name="myMDB_DEV_QUEUE_2.ear">
<property name="queuename" value="DEV_QUEUE_2"/>
</application>}}
</application-properties>
whereas for production the queuename properties would be different.
[1] https://docs.jboss.org/author/display/WFLY10/Expressions
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 6 months