[JBoss JIRA] (WFLY-5616) Recovery problem with CMR on MariaDB
by Hayk Hovsepyan (JIRA)
[ https://issues.jboss.org/browse/WFLY-5616?page=com.atlassian.jira.plugin.... ]
Hayk Hovsepyan updated WFLY-5616:
---------------------------------
Affects Version/s: 10.0.0.CR4
> Recovery problem with CMR on MariaDB
> -------------------------------------
>
> Key: WFLY-5616
> URL: https://issues.jboss.org/browse/WFLY-5616
> Project: WildFly
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 10.0.0.CR4
> Reporter: Hayk Hovsepyan
> Assignee: Tom Jenkinson
> Priority: Blocker
>
> Transaction recovery fails with error in logs when in transaction commit-markable-resource is used which is connected to MariaDB.
> {code}
> 10:02:14,727 DEBUG [com.arjuna.ats.arjuna] (Listener:4712) Connected to 127.0.0.1 on port 60906 on listener port 4712 for service com.arjuna.ats.internal.arjuna.recovery.WorkerService
> 10:02:14,729 DEBUG [com.arjuna.ats.arjuna] (Server.Connection:127.0.0.1:60906) PeriodicRecovery: listener worker interrupts background thread
> 10:02:14,729 DEBUG [com.arjuna.ats.arjuna] (Periodic Recovery) PeriodicRecovery: background thread Status <== SCANNING
> 10:02:14,729 INFO [com.arjuna.ats.arjuna] (Server.Connection:127.0.0.1:60906) ARJUNA012340: RecoveryManager scan scheduled to begin.
> 10:02:14,729 DEBUG [com.arjuna.ats.arjuna] (Periodic Recovery) PeriodicRecovery: background thread scanning
> 10:02:14,729 DEBUG [com.arjuna.ats.arjuna] (Periodic Recovery) Periodic recovery first pass at Mon, 2 Nov 2015 10:02:14
> 10:02:14,729 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) CommitMarkableResourceRecordRecoveryModule::periodicWorkFirstPass
> 10:02:14,729 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) CommitMarkableResourceRecordRecoveryModule::connecting to: java:jboss/xa-datasources/CrashRecoveryDS
> 10:02:14,730 TRACE [com.arjuna.ats.jta] (Periodic Recovery) TransactionSynchronizationRegistryImple.getTransactionKey
> 10:02:15,351 ERROR [stderr] (Periodic Recovery) Exception in thread "Periodic Recovery" java.lang.ArrayIndexOutOfBoundsException
> 10:02:15,351 ERROR [stderr] (Periodic Recovery) at java.lang.System.arraycopy(Native Method)
> 10:02:15,351 ERROR [stderr] (Periodic Recovery) at com.arjuna.ats.internal.jta.recovery.arjunacore.CommitMarkableResourceRecordRecoveryModule.periodicWorkFirstPass(CommitMarkableResourceRecordRecoveryModule.java:259)
> 10:02:15,351 ERROR [stderr] (Periodic Recovery) at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:747)
> 10:02:15,351 ERROR [stderr] (Periodic Recovery) at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:375)
> 10:06:58,460 TRACE [com.arjuna.ats.arjuna] (Transaction Reaper) ReaperThread.run ()
> 10:06:58,460 TRACE [com.arjuna.ats.arjuna] (Transaction Reaper) TransactionReaper::check ()
> 10:06:58,460 TRACE [com.arjuna.ats.arjuna] (Transaction Reaper) TransactionReaper::check - comparing 1446455218460
> 10:06:58,460 TRACE [com.arjuna.ats.arjuna] (Transaction Reaper) Thread Thread[Transaction Reaper,5,main] sleeping for 9223370590399557347
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-5616) Recovery problem with CMR on MariaDB
by Hayk Hovsepyan (JIRA)
Hayk Hovsepyan created WFLY-5616:
------------------------------------
Summary: Recovery problem with CMR on MariaDB
Key: WFLY-5616
URL: https://issues.jboss.org/browse/WFLY-5616
Project: WildFly
Issue Type: Bug
Components: Transactions
Reporter: Hayk Hovsepyan
Assignee: Tom Jenkinson
Priority: Blocker
Transaction recovery fails with error in logs when in transaction commit-markable-resource is used which is connected to MariaDB.
{code}
10:02:14,727 DEBUG [com.arjuna.ats.arjuna] (Listener:4712) Connected to 127.0.0.1 on port 60906 on listener port 4712 for service com.arjuna.ats.internal.arjuna.recovery.WorkerService
10:02:14,729 DEBUG [com.arjuna.ats.arjuna] (Server.Connection:127.0.0.1:60906) PeriodicRecovery: listener worker interrupts background thread
10:02:14,729 DEBUG [com.arjuna.ats.arjuna] (Periodic Recovery) PeriodicRecovery: background thread Status <== SCANNING
10:02:14,729 INFO [com.arjuna.ats.arjuna] (Server.Connection:127.0.0.1:60906) ARJUNA012340: RecoveryManager scan scheduled to begin.
10:02:14,729 DEBUG [com.arjuna.ats.arjuna] (Periodic Recovery) PeriodicRecovery: background thread scanning
10:02:14,729 DEBUG [com.arjuna.ats.arjuna] (Periodic Recovery) Periodic recovery first pass at Mon, 2 Nov 2015 10:02:14
10:02:14,729 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) CommitMarkableResourceRecordRecoveryModule::periodicWorkFirstPass
10:02:14,729 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) CommitMarkableResourceRecordRecoveryModule::connecting to: java:jboss/xa-datasources/CrashRecoveryDS
10:02:14,730 TRACE [com.arjuna.ats.jta] (Periodic Recovery) TransactionSynchronizationRegistryImple.getTransactionKey
10:02:15,351 ERROR [stderr] (Periodic Recovery) Exception in thread "Periodic Recovery" java.lang.ArrayIndexOutOfBoundsException
10:02:15,351 ERROR [stderr] (Periodic Recovery) at java.lang.System.arraycopy(Native Method)
10:02:15,351 ERROR [stderr] (Periodic Recovery) at com.arjuna.ats.internal.jta.recovery.arjunacore.CommitMarkableResourceRecordRecoveryModule.periodicWorkFirstPass(CommitMarkableResourceRecordRecoveryModule.java:259)
10:02:15,351 ERROR [stderr] (Periodic Recovery) at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:747)
10:02:15,351 ERROR [stderr] (Periodic Recovery) at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:375)
10:06:58,460 TRACE [com.arjuna.ats.arjuna] (Transaction Reaper) ReaperThread.run ()
10:06:58,460 TRACE [com.arjuna.ats.arjuna] (Transaction Reaper) TransactionReaper::check ()
10:06:58,460 TRACE [com.arjuna.ats.arjuna] (Transaction Reaper) TransactionReaper::check - comparing 1446455218460
10:06:58,460 TRACE [com.arjuna.ats.arjuna] (Transaction Reaper) Thread Thread[Transaction Reaper,5,main] sleeping for 9223370590399557347
{code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-5615) Security module options not parsed
by Heiko Braun (JIRA)
[ https://issues.jboss.org/browse/WFLY-5615?page=com.atlassian.jira.plugin.... ]
Heiko Braun updated WFLY-5615:
------------------------------
Summary: Security module options not parsed (was: Secutiry module optioins not parsed)
> Security module options not parsed
> ----------------------------------
>
> Key: WFLY-5615
> URL: https://issues.jboss.org/browse/WFLY-5615
> Project: WildFly
> Issue Type: Bug
> Components: Domain Management, Security
> Affects Versions: 10.0.0.CR4
> Reporter: Heiko Braun
> Assignee: Brian Stansberry
> Priority: Critical
>
> I've created a login module with several options and the result appears in standalone.xml. However when I read the resource using the CLI, these options are not shown.
> {noformat}
> <security-domain name="myDomain" cache-type="default">
> <authentication>
> <login-module name="myauth" code="Simple" flag="optional"/>
> <login-module name="myauth2" code="SimpleUsers" flag="sufficient">
> <module-option name="foo" value="bar"/>
> <module-option name="one" value="two"/>
> </login-module>
> </authentication>
> </security-domain>
> {noformat}
> {noformat}
> [standalone@localhost:9990 /] /subsystem=security/security-domain=myDomain/authentication=classic/login-module=myauth:read-resource(recursive=true)
> {
> "outcome" => "success",
> "result" => {
> "code" => "Simple",
> "flag" => "optional",
> "module" => undefined,
> "module-options" => undefined
> }
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-5615) Secutiry module optioins not parsed
by Heiko Braun (JIRA)
Heiko Braun created WFLY-5615:
---------------------------------
Summary: Secutiry module optioins not parsed
Key: WFLY-5615
URL: https://issues.jboss.org/browse/WFLY-5615
Project: WildFly
Issue Type: Bug
Components: Domain Management, Security
Affects Versions: 10.0.0.CR4
Reporter: Heiko Braun
Assignee: Brian Stansberry
Priority: Critical
I've created a login module with several options and the result appears in standalone.xml. However when I read the resource using the CLI, these options are not shown.
{noformat}
<security-domain name="myDomain" cache-type="default">
<authentication>
<login-module name="myauth" code="Simple" flag="optional"/>
<login-module name="myauth2" code="SimpleUsers" flag="sufficient">
<module-option name="foo" value="bar"/>
<module-option name="one" value="two"/>
</login-module>
</authentication>
</security-domain>
{noformat}
{noformat}
[standalone@localhost:9990 /] /subsystem=security/security-domain=myDomain/authentication=classic/login-module=myauth:read-resource(recursive=true)
{
"outcome" => "success",
"result" => {
"code" => "Simple",
"flag" => "optional",
"module" => undefined,
"module-options" => undefined
}
}
{noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-5413) On IIOP migration default properties are not persisted
by Ondřej Chaloupka (JIRA)
[ https://issues.jboss.org/browse/WFLY-5413?page=com.atlassian.jira.plugin.... ]
Ondřej Chaloupka reassigned WFLY-5413:
--------------------------------------
Assignee: Tomasz Adamski (was: Ondřej Chaloupka)
> On IIOP migration default properties are not persisted
> ------------------------------------------------------
>
> Key: WFLY-5413
> URL: https://issues.jboss.org/browse/WFLY-5413
> Project: WildFly
> Issue Type: Enhancement
> Components: IIOP
> Affects Versions: 10.0.0.CR1
> Reporter: Ondřej Chaloupka
> Assignee: Tomasz Adamski
>
> If there are some enumeration set in {{jacorb}} subsystem that should be migrate to new {{iiop}} subsystem with the {{:migrate}} operation then if value of such property matches the the defaults set for the new {{iiop}} such property with value is not persisted to XML.
> It would be nice if properties would be persisted for user can see what's happened after migration directly and not being confused that migration forgot for some value. Or he will need to check what are defaults and if all settings was migrated correctly.
> The example of such properties which do not persist because of its default values are
> * initializers: security="none"
> * security: client-supports="ServerAuth" server-supports="MutualAuth"
> * security: client-requires="None" server-requires="None"
> * transport-config: detect-misordering="none"
> * as-context: auth-method="username_password" required="false"
> * sas-context caller-propagation="none"
>
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-5413) On IIOP migration default properties are not persisted
by Ondřej Chaloupka (JIRA)
[ https://issues.jboss.org/browse/WFLY-5413?page=com.atlassian.jira.plugin.... ]
Ondřej Chaloupka commented on WFLY-5413:
----------------------------------------
Sure, agree, no problem.
Just I thought that I can fill this jira as a bug per mail conversation for being fixed in WFLY 10.
> On IIOP migration default properties are not persisted
> ------------------------------------------------------
>
> Key: WFLY-5413
> URL: https://issues.jboss.org/browse/WFLY-5413
> Project: WildFly
> Issue Type: Bug
> Components: IIOP
> Affects Versions: 10.0.0.CR1
> Reporter: Ondřej Chaloupka
> Assignee: Ondřej Chaloupka
>
> If there are some enumeration set in {{jacorb}} subsystem that should be migrate to new {{iiop}} subsystem with the {{:migrate}} operation then if value of such property matches the the defaults set for the new {{iiop}} such property with value is not persisted to XML.
> It would be nice if properties would be persisted for user can see what's happened after migration directly and not being confused that migration forgot for some value. Or he will need to check what are defaults and if all settings was migrated correctly.
> The example of such properties which do not persist because of its default values are
> * initializers: security="none"
> * security: client-supports="ServerAuth" server-supports="MutualAuth"
> * security: client-requires="None" server-requires="None"
> * transport-config: detect-misordering="none"
> * as-context: auth-method="username_password" required="false"
> * sas-context caller-propagation="none"
>
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-5413) On IIOP migration default properties are not persisted
by Ondřej Chaloupka (JIRA)
[ https://issues.jboss.org/browse/WFLY-5413?page=com.atlassian.jira.plugin.... ]
Ondřej Chaloupka updated WFLY-5413:
-----------------------------------
Issue Type: Enhancement (was: Bug)
> On IIOP migration default properties are not persisted
> ------------------------------------------------------
>
> Key: WFLY-5413
> URL: https://issues.jboss.org/browse/WFLY-5413
> Project: WildFly
> Issue Type: Enhancement
> Components: IIOP
> Affects Versions: 10.0.0.CR1
> Reporter: Ondřej Chaloupka
> Assignee: Ondřej Chaloupka
>
> If there are some enumeration set in {{jacorb}} subsystem that should be migrate to new {{iiop}} subsystem with the {{:migrate}} operation then if value of such property matches the the defaults set for the new {{iiop}} such property with value is not persisted to XML.
> It would be nice if properties would be persisted for user can see what's happened after migration directly and not being confused that migration forgot for some value. Or he will need to check what are defaults and if all settings was migrated correctly.
> The example of such properties which do not persist because of its default values are
> * initializers: security="none"
> * security: client-supports="ServerAuth" server-supports="MutualAuth"
> * security: client-requires="None" server-requires="None"
> * transport-config: detect-misordering="none"
> * as-context: auth-method="username_password" required="false"
> * sas-context caller-propagation="none"
>
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (JGRP-1972) Problem with tcp-cluster in Wildfly 8.2.1.Final
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1972?page=com.atlassian.jira.plugin.... ]
Bela Ban closed JGRP-1972.
--------------------------
Resolution: Rejected
> Problem with tcp-cluster in Wildfly 8.2.1.Final
> -----------------------------------------------
>
> Key: JGRP-1972
> URL: https://issues.jboss.org/browse/JGRP-1972
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Manu Forensic
> Assignee: Bela Ban
> Attachments: server.log, standalone-ha.xml
>
>
> I´ve some problems with a cluster tcp configuration with wildfly 8.2.1.Final. This is my standalone-ha.xml (attached file).
> Now when I try to start server in standalone mode:
> # ./standalone.sh -c standalone-ha.xml -b 10.10.10.1 & (server.log attached file).
> It seems not starting a TCP socket in port 7600:
> # netstat -nlpt|grep java
> tcp 0 0 127.0.0.1:9990 0.0.0.0:* LISTEN 30348/java
> tcp 0 0 10.10.10.1:8009 0.0.0.0:* LISTEN 30348/java
> tcp 0 0 10.10.10.1:8080 0.0.0.0:* LISTEN 30348/java
>
>
> However there is multicast in UDP:
>
> # netstat -nlpu|grep java
> udp 0 0 224.0.1.105:23364 0.0.0.0:* 30348/java
> Where is the problem?
> Thank for your support
> Best regards.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (JGRP-1972) Problem with tcp-cluster in Wildfly 8.2.1.Final
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1972?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1972:
--------------------------------
I don't think a cluster was started, as this is done just-in-time when (e.g.) a distributable app is deployed. You could use -Djgroups.bind_addr=x.x.x.x to pick an interface to bind to.
This is a Wildfly question, not a JGroups question; I suggest ask on the Wildfly mailing list.
> Problem with tcp-cluster in Wildfly 8.2.1.Final
> -----------------------------------------------
>
> Key: JGRP-1972
> URL: https://issues.jboss.org/browse/JGRP-1972
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Manu Forensic
> Assignee: Bela Ban
> Attachments: server.log, standalone-ha.xml
>
>
> I´ve some problems with a cluster tcp configuration with wildfly 8.2.1.Final. This is my standalone-ha.xml (attached file).
> Now when I try to start server in standalone mode:
> # ./standalone.sh -c standalone-ha.xml -b 10.10.10.1 & (server.log attached file).
> It seems not starting a TCP socket in port 7600:
> # netstat -nlpt|grep java
> tcp 0 0 127.0.0.1:9990 0.0.0.0:* LISTEN 30348/java
> tcp 0 0 10.10.10.1:8009 0.0.0.0:* LISTEN 30348/java
> tcp 0 0 10.10.10.1:8080 0.0.0.0:* LISTEN 30348/java
>
>
> However there is multicast in UDP:
>
> # netstat -nlpu|grep java
> udp 0 0 224.0.1.105:23364 0.0.0.0:* 30348/java
> Where is the problem?
> Thank for your support
> Best regards.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months