[JBoss JIRA] (WFLY-5134) Error creating Batch JDBC storage in domain
by Cheng Fang (JIRA)
[ https://issues.jboss.org/browse/WFLY-5134?page=com.atlassian.jira.plugin.... ]
Cheng Fang resolved WFLY-5134.
------------------------------
Resolution: Done
WFLY-5174 Upgrade jberet-core to 1.2.0.Beta1 has been merged into WildFly 10
> Error creating Batch JDBC storage in domain
> -------------------------------------------
>
> Key: WFLY-5134
> URL: https://issues.jboss.org/browse/WFLY-5134
> Project: WildFly
> Issue Type: Bug
> Components: Batch
> Affects Versions: 10.0.0.Beta1
> Environment: Oracle, DB2, Derby, Sybase, Firebird, and SQL Server databases
> Reporter: Jan Martiska
> Assignee: Cheng Fang
>
> When multiple servers (eg. a server-group in a JBoss domain) attempt to create a JDBC Batch repository at once, and they share a common database, they race in creating the database tables, because sometimes instance A will create the table PARTITION_EXECUTION after instance B invokes the check whether this table exists (this check is used to decide whether all tables need to be created) - therefore B will decide to create all tables too.
> If the database doesn't support the IF NOT EXISTS clause in CREATE TABLE (db2, oracle, sybase..), it will probably lead to a failure like 'table already exists', which in turn rolls back the creation of the JDBC store on all nodes in the domain, including those where the schema creation succeeded or was skipped. The tables remain physically in the database.
> This is similar to WFLY-5061, but this time, it is caused by having multiple servers in a domain.
> Sharing a common database in domain mode should work because it is useful for restarting failed jobs on different nodes if one node crashes.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 10 months
[JBoss JIRA] (WFLY-5263) MBeanServer returns MBean names that do not match filter
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-5263?page=com.atlassian.jira.plugin.... ]
Kabir Khan commented on WFLY-5263:
----------------------------------
This turns out to be because the JSR 77 mbean server plugin does not filter out matches which do not match the wildcard (hence the move back to WFLY, I moved it to WFCORE when assuming that )
I am a bit stumped that this works in WF 9.0.0.CR1, since this code has been the same for a long time. Perhaps your config there is not using the jsr77 subsystem?
> MBeanServer returns MBean names that do not match filter
> --------------------------------------------------------
>
> Key: WFLY-5263
> URL: https://issues.jboss.org/browse/WFLY-5263
> Project: WildFly
> Issue Type: Bug
> Components: JMX
> Affects Versions: 10.0.0.Beta2
> Reporter: Thomas Diesler
> Assignee: Kabir Khan
> Fix For: 10.0.0.CR1
>
>
> This code
> {code}
> MBeanServer server = ManagementFactory.getPlatformMBeanServer();
> for (ObjectName oname : server.queryNames(new ObjectName("*:type=context,*"), null)) {
> System.out.println(oname);
> }
> {code}
> gives
> {code}
> 16:51:25,842 INFO [stdout] (pool-3-thread-1) org.apache.camel:context=swagger-test,type=context,name="swagger-test"
> 16:51:25,842 INFO [stdout] (pool-3-thread-1) jboss.jsr77:j2eeType=J2EEServer,name=default
> 16:51:25,843 INFO [stdout] (pool-3-thread-1) jboss.jsr77:j2eeType=JVM,name=default,J2EEServer=default
> 16:51:25,843 INFO [stdout] (pool-3-thread-1) jboss.jsr77:j2eeType=J2EEDomain,name=jboss.jsr77
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 10 months
[JBoss JIRA] (ELY-281) Investigate if it's possible to modify the OTP SASL mechanism and password implementation to make use of the credential verification API
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/ELY-281?page=com.atlassian.jira.plugin.sy... ]
David Lloyd commented on ELY-281:
---------------------------------
One possible slight modification to this approach might be to add a method to the realm identity indicating that authentication was completed - this would avoid the possible problem where a verification should not "count" towards the OTP authentication.
I can't think of a good solution to requiring realms to use {{PasswordFactory}}. Ideally they *should* but I can't say for sure that they always *must*...
> Investigate if it's possible to modify the OTP SASL mechanism and password implementation to make use of the credential verification API
> ----------------------------------------------------------------------------------------------------------------------------------------
>
> Key: ELY-281
> URL: https://issues.jboss.org/browse/ELY-281
> Project: WildFly Elytron
> Issue Type: Feature Request
> Components: SASL
> Reporter: Farah Juma
> Assignee: Farah Juma
>
> The main idea here is to be able to pass the guess that's being verified to the realm and have the realm handle updating the stored credential if verification succeeds.
> Relevant chat discussion:
> {quote}
> \[8:42 AM\] Darran Lofthouse: @KabirKhan Ok, so you are trying to test OTP and require updates to be applied to the realm
> \[8:43 AM\] Darran Lofthouse: One option is to update the ServerAuthenticationContext to make an update
> \[8:43 AM\] Kabir Khan: That is what I had planned
> \[8:43 AM\] Darran Lofthouse: I do also wonder if a second option may be to use the credential verification API we have instead so the credential being verified is passed into the realm and the realm can handle updates internally
> \[8:44 AM\] Darran Lofthouse: although have not been in the credential in detail to see if this is possible
> \[8:44 AM\] Kabir Khan: Possibly, I'd need to look at the code a bit better though
> \[8:44 AM\] Kabir Khan: the first option is what stood out to me
> \[8:45 AM\] Darran Lofthouse: the first option may match with how the credential and mech are currently implemented - but does risk us adding more and more behaviour to ServerAuthenticationContext
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 10 months
[JBoss JIRA] (WFLY-5263) MBeanServer returns MBean names that do not match filter
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-5263?page=com.atlassian.jira.plugin.... ]
Kabir Khan moved WFCORE-862 to WFLY-5263:
-----------------------------------------
Project: WildFly (was: WildFly Core)
Key: WFLY-5263 (was: WFCORE-862)
Component/s: JMX
(was: JMX)
Affects Version/s: 10.0.0.Beta2
(was: 2.0.0.Alpha12)
Fix Version/s: 10.0.0.CR1
(was: 2.0.0.CR1)
> MBeanServer returns MBean names that do not match filter
> --------------------------------------------------------
>
> Key: WFLY-5263
> URL: https://issues.jboss.org/browse/WFLY-5263
> Project: WildFly
> Issue Type: Bug
> Components: JMX
> Affects Versions: 10.0.0.Beta2
> Reporter: Thomas Diesler
> Assignee: Kabir Khan
> Fix For: 10.0.0.CR1
>
>
> This code
> {code}
> MBeanServer server = ManagementFactory.getPlatformMBeanServer();
> for (ObjectName oname : server.queryNames(new ObjectName("*:type=context,*"), null)) {
> System.out.println(oname);
> }
> {code}
> gives
> {code}
> 16:51:25,842 INFO [stdout] (pool-3-thread-1) org.apache.camel:context=swagger-test,type=context,name="swagger-test"
> 16:51:25,842 INFO [stdout] (pool-3-thread-1) jboss.jsr77:j2eeType=J2EEServer,name=default
> 16:51:25,843 INFO [stdout] (pool-3-thread-1) jboss.jsr77:j2eeType=JVM,name=default,J2EEServer=default
> 16:51:25,843 INFO [stdout] (pool-3-thread-1) jboss.jsr77:j2eeType=J2EEDomain,name=jboss.jsr77
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 10 months
[JBoss JIRA] (ELY-282) Formalize multiple credential support
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/ELY-282?page=com.atlassian.jira.plugin.sy... ]
David Lloyd updated ELY-282:
----------------------------
Description:
Tackle the multiple credential problem directly rather than work around it. This requires multiple steps:
# In {{org.wildfly.security.auth.server.RealmIdentity}}, the credential access methods should drop {{credentialType}} and {{algorithmName}} and replace them with a single {{credentialName}}. The sole exception should be the {{getCredential}} method, which can retain the {{credentialType}} parameter in order to perform a soft cast-or-null operation for convenience. The {{verifyCredential}} method will need a {{credentialName}} parameter added.
# Add a method to {{RealmIdentity}} which can be used to query for the existence of a credential with the given label, e.g. {{hasCredential(String)}}.
# Modify {{org.wildfly.security.auth.server.ModifiableRealmIdentity}} to add a {{credentialName}} parameter to {{setCredential}}.
# Add a method to {{ModifiableRealmIdentity}} to delete a single named credential.
# Modify the {{setCredentials}} method of {{ModifiableRealmIdentity}} to accept a {{Map<String,Object>}} instead of a {{List<Object>}}.
# Add a credential selection mapper mechanism which can consume authentication process information and use it to yield a credential label. Some implementation ideas:
#* A functional interface which accepts the (mapped) name, authentication mechanism type (e.g. SASL vs HTTP vs ???), optional protocol type (e.g. SASL field), actual mechanism name (e.g. "DIGEST-MD5") and yields the label name or a list (in descending order of preference) of label names
#* Note that the approach must be forwards-compatible if we need to add more criteria to the mapping process
# Provide a default setting which selects a label from a simple predefined scheme based on the kind of authentication being performed (e.g. SASL "DIGEST-MD5" could prefer "sasl-digest" and then "clear-password", SASL "CLEAR" could prefer "password" and then "clear-password", etc.).
was:
Tackle the multiple credential problem directly rather than work around it. This requires multiple steps:
# In {{org.wildfly.security.auth.server.RealmIdentity}}, the credential access methods should drop {{credentialType}} and {{algorithmName}} and replace them with a single {{credentialName}}. The sole exception should be the {{getCredential}} method, which can retain the {{credentialType}} parameter in order to perform a soft cast-or-null operation for convenience. The {{verifyCredential}} method will need a {{credentialName}} parameter added.
# Add a method to {{RealmIdentity}} which can be used to query for the existence of a credential with the given label, e.g. {{hasCredential(String)}}.
# Modify {{org.wildfly.security.auth.server.ModifiableRealmIdentity}} to add a {{credentialName}} parameter to {{setCredential}}.
# Add a method to {{ModifiableRealmIdentity}} to delete a single named credential.
# Modify the {{setCredentials}} method of {{ModifiableRealmIdentity}} to accept a {{Map<String,Object>}} instead of a {{List<Object>}}.
# Add a credential selection mapper mechanism which can consume authentication process information and use it to yield a credential label. Some implementation ideas:
#* A functional interface which accepts the (mapped) name, authentication mechanism type (e.g. SASL vs HTTP vs ???), optional protocol type (e.g. SASL field), actual mechanism name (e.g. "DIGEST-MD5") and yields the label name or a list (in descending order of preference) of label names
# Provide a default setting which selects a label from a simple predefined scheme based on the kind of authentication being performed (e.g. SASL "DIGEST-MD5" could prefer "sasl-digest" and then "clear-password", SASL "CLEAR" could prefer "password" and then "clear-password", etc.).
> Formalize multiple credential support
> -------------------------------------
>
> Key: ELY-282
> URL: https://issues.jboss.org/browse/ELY-282
> Project: WildFly Elytron
> Issue Type: Task
> Components: API / SPI, Realms
> Reporter: David Lloyd
> Priority: Critical
> Fix For: 1.1.0.Alpha1
>
>
> Tackle the multiple credential problem directly rather than work around it. This requires multiple steps:
> # In {{org.wildfly.security.auth.server.RealmIdentity}}, the credential access methods should drop {{credentialType}} and {{algorithmName}} and replace them with a single {{credentialName}}. The sole exception should be the {{getCredential}} method, which can retain the {{credentialType}} parameter in order to perform a soft cast-or-null operation for convenience. The {{verifyCredential}} method will need a {{credentialName}} parameter added.
> # Add a method to {{RealmIdentity}} which can be used to query for the existence of a credential with the given label, e.g. {{hasCredential(String)}}.
> # Modify {{org.wildfly.security.auth.server.ModifiableRealmIdentity}} to add a {{credentialName}} parameter to {{setCredential}}.
> # Add a method to {{ModifiableRealmIdentity}} to delete a single named credential.
> # Modify the {{setCredentials}} method of {{ModifiableRealmIdentity}} to accept a {{Map<String,Object>}} instead of a {{List<Object>}}.
> # Add a credential selection mapper mechanism which can consume authentication process information and use it to yield a credential label. Some implementation ideas:
> #* A functional interface which accepts the (mapped) name, authentication mechanism type (e.g. SASL vs HTTP vs ???), optional protocol type (e.g. SASL field), actual mechanism name (e.g. "DIGEST-MD5") and yields the label name or a list (in descending order of preference) of label names
> #* Note that the approach must be forwards-compatible if we need to add more criteria to the mapping process
> # Provide a default setting which selects a label from a simple predefined scheme based on the kind of authentication being performed (e.g. SASL "DIGEST-MD5" could prefer "sasl-digest" and then "clear-password", SASL "CLEAR" could prefer "password" and then "clear-password", etc.).
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 10 months
[JBoss JIRA] (ELY-282) Formalize multiple credential support
by David Lloyd (JIRA)
David Lloyd created ELY-282:
-------------------------------
Summary: Formalize multiple credential support
Key: ELY-282
URL: https://issues.jboss.org/browse/ELY-282
Project: WildFly Elytron
Issue Type: Task
Components: API / SPI, Realms
Reporter: David Lloyd
Priority: Critical
Fix For: 1.1.0.Alpha1
Tackle the multiple credential problem directly rather than work around it. This requires multiple steps:
# In {{org.wildfly.security.auth.server.RealmIdentity}}, the credential access methods should drop {{credentialType}} and {{algorithmName}} and replace them with a single {{credentialName}}. The sole exception should be the {{getCredential}} method, which can retain the {{credentialType}} parameter in order to perform a soft cast-or-null operation for convenience. The {{verifyCredential}} method will need a {{credentialName}} parameter added.
# Add a method to {{RealmIdentity}} which can be used to query for the existence of a credential with the given label, e.g. {{hasCredential(String)}}.
# Modify {{org.wildfly.security.auth.server.ModifiableRealmIdentity}} to add a {{credentialName}} parameter to {{setCredential}}.
# Add a method to {{ModifiableRealmIdentity}} to delete a single named credential.
# Modify the {{setCredentials}} method of {{ModifiableRealmIdentity}} to accept a {{Map<String,Object>}} instead of a {{List<Object>}}.
# Add a credential selection mapper mechanism which can consume authentication process information and use it to yield a credential label. Some implementation ideas:
#* A functional interface which accepts the (mapped) name, authentication mechanism type (e.g. SASL vs HTTP vs ???), optional protocol type (e.g. SASL field), actual mechanism name (e.g. "DIGEST-MD5") and yields the label name or a list (in descending order of preference) of label names
# Provide a default setting which selects a label from a simple predefined scheme based on the kind of authentication being performed (e.g. SASL "DIGEST-MD5" could prefer "sasl-digest" and then "clear-password", SASL "CLEAR" could prefer "password" and then "clear-password", etc.).
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 10 months
[JBoss JIRA] (JGRP-1956) S3_PING / FILE_PING: remove failed members
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1956?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1956:
--------------------------------
No, all files will be removed. The info sender task will cause each coordinator to write its own information to the store again after a view change, based on {{info_writer_max_writes_after_view}} and {{info_writer_sleep_time}}. The former attribute governs the number of times this info is written, with a sleep (the latter attr) in-between.
> S3_PING / FILE_PING: remove failed members
> ------------------------------------------
>
> Key: JGRP-1956
> URL: https://issues.jboss.org/browse/JGRP-1956
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.4
> Reporter: Karsten Ohme
> Assignee: Bela Ban
> Fix For: 3.6.5
>
>
> When we terminate a member (EC2's "terminate" function) or kill -9 it, then the file (or bucket data in S3) won't get removed. This leads to stale data. On EC2, I expect that virtualized instances are often simply terminated, so this problem is compounded there.
> SOLUTION:
> - Periodically write own data to the file system (FILE_PING) or S3 (S3_PING)
> - On a view change: remove all data that's not in the current view
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 10 months
