[JBoss JIRA] (WFCORE-1017) Reload operation causes crash of EAP server
by Miroslav Novak (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1017?page=com.atlassian.jira.plugi... ]
Miroslav Novak commented on WFCORE-1017:
----------------------------------------
[~ctomc] Hi Tomaz, Erich is not here this week and ask me to try instead of him. I've tried to run the test waitForLiveServerToReload() method from your comment and used instead of waitHornetQToAlive() in CoreBridgeAttributesTestCase#reloadServerTest test.
On IBM JDK 1.8 with RHEL7 (or my Fedora 22) the JVM is still crashing. I'll attach log from the test and server.log.
> Reload operation causes crash of EAP server
> -------------------------------------------
>
> Key: WFCORE-1017
> URL: https://issues.jboss.org/browse/WFCORE-1017
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 2.0.0.CR1
> Environment: Fedora 22, RHEL 7 ++ OpenJDK 8 - crash of EAP server
> Fedora 22, RHEL 7 ++ IBM Java 1.8 - crash of JVM where runs the EAP server
> {panel}
> $ java -version
> java version "1.8.0"
> Java(TM) SE Runtime Environment (build pxa6480sr1fp10-20150711_01(SR1 FP10))
> IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20150630_255633 (JIT enabled, AOT enabled)
> J9VM - R28_jvm.28_20150630_1742_B255633
> JIT - tr.r14.java_20150625_95081.01
> GC - R28_jvm.28_20150630_1742_B255633_CMPRSS
> J9CL - 20150630_255633)
> JCL - 20150711_01 based on Oracle jdk8u51-b15
> {panel}
> Reporter: Erich Duda
> Assignee: Tomaz Cerar
> Attachments: javacore.20150917.161241.19157.0002.txt, server-openjdk.log, Snap.20150917.161241.19157.0003.trc
>
>
> Repeated execution of reload request causes EAP server crash.
> {panel}
> 10:43:15,179 ERROR [org.jboss.msc.service] (MSC service thread 1-4) MSC000002: Invocation of listener "org.jboss.as.controller.operations.common.ProcessReloadHandler$1$1$1@3d119a3c" failed: java.lang.IllegalArgumentException: Container is shutting down
> at org.jboss.msc.service.ServiceControllerImpl.internalSetMode(ServiceControllerImpl.java:762) [jboss-msc-1.2.6.Final.jar:1.2.6.Final]
> at org.jboss.msc.service.ServiceControllerImpl.setMode(ServiceControllerImpl.java:753) [jboss-msc-1.2.6.Final.jar:1.2.6.Final]
> at org.jboss.as.controller.operations.common.ProcessReloadHandler$1$1$1.transition(ProcessReloadHandler.java:90) [wildfly-controller-2.0.0.Beta4.jar:2.0.0.Beta4]
> at org.jboss.msc.service.ServiceControllerImpl.invokeListener(ServiceControllerImpl.java:1533) [jboss-msc-1.2.6.Final.jar:1.2.6.Final]
> at org.jboss.msc.service.ServiceControllerImpl.access$2800(ServiceControllerImpl.java:51) [jboss-msc-1.2.6.Final.jar:1.2.6.Final]
> at org.jboss.msc.service.ServiceControllerImpl$ListenerTask.run(ServiceControllerImpl.java:2099) [jboss-msc-1.2.6.Final.jar:1.2.6.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_60]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_60]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_60]
> {panel}
> On IBM Java reload resquests cause even JVM crash.
> {panel}
> #0: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x8a455f) [0x7f44cce6055f]
> #1: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x1042f1) [0x7f44cc6c02f1]
> #2: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9prt28.so(+0x255ee) [0x7f44d8b515ee]
> #3: /lib64/libpthread.so.0(+0x10430) [0x7f44dafd9430]
> #4: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x74909e) [0x7f44ccd0509e]
> #5: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x749372) [0x7f44ccd05372]
> #6: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x437922) [0x7f44cc9f3922]
> #7: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x4385bb) [0x7f44cc9f45bb]
> #8: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x448e10) [0x7f44cca04e10]
> #9: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x449855) [0x7f44cca05855]
> #10: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x44dd5d) [0x7f44cca09d5d]
> #11: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x44eb3e) [0x7f44cca0ab3e]
> #12: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x44dc40) [0x7f44cca09c40]
> #13: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x44eb3e) [0x7f44cca0ab3e]
> #14: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x44dc40) [0x7f44cca09c40]
> #15: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x44eb3e) [0x7f44cca0ab3e]
> #16: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x44ec75) [0x7f44cca0ac75]
> #17: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x44effb) [0x7f44cca0affb]
> #18: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x2cd94d) [0x7f44cc88994d]
> #19: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x2cdc19) [0x7f44cc889c19]
> #20: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x2cee94) [0x7f44cc88ae94]
> #21: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x7c748b) [0x7f44ccd8348b]
> #22: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x7cee4c) [0x7f44ccd8ae4c]
> #23: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x10c7b5) [0x7f44cc6c87b5]
> #24: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x10dcab) [0x7f44cc6c9cab]
> #25: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9prt28.so(+0x25975) [0x7f44d8b51975]
> #26: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x10fdf0) [0x7f44cc6cbdf0]
> #27: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x1110ed) [0x7f44cc6cd0ed]
> #28: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9prt28.so(+0x25975) [0x7f44d8b51975]
> #29: /opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so(+0x111a04) [0x7f44cc6cda04]
> Unhandled exception
> Type=Segmentation error vmState=0x00051cff
> J9Generic_Signal_Number=00000004 Signal_Number=0000000b Error_Value=00000000 Signal_Code=00000001
> Handler1=00007F44D920CD90 Handler2=00007F44D8B513F0 InaccessibleAddress=0000000000000000
> RDI=00007F440613D710 RSI=FFFFFFFFFFDF3B65 RAX=0000000000000000 RBX=00007F4406141390
> RCX=0000000000000026 RDX=0000000000000001 R8=00007F44CCF4EA52 R9=0000000000000000
> R10=00007F4406145740 R11=0000000000000003 R12=00007F44076AEF00 R13=0000000000000000
> R14=0000000000000000 R15=0000000000000000
> RIP=00007F44CCD0509E GS=0000 FS=0000 RSP=00007F44C9A84C20
> EFlags=0000000000210246 CS=0033 RBP=0000000000000000 ERR=0000000000000004
> TRAPNO=000000000000000E OLDMASK=0000000000000000 CR2=0000000000000000
> xmm0 00007f44003b6e6f (f: 3894895,000000, d: 6,913462e-310)
> xmm1 0000000000000000 (f: 0,000000, d: 0,000000e+00)
> xmm2 616c2f6176616a4c (f: 1986095744,000000, d: 1,981285e+161)
> xmm3 6a00656c62617468 (f: 1650553984,000000, d: 4,016150e+202)
> xmm4 0000000000000000 (f: 0,000000, d: 0,000000e+00)
> xmm5 03d303d203d103d0 (f: 64029648,000000, d: 3,048729e-290)
> xmm6 49676e697274532f (f: 1920226048,000000, d: 4,180283e+45)
> xmm7 4573646e756f4266 (f: 1970225792,000000, d: 3,751018e+26)
> xmm8 03d603d503d403d3 (f: 64226260,000000, d: 3,529736e-290)
> xmm9 03de03dd03dc03db (f: 64750556,000000, d: 4,812424e-290)
> xmm10 03e603e503e403e3 (f: 65274852,000000, d: 7,059551e-290)
> xmm11 03ee03ed03ec03eb (f: 65799148,000000, d: 9,624926e-290)
> xmm12 03f603f503f403f3 (f: 66323444,000000, d: 1,411926e-289)
> xmm13 03fe03fd03fc03fb (f: 66847740,000000, d: 1,925001e-289)
> xmm14 0406040504040403 (f: 67372032,000000, d: 2,823883e-289)
> xmm15 040e040d040c040b (f: 67896328,000000, d: 3,850033e-289)
> Module=/opt/ibm/java-x86_64-80/jre/lib/amd64/compressedrefs/libj9jit28.so
> Module_base_address=00007F44CC5BC000
> Method_being_compiled=org/jboss/as/controller/OperationContextImpl$ContextServiceBuilder.install()Lorg/jboss/msc/service/ServiceController;
> Target=2_80_20150630_255633 (Linux 4.1.6-201.fc22.x86_64)
> CPU=amd64 (8 logical CPUs) (0x3d3def000 RAM)
> ----------- Stack Backtrace -----------
> (0x00007F44CCD0509E [libj9jit28.so+0x74909e])
> (0x00007F44CCD05372 [libj9jit28.so+0x749372])
> (0x00007F44CC9F3922 [libj9jit28.so+0x437922])
> (0x00007F44CC9F45BB [libj9jit28.so+0x4385bb])
> (0x00007F44CCA04E10 [libj9jit28.so+0x448e10])
> (0x00007F44CCA05855 [libj9jit28.so+0x449855])
> (0x00007F44CCA09D5D [libj9jit28.so+0x44dd5d])
> (0x00007F44CCA0AB3E [libj9jit28.so+0x44eb3e])
> (0x00007F44CCA09C40 [libj9jit28.so+0x44dc40])
> (0x00007F44CCA0AB3E [libj9jit28.so+0x44eb3e])
> (0x00007F44CCA09C40 [libj9jit28.so+0x44dc40])
> (0x00007F44CCA0AB3E [libj9jit28.so+0x44eb3e])
> (0x00007F44CCA0AC75 [libj9jit28.so+0x44ec75])
> (0x00007F44CCA0AFFB [libj9jit28.so+0x44effb])
> (0x00007F44CC88994D [libj9jit28.so+0x2cd94d])
> (0x00007F44CC889C19 [libj9jit28.so+0x2cdc19])
> (0x00007F44CC88AE94 [libj9jit28.so+0x2cee94])
> (0x00007F44CCD8348B [libj9jit28.so+0x7c748b])
> (0x00007F44CCD8AE4C [libj9jit28.so+0x7cee4c])
> (0x00007F44CC6C87B5 [libj9jit28.so+0x10c7b5])
> (0x00007F44CC6C9CAB [libj9jit28.so+0x10dcab])
> (0x00007F44D8B51975 [libj9prt28.so+0x25975])
> (0x00007F44CC6CBDF0 [libj9jit28.so+0x10fdf0])
> (0x00007F44CC6CD0ED [libj9jit28.so+0x1110ed])
> (0x00007F44D8B51975 [libj9prt28.so+0x25975])
> (0x00007F44CC6CDA04 [libj9jit28.so+0x111a04])
> (0x00007F44D8F8E9EC [libj9thr28.so+0x99ec])
> (0x00007F44DAFD0555 [libpthread.so.0+0x7555])
> clone+0x6d (0x00007F44DA8F0B9D [libc.so.6+0x102b9d])
> {panel}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[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:
---------------------------------
Attachment: server.log
datasourcesmariadb.properties
> 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
> Attachments: datasourcesmariadb.properties, server.log
>
>
> 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)
8 years, 6 months
[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:
---------------------------------
Steps to Reproduce:
Steps to reproduce:
1) enlist CMR resource
2) enlist test XA Resource
3) prepare CMR resource (nothing is written to xids table)
4) prepare test XA resource
5) finish 2PC prepare phase by writing everything to log
7) commit CMR resource
8) crash JVM
9) Restart server and call recovery. Recovery run fails with exception and recovery call does not return.
This scenario works with other databases.
It can be reproduced by automated case:
1. Clone the repo: "git clone git://git.app.eng.bos.redhat.com/jbossqe-eap-tests-transactions.git tests-transactions"
2. Change directory: "cd tests-transactions/jbossts/"
3. Run test: "mvn clean verify -Djboss.home=$JBOSS_HOME -Djbossts.noJTS -Dds.properties=$PATH_TO_datasourcesmariadb.properties -Dtest=JPACMRCrashRecoveryTestCase#commitHaltAfterCMR"
"datasourcesmariadb.properties" and TRACE "server.log" are attached.
> 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
> Attachments: datasourcesmariadb.properties, server.log
>
>
> 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)
8 years, 6 months
[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)
8 years, 6 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)
8 years, 6 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)
8 years, 6 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)
8 years, 6 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)
8 years, 6 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)
8 years, 6 months