[JBoss JIRA] (WFCORE-242) the deployment content is deleted if first undeploy and then deploy the same application using CLI batch
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-242?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on WFCORE-242:
------------------------------------------------
Brian Stansberry <brian.stansberry(a)redhat.com> changed the Status of [bug 1162444|https://bugzilla.redhat.com/show_bug.cgi?id=1162444] from ASSIGNED to POST
> the deployment content is deleted if first undeploy and then deploy the same application using CLI batch
> --------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-242
> URL: https://issues.jboss.org/browse/WFCORE-242
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI, Domain Management
> Reporter: Jay Kumar SenSharma
> Assignee: Emmanuel Hugonnet
> Priority: Minor
>
> - If deploy and undeploy CLI commands executed in a batch mode then it causes missing deployment inside the "data/content" directory which leads to the following error:
> {code}
> [Host Controller] 10:33:42,387 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([("deployment" => "example.war")]) - failure description: "WFLYDC0058: No deployment content with hash d85f1e3106bc8a49838a0dccae9e80819c25e02c is available in the deployment content repository for deployment 'example.war'. This is a fatal boot error. To correct the problem, either restart with the --admin-only switch set and use the CLI to install the missing content or remove it from the configuration, or remove the deployment from the xml configuraiton file and restart."
> [Host Controller] 10:33:42,390 FATAL [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0034: Host Controller boot has failed in an unrecoverable manner; exiting. See previous messages for details.
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 7 months
[JBoss JIRA] (JGRP-1878) Multicast discovery does not work on JDK8
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JGRP-1878?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on JGRP-1878:
-----------------------------------------------
Dominik Pospisil <dpospisi(a)redhat.com> changed the Status of [bug 1167666|https://bugzilla.redhat.com/show_bug.cgi?id=1167666] from ASSIGNED to POST
> Multicast discovery does not work on JDK8
> -----------------------------------------
>
> Key: JGRP-1878
> URL: https://issues.jboss.org/browse/JGRP-1878
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.2.12, 3.5
> Environment: OpenJDK8, OracleJDK8u40
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Priority: Minor
> Fix For: 3.2.14, 3.6
>
> Attachments: mcast.java
>
>
> Multicast discovery does not work on JDK8 when using different bind IP addresses. This blocks EAP certification on JDK8.
> Steps to reproduce with draw, switch to JDK8:
> {noformat}
> export IP_ADDR=127.0.0.1
> ./draw.sh
> export IP_ADDR=192.168.1.10
> ./draw.sh
> {noformat}
> Everything works when binding to the same IP address or using JDK 6 or 7. Possibly a JDK8 bug..
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 7 months
[JBoss JIRA] (WFLY-825) JBOSS 7.1.1.Final hangs on z/OS with new JDK maintenance
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFLY-825?page=com.atlassian.jira.plugin.s... ]
David Lloyd commented on WFLY-825:
----------------------------------
Regarding my (much) earlier comment about {{-Dxnio.nio.old-locking}}, you have to define it to be "true" in order for it to actually take effect.
Like this: {{-Dxnio.nio.old-locking=true}}
Also, I don't know much about z/OS but is there a way you could attach the {{/javacore.20141125.141658.80445.0002.txt}} file?
> JBOSS 7.1.1.Final hangs on z/OS with new JDK maintenance
> --------------------------------------------------------
>
> Key: WFLY-825
> URL: https://issues.jboss.org/browse/WFLY-825
> Project: WildFly
> Issue Type: Bug
> Components: Server
> Environment: operating system - z/OS version 1.13
> JDK version info:
> java version "1.7.0"
> Java(TM) SE Runtime Environment (build pmz6470sr2-20120901_01(SR2))
> IBM J9 VM (build 2.6, JRE 1.7.0 z/OS s390x-64 20120809_118929 (JIT enabled, AOT enabled)
> J9VM - R26_Java726_SR2_20120809_0948_B118929
> JIT - r11.b01_20120808_24925
> GC - R26_Java726_SR2_20120809_0948_B118929
> J9CL - 20120809_118929)
> JCL - 20120831_02 based on Oracle 7u3-b05
> Reporter: Bob Bennett
> Assignee: Jason Greene
> Labels: jboss
> Attachments: relevant-threads.txt, threadstacks.txt, xnio-nio-3.0.8.GA-SNAPSHOT.jar, xnio-nio-3.0.8.GA-SNAPSHOT.jar
>
>
> When I install the jboss-as-7.1.1.Final on a z/OS system with the newest JDK, and start the standalone server, it gets stuck and never completes initialization. It also does not respond to kill, and requires kill -9 to terminate. I have javacore from the hang. I opened an issue with IBM support, and here is their response:
> Hi Bob,
>
> Have you contacted JBoss support for this issue?
>
> From my review of the javacore, every application-related thread is
> waiting on some kind of internal state monitoring code. The most
> prominent cause of waiting appears to be a CountdownLatch used in:
>
> org/jboss/as/controller/ParallelBootOperationStepHandler
> $ParallelBootTransactionControl.operationPrepared
>
> A quick search found this possibly related JBoss bug which was
> introduced because of incompatibilities with Java 7 (although it would appear to have been fixed before your current build, but I'm not certain
> how.) https://issues.jboss.org/browse/AS7-2940?_sscc=t
>
> The CountdownLatch is one of the Concurrency classes, and is very
> simplistic in that it allows an application to direct threads to wait
> until some certain number of actions have occured. The application code
> (JBoss in this case) would need to explain how many countdowns are
> required and which piece of code decrements the counter as needed.
>
> There's not much to say from a JVM perspective other than the threads
> are all waiting for an application-level event (a call to the
> "countDown()" method 'N' times where 'N' is how many JBoss initialized
> the CountDownLatch to originally.)
>
> If the JBoss team believes there is a specific thread not processing for one reason or another, we could look at that from a JVM perspective to see why. Unfortunately we'd need the JBoss team to explain which thread
> they think should be executing and why. A system dump of the problem
> (taken using signal 3, or from the operator console) would potentially allow for the internal state variables associated here to be read out...
> but that won't really be of any use if we don't know what JBoss expects
> them to be.
>
> Regards,
> Java Defect Support
> Please let me know if you need more info, either from myself or IBM JDK support.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 7 months
[JBoss JIRA] (WFLY-825) JBOSS 7.1.1.Final hangs on z/OS with new JDK maintenance
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-825?page=com.atlassian.jira.plugin.s... ]
Tomaz Cerar commented on WFLY-825:
----------------------------------
Can you try without remote debugging enabled as this could cause some problems.
in short just remove "-Xdebug -Xrunjdwp:transport=dt_socket,address=5051,server=y,suspend=n" properties.
if it is still a problem can you attach also javacore dump.
> JBOSS 7.1.1.Final hangs on z/OS with new JDK maintenance
> --------------------------------------------------------
>
> Key: WFLY-825
> URL: https://issues.jboss.org/browse/WFLY-825
> Project: WildFly
> Issue Type: Bug
> Components: Server
> Environment: operating system - z/OS version 1.13
> JDK version info:
> java version "1.7.0"
> Java(TM) SE Runtime Environment (build pmz6470sr2-20120901_01(SR2))
> IBM J9 VM (build 2.6, JRE 1.7.0 z/OS s390x-64 20120809_118929 (JIT enabled, AOT enabled)
> J9VM - R26_Java726_SR2_20120809_0948_B118929
> JIT - r11.b01_20120808_24925
> GC - R26_Java726_SR2_20120809_0948_B118929
> J9CL - 20120809_118929)
> JCL - 20120831_02 based on Oracle 7u3-b05
> Reporter: Bob Bennett
> Assignee: Jason Greene
> Labels: jboss
> Attachments: relevant-threads.txt, threadstacks.txt, xnio-nio-3.0.8.GA-SNAPSHOT.jar, xnio-nio-3.0.8.GA-SNAPSHOT.jar
>
>
> When I install the jboss-as-7.1.1.Final on a z/OS system with the newest JDK, and start the standalone server, it gets stuck and never completes initialization. It also does not respond to kill, and requires kill -9 to terminate. I have javacore from the hang. I opened an issue with IBM support, and here is their response:
> Hi Bob,
>
> Have you contacted JBoss support for this issue?
>
> From my review of the javacore, every application-related thread is
> waiting on some kind of internal state monitoring code. The most
> prominent cause of waiting appears to be a CountdownLatch used in:
>
> org/jboss/as/controller/ParallelBootOperationStepHandler
> $ParallelBootTransactionControl.operationPrepared
>
> A quick search found this possibly related JBoss bug which was
> introduced because of incompatibilities with Java 7 (although it would appear to have been fixed before your current build, but I'm not certain
> how.) https://issues.jboss.org/browse/AS7-2940?_sscc=t
>
> The CountdownLatch is one of the Concurrency classes, and is very
> simplistic in that it allows an application to direct threads to wait
> until some certain number of actions have occured. The application code
> (JBoss in this case) would need to explain how many countdowns are
> required and which piece of code decrements the counter as needed.
>
> There's not much to say from a JVM perspective other than the threads
> are all waiting for an application-level event (a call to the
> "countDown()" method 'N' times where 'N' is how many JBoss initialized
> the CountDownLatch to originally.)
>
> If the JBoss team believes there is a specific thread not processing for one reason or another, we could look at that from a JVM perspective to see why. Unfortunately we'd need the JBoss team to explain which thread
> they think should be executing and why. A system dump of the problem
> (taken using signal 3, or from the operator console) would potentially allow for the internal state variables associated here to be read out...
> but that won't really be of any use if we don't know what JBoss expects
> them to be.
>
> Regards,
> Java Defect Support
> Please let me know if you need more info, either from myself or IBM JDK support.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 7 months
[JBoss JIRA] (WFLY-825) JBOSS 7.1.1.Final hangs on z/OS with new JDK maintenance
by Stefan Erichsen (JIRA)
[ https://issues.jboss.org/browse/WFLY-825?page=com.atlassian.jira.plugin.s... ]
Stefan Erichsen commented on WFLY-825:
--------------------------------------
Hi Tomar,
thanks for your quick response. Unfortunately WildFly 8.1.0.Final and 8.2.0.Final won't even start on the machine.
{code:java}
=========================================================================
JBoss Bootstrap Environment
JBOSS_HOME: /wildfly-8.2.0.Final
JAVA: /QOpenSys/QIBM/ProdData/JavaVM/jdk70/64bit/bin/java
JAVA_OPTS: -Xms64m -Xmx2048m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.bytema
n -Djava.awt.headless=true -Xdebug -Xrunjdwp:transport=dt_socket,address=5051,server=y,suspend=n
=========================================================================
Listening for transport dt_socket at address: 5051
[0m14:16:54,330 INFO [org.jboss.modules] (main) JBoss Modules version 1.3.3.Final
[0m [0m14:16:55,150 INFO [org.jboss.msc] (main) JBoss MSC version 1.2.2.Final
[0m [0m14:16:55,251 INFO [org.jboss.as] (MSC service thread 1-8) JBAS015899: WildFly 8.2.0.Final "Tweek" starting
[0m [0m14:16:58,363 INFO [org.jboss.as.server] (Controller Boot Thread) JBAS015888: Creating http management service using socket-binding (management-http)
[0m [0m14:16:58,392 INFO [org.xnio] (MSC service thread 1-4) XNIO version 3.3.0.Final
[0m [0m14:16:58,412 INFO [org.xnio.nio] (MSC service thread 1-4) XNIO NIO Implementation Version 3.3.0.Final
[0mUnhandled exception
Type=Illegal instruction vmState=0x00040000
J9Generic_Signal_Number=00000010 Signal_Number=00000004 Error_Value=00000000 Signal_Code=00000009
Handler1=09001000A0248020 Handler2=09001000A023F518
R0=F9A052647CFFF7E0 R1=00000001832E5CF0 R2=00000000000002E6 R3=FFFFFFFFFFFFFFFF
R4=FFFFFFFFFFFFFFFF R5=0000000000002000 R6=00000001859B51E0 R7=0000000000000003
R8=000000018499BED4 R9=09001000A02798E8 R10=000000018499BED4 R11=0000000000003610
R12=0000000000000102 R13=00000001832EF800 R14=00000001859B51B0 R15=00000001832F3F00
R16=0000000000000007 R17=0000000000000000 R18=09001000A024C6D0 R19=09001000A0453020
R20=0000000185B0F250 R21=00000001859B51E0 R22=00000001832F3FF0 R23=0000000000000000
R24=000000000000007E R25=09001000A0241DD0 R26=000000000000007E R27=00000001832E7680
R28=0000000000000002 R29=09001000A0248020 R30=00000001832E6440 R31=0000000000040000
IAR=0000000000003618 LR=090000000282E4D8 MSR=800000000000F032 CTR=0000000000003610
CR=8200004B32000001 FPSCR=8200000000000000 XER=3200000182000000
FPR0 0000000082000000 (f: 2181038080,000000, d: 1,077576e-314)
FPR1 0000000000000000 (f: 0,000000, d: 0,000000e+00)
FPR2 41e8630000000000 (f: 0,000000, d: 3,273130e+09)
FPR3 0000000000000000 (f: 0,000000, d: 0,000000e+00)
FPR4 41d3729e61400000 (f: 1631584256,000000, d: 1,305115e+09)
FPR5 4323575afd29b546 (f: 4247368960,000000, d: 2,722036e+15)
FPR6 00000000000a74c0 (f: 685248,000000, d: 3,385575e-318)
FPR7 4124e98000000000 (f: 0,000000, d: 6,852480e+05)
FPR8 000000005474814a (f: 1416921472,000000, d: 7,000522e-315)
FPR9 41d51d2052800000 (f: 1384120320,000000, d: 1,416921e+09)
FPR10 43128bfb13208000 (f: 320897024,000000, d: 1,305115e+15)
FPR11 000000004dca7985 (f: 1305115008,000000, d: 6,448125e-315)
FPR12 40b0000000000000 (f: 0,000000, d: 4,096000e+03)
FPR13 4020800000000000 (f: 0,000000, d: 8,250000e+00)
FPR14 0000000000000000 (f: 0,000000, d: 0,000000e+00)
FPR15 0000000000000000 (f: 0,000000, d: 0,000000e+00)
FPR16 0000000000000000 (f: 0,000000, d: 0,000000e+00)
FPR17 0000000000000000 (f: 0,000000, d: 0,000000e+00)
FPR18 0000000000000000 (f: 0,000000, d: 0,000000e+00)
FPR19 0000000000000000 (f: 0,000000, d: 0,000000e+00)
FPR20 0000000000000000 (f: 0,000000, d: 0,000000e+00)
FPR21 0000000000000000 (f: 0,000000, d: 0,000000e+00)
FPR22 0000000000000000 (f: 0,000000, d: 0,000000e+00)
FPR23 0000000000000000 (f: 0,000000, d: 0,000000e+00)
FPR24 0000000000000000 (f: 0,000000, d: 0,000000e+00)
FPR25 0000000000000000 (f: 0,000000, d: 0,000000e+00)
FPR26 0000000000000000 (f: 0,000000, d: 0,000000e+00)
FPR27 0000000000000000 (f: 0,000000, d: 0,000000e+00)
FPR28 0000000000000000 (f: 0,000000, d: 0,000000e+00)
FPR29 0000000000000000 (f: 0,000000, d: 0,000000e+00)
FPR30 0000000000000000 (f: 0,000000, d: 0,000000e+00)
FPR31 0000000000000000 (f: 0,000000, d: 0,000000e+00)
Target=2_60_20121024_126071 (OS/400 V7R1M0)
CPU=ppc64 (4 logical CPUs) (0x4c0000000 RAM)
----------- Stack Backtrace -----------
.VMprJavaSendNative (0x09000000008153D4 [libj9vm26.so+0x933d4])
.java_lang_J9VMInternals_initializeImpl (0x09000000025BC924 [libjclse7b_26.so+0x1d924])
.java_lang_J9VMInternals_newInstanceImpl (0x09000000025BC430 [libjclse7b_26.so+0x1d430])
javaProtectedThreadProc+0x13c (0x0900000000788BC0 [libj9vm26.so+0x6bc0])
j9sig_protect+0x38c (0x090000000091CF30 [libj9prt26.so+0x2f30])
javaThreadProc+0x70 (0x09000000007889F4 [libj9vm26.so+0x69f4])
thread_wrapper+0x14c (0x09000000008ED410 [libj9thr26.so+0x3410])
_pthread_body+0x100 (0x09000000003CAD64 [libpthreads.a+0x3d64])
---------------------------------------
JVMDUMP039I
JVMDUMP032I JVM forderte als Antwort auf ein Ereignis einen Speicherauszug von System mit "/core.20141125.141658.80445.0001.dmp" an
JVMDUMP010I Speicherauszug von System in /core.20141125.141658.80445.0001.dmp geschrieben
JVMDUMP032I JVM forderte als Antwort auf ein Ereignis einen Speicherauszug von Java mit "/javacore.20141125.141658.80445.0002.txt" an
JVMDUMP010I Speicherauszug von Java in /javacore.20141125.141658.80445.0002.txt geschrieben
JVMDUMP032I JVM forderte als Antwort auf ein Ereignis einen Speicherauszug von Snap mit "/Snap.20141125.141658.80445.0003.trc" an
JVMDUMP010I Speicherauszug von Snap in /Snap.20141125.141658.80445.0003.trc geschrieben
JVMDUMP013I Speicherauszugsereignis "gpf", Detail "" wurde verarbeitet.
{code}
> JBOSS 7.1.1.Final hangs on z/OS with new JDK maintenance
> --------------------------------------------------------
>
> Key: WFLY-825
> URL: https://issues.jboss.org/browse/WFLY-825
> Project: WildFly
> Issue Type: Bug
> Components: Server
> Environment: operating system - z/OS version 1.13
> JDK version info:
> java version "1.7.0"
> Java(TM) SE Runtime Environment (build pmz6470sr2-20120901_01(SR2))
> IBM J9 VM (build 2.6, JRE 1.7.0 z/OS s390x-64 20120809_118929 (JIT enabled, AOT enabled)
> J9VM - R26_Java726_SR2_20120809_0948_B118929
> JIT - r11.b01_20120808_24925
> GC - R26_Java726_SR2_20120809_0948_B118929
> J9CL - 20120809_118929)
> JCL - 20120831_02 based on Oracle 7u3-b05
> Reporter: Bob Bennett
> Assignee: Jason Greene
> Labels: jboss
> Attachments: relevant-threads.txt, threadstacks.txt, xnio-nio-3.0.8.GA-SNAPSHOT.jar, xnio-nio-3.0.8.GA-SNAPSHOT.jar
>
>
> When I install the jboss-as-7.1.1.Final on a z/OS system with the newest JDK, and start the standalone server, it gets stuck and never completes initialization. It also does not respond to kill, and requires kill -9 to terminate. I have javacore from the hang. I opened an issue with IBM support, and here is their response:
> Hi Bob,
>
> Have you contacted JBoss support for this issue?
>
> From my review of the javacore, every application-related thread is
> waiting on some kind of internal state monitoring code. The most
> prominent cause of waiting appears to be a CountdownLatch used in:
>
> org/jboss/as/controller/ParallelBootOperationStepHandler
> $ParallelBootTransactionControl.operationPrepared
>
> A quick search found this possibly related JBoss bug which was
> introduced because of incompatibilities with Java 7 (although it would appear to have been fixed before your current build, but I'm not certain
> how.) https://issues.jboss.org/browse/AS7-2940?_sscc=t
>
> The CountdownLatch is one of the Concurrency classes, and is very
> simplistic in that it allows an application to direct threads to wait
> until some certain number of actions have occured. The application code
> (JBoss in this case) would need to explain how many countdowns are
> required and which piece of code decrements the counter as needed.
>
> There's not much to say from a JVM perspective other than the threads
> are all waiting for an application-level event (a call to the
> "countDown()" method 'N' times where 'N' is how many JBoss initialized
> the CountDownLatch to originally.)
>
> If the JBoss team believes there is a specific thread not processing for one reason or another, we could look at that from a JVM perspective to see why. Unfortunately we'd need the JBoss team to explain which thread
> they think should be executing and why. A system dump of the problem
> (taken using signal 3, or from the operator console) would potentially allow for the internal state variables associated here to be read out...
> but that won't really be of any use if we don't know what JBoss expects
> them to be.
>
> Regards,
> Java Defect Support
> Please let me know if you need more info, either from myself or IBM JDK support.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 7 months
[JBoss JIRA] (JGRP-1898) FD_HOST many false suspect with Full GC
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JGRP-1898?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on JGRP-1898:
-----------------------------------------------
Sebastian Łaskawiec <slaskawi(a)redhat.com> changed the Status of [bug 1159162|https://bugzilla.redhat.com/show_bug.cgi?id=1159162] from POST to MODIFIED
> FD_HOST many false suspect with Full GC
> ---------------------------------------
>
> Key: JGRP-1898
> URL: https://issues.jboss.org/browse/JGRP-1898
> Project: JGroups
> Issue Type: Enhancement
> Affects Versions: 3.5.1
> Reporter: Takayoshi Kimura
> Assignee: Takayoshi Kimura
> Fix For: 3.4.7, 3.5.2, 3.6.1
>
> Attachments: test-fdhost.zip
>
>
> Currently FD_HOST PingTask has 2 loops, ping loop and cheking timeout loop.
> {code}
> for (h: hosts) { ping_and_update_timestamp(host) }
> current = System.currentTimeMillis();
> for (h: hosts) { compare current and (ping_timestmp + timeout) }
> {code}
> Testing with large number of hosts, after lengthy Full GC during the ping loop, FD_HOST checks timeout and it counts the Full GC time in, sometimes causes many false suspects.
> For example, 1 min Full GC and 50 sec timeout, all hosts are suspected with current implementation.
> To reduce the impact of the Full GC time, we can combine the 2 loops into 1 loop, ping and checking timeout each host, so the Full GC delay only affects to a single host and never affect to other hosts.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 7 months
[JBoss JIRA] (WFLY-1149) Naming lookup intermittently fails on IBM JDK due to org.jboss.remoting3.NotOpenException: Endpoint is not open.
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-1149?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-1149:
-----------------------------------------------
Jan Martiska <jmartisk(a)redhat.com> changed the Status of [bug 923836|https://bugzilla.redhat.com/show_bug.cgi?id=923836] from ON_QA to VERIFIED
> Naming lookup intermittently fails on IBM JDK due to org.jboss.remoting3.NotOpenException: Endpoint is not open.
> ----------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-1149
> URL: https://issues.jboss.org/browse/WFLY-1149
> Project: WildFly
> Issue Type: Bug
> Components: Naming, Test Suite
> Environment: IBM JDK 6 (build 20110203_074623)
> IBM JDK 7 (build 20120809_118929)
> Reporter: Ivo Studensky
> Assignee: Jason Greene
> Attachments: endpoint_is_not_open_2012-11-26.xml, failed_with_status_cancelled_2012-11-26.xml, test_output_with_trace_logging_in_EndpointCache.xml
>
>
> RemoteNamingTestCase intermittently fails when running on IBM JDK. According to logs the remoting channel had been closed before the endpoint tried to connect to it. Unfortunately, when I was trying to debug this issue the tests always nicely passed.
> test.log snippet:
> {noformat}
> 13:16:31,115 DEBUG [org.xnio.nio] (Remoting "config-based-naming-client-endpoint" read-1) Started channel thread 'Remoting "config-based-naming-client-endpoint" read-1', selector sun.nio.ch.EPollSelectorImpl@345642e1
> 13:16:31,115 DEBUG [org.xnio.nio] (Remoting "config-based-naming-client-endpoint" write-1) Started channel thread 'Remoting "config-based-naming-client-endpoint" write-1', selector sun.nio.ch.EPollSelectorImpl@1dc68cf2
> 13:16:31,121 DEBUG [org.jboss.naming.remote.client.InitialContextFactory] (main) jboss.naming.client.connect.options. has the following options {org.xnio.Options.SASL_POLICY_NOPLAINTEXT=>false}
> 13:16:31,191 ERROR [org.jboss.naming.remote.protocol.v1.RemoteNamingStoreV1] (Remoting "config-based-naming-client-endpoint" task-1) Channel end notification received, closing channel Channel ID d1f17196 (outbound) of Remoting connection fd3dcedc to /127.0.0.1:4447
> 13:16:31,204 DEBUG [org.jboss.naming.remote.client.HaRemoteNamingStore] (main) Failed to connect to server remote://127.0.0.1:4447: org.jboss.remoting3.NotOpenException: Endpoint is not open
> at org.jboss.remoting3.EndpointImpl.resourceUntick(EndpointImpl.java:182)
> at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:261)
> at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:251)
> at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:349)
> at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:333)
> at org.jboss.naming.remote.client.EndpointCache$EndpointWrapper.connect(EndpointCache.java:105)
> at org.jboss.naming.remote.client.HaRemoteNamingStore.failOverSequence(HaRemoteNamingStore.java:179)
> at org.jboss.naming.remote.client.HaRemoteNamingStore.namingOperation(HaRemoteNamingStore.java:117)
> at org.jboss.naming.remote.client.HaRemoteNamingStore.lookup(HaRemoteNamingStore.java:223)
> at org.jboss.naming.remote.client.RemoteContext.lookup(RemoteContext.java:79)
> at org.jboss.naming.remote.client.RemoteContext.lookup(RemoteContext.java:83)
> at javax.naming.InitialContext.lookup(InitialContext.java:422)
> at org.jboss.as.test.integration.naming.remote.simple.RemoteNamingTestCase.testRemoteLookup(RemoteNamingTestCase.java:74)
> {noformat}
> server.log snippet:
> {noformat}
> 13:16:31,025 INFO [org.jboss.as.server] (management-handler-thread - 3) JBAS018559: Deployed "test.jar"
> 13:16:31,163 DEBUG [org.jboss.naming.remote.server.RemoteNamingService] (Remoting "thinkpax" task-3) Channel Opened - Channel ID 51f17196 (inbound) of Remoting connection b9da2788 to /127.0.0.1:46866
> 13:16:31,176 DEBUG [org.jboss.naming.remote.server.RemoteNamingService] (Remoting "thinkpax" task-4) Chosen version 0x01
> 13:16:31,189 DEBUG [org.jboss.naming.remote.server.RemoteNamingService] (Remoting "thinkpax" read-1) Channel Channel ID 51f17196 (inbound) of Remoting connection b9da2788 to /127.0.0.1:46866 closed.
> 13:16:31,193 INFO [org.jboss.as.naming] (Remoting "thinkpax" task-1) JBAS011806: Channel end notification received, closing channel Channel ID 51f17196 (inbound) of Remoting connection b9da2788 to null
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 7 months