[Red Hat JIRA] (JGRP-2506) Loads of error messages of type IllegalArgumentException: Invalid UUID string in org.jgroups.fromString(UUID.java:139) in error log
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2506?page=com.atlassian.jira.plugin... ]
Bela Ban commented on JGRP-2506:
--------------------------------
I agree with your proposed change. Running the testsuite now...
> Loads of error messages of type IllegalArgumentException: Invalid UUID string in org.jgroups.fromString(UUID.java:139) in error log
> -----------------------------------------------------------------------------------------------------------------------------------
>
> Key: JGRP-2506
> URL: https://issues.redhat.com/browse/JGRP-2506
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.2.0
> Reporter: Valeska Dreßler
> Assignee: Bela Ban
> Priority: Major
> Fix For: 5.1, 4.2.7
>
>
> The customer encounters situations, when at server start or after some time one of their server starts to write very big error logs very fast, because of some jgroups issue. This can only be stopped by a server restart.
> They use AWS based on jgroups for communication
> Here are two example log messages:
> server start:
> {code:java}
> [2020-09-29 06:29:01.625 +0200] ERROR <*host name*> ES0 appserver0 [] [] org.jgroups.protocols.FILE_PING [] [] [] [] "ip-<**-**-**-**><*host name*>-startStop-1" JGRP000187: failed reading line of input stream java.lang.IllegalArgumentException: Invalid UUID string:
> at org.jgroups.util.UUID.fromString(UUID.java:139)
> at org.jgroups.protocols.Discovery.read(Discovery.java:455)
> at org.jgroups.protocols.FILE_PING.read(FILE_PING.java:269)
> at org.jgroups.protocols.FILE_PING.read(FILE_PING.java:263)
> at org.jgroups.protocols.FILE_PING.readAll(FILE_PING.java:239)
> at org.jgroups.protocols.FILE_PING.findMembers(FILE_PING.java:124)
> at org.jgroups.protocols.Discovery.invokeFindMembers(Discovery.java:217)
> at org.jgroups.protocols.Discovery.findMembers(Discovery.java:244)
> at org.jgroups.protocols.Discovery.down(Discovery.java:383)
> at org.jgroups.protocols.FILE_PING.down(FILE_PING.java:119)
> at org.jgroups.protocols.MERGE3.down(MERGE3.java:274)
> at org.jgroups.protocols.FD_SOCK.down(FD_SOCK.java:375)
> at org.jgroups.protocols.FD_ALL2.down(FD_ALL2.java:214)
> at org.jgroups.protocols.VERIFY_SUSPECT.down(VERIFY_SUSPECT.java:102)
> at org.jgroups.protocols.pbcast.NAKACK2.down(NAKACK2.java:555)
> at org.jgroups.protocols.UNICAST3.down(UNICAST3.java:595)
> at org.jgroups.protocols.pbcast.STABLE.down(STABLE.java:350)
> at org.jgroups.protocols.pbcast.ClientGmsImpl.joinInternal(ClientGmsImpl.java:72)
> at org.jgroups.protocols.pbcast.ClientGmsImpl.join(ClientGmsImpl.java:41)
> at org.jgroups.protocols.pbcast.GMS.down(GMS.java:1054)
> at org.jgroups.protocols.FlowControl.down(FlowControl.java:300)
> at org.jgroups.protocols.FRAG2.down(FRAG2.java:138)
> at org.jgroups.protocols.RSVP.down(RSVP.java:103)
> at org.jgroups.protocols.pbcast.StreamingStateTransfer.down(StreamingStateTransfer.java:183)
> at org.jgroups.stack.ProtocolStack.down(ProtocolStack.java:908)
> at org.jgroups.JChannel.down(JChannel.java:627)
> at org.jgroups.JChannel._connect(JChannel.java:855)
> at org.jgroups.JChannel.connect(JChannel.java:352)
> at org.jgroups.JChannel.connect(JChannel.java:343)
> at com.intershop.beehive.messaging.internal.jgroups.JGroupsMessenger.createJGroupsObjAndReceiver(JGroupsMessenger.java:230)
> at com.intershop.beehive.messaging.internal.jgroups.JGroupsMessenger.createResourcesAndReceivers(JGroupsMessenger.java:183)
> at com.intershop.beehive.messaging.capi.AbstractMessenger.initialize(AbstractMessenger.java:154)
> at com.intershop.beehive.messaging.capi.MessengerProvider.createMessengerInstance(MessengerProvider.java:133)
> at com.intershop.beehive.messaging.capi.MessengerProvider.createMessenger(MessengerProvider.java:68)
> at com.intershop.beehive.core.internal.event.EventMgrImpl.onStartupHook(EventMgrImpl.java:168)
> at com.intershop.beehive.core.internal.environment.ServerEnvironment.onStartupHook(ServerEnvironment.java:1126)
> at com.intershop.beehive.core.internal.environment.ServerEnvironment.startup(ServerEnvironment.java:2064)
> at com.intershop.beehive.core.internal.environment.ApplicationContextListener.contextInitialized(ApplicationContextListener.java:47)
> at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4939)
> at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5434)
> at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
> at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1559)
> at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1549)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> issue happening later:
> {code:java}
> [2020-09-27 03:55:14.342 +0200] ERROR <*host name*> ES0 appserver0 [] [] org.jgroups.protocols.FILE_PING [] [] [] [] "Timer runner-2,eventChannel,ip-<**-**-**-**>-21247" JGRP000187: failed reading line of input stream java.lang.IllegalArgumentException: Invalid UUID string:
> at org.jgroups.util.UUID.fromString(UUID.java:139)
> at org.jgroups.protocols.Discovery.read(Discovery.java:455)
> at org.jgroups.protocols.FILE_PING.read(FILE_PING.java:269)
> at org.jgroups.protocols.FILE_PING.read(FILE_PING.java:263)
> at org.jgroups.protocols.FILE_PING.readAll(FILE_PING.java:239)
> at org.jgroups.protocols.FILE_PING.findMembers(FILE_PING.java:124)
> at org.jgroups.protocols.Discovery.invokeFindMembers(Discovery.java:217)
> at org.jgroups.protocols.Discovery.findMembers(Discovery.java:244)
> at org.jgroups.protocols.Discovery.down(Discovery.java:387)
> at org.jgroups.protocols.FILE_PING.down(FILE_PING.java:119)
> at org.jgroups.protocols.MERGE3$InfoSender.run(MERGE3.java:412)
> at org.jgroups.util.TimeScheduler3$Task.run(TimeScheduler3.java:328)
> at org.jgroups.util.TimeScheduler3$RecurringTask.run(TimeScheduler3.java:362)
> at org.jgroups.util.TimeScheduler3.submitToPool(TimeScheduler3.java:244)
> at org.jgroups.util.TimeScheduler3.run(TimeScheduler3.java:200)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> In the stack traces the original IPs/ host names of the servers were replaced by <**--****-**>/<*host name*>.
> In both cases the message is written very fast very often and always from the same thread.
> We have error log examples of these sizes:
> 9,1 GB (server startup) - 2453051 occurrences from [2020-09-29 06:19:01.013 +0200] until [2020-09-29 06:29:01.983 +0200] (~10 min)
> 450 MB ((the timer issue above) - 349586 occurrences from [2020-09-27 03:55:14.342 +0200] until [2020-09-27 04:10:20.213 +0200] (~15 min)
> *Steps to repeat:*
> - this happens occasionally. no steps to repeat available
> *Investigations:*
> Especially the second stack trace consists of jgroups classes only.
> With the given sources I analyzed how these messages could be created.
> message JGRP000187 is defined here: JGroups/conf/jg-messages.properties
> {code:java}
> FailedReadingLineOfInputStream = JGRP000187: failed reading line of input stream
> {code}
> Look around this line from the stack trace
> ---------------------------------------------------------------------------
> at org.jgroups.util.UUID.fromString(UUID.java:139)
> ---------------------------------------------------------------------------
> {code:java}
>
> /*136*/ public static UUID fromString(String name) {
> /*137*/ String[] components = name.split("-");
> /*138*/ if (components.length != 5)
> /*139*/ throw new IllegalArgumentException("Invalid UUID string: "+name);
> {code}
> The exception is thrown when the provided string cannot be split into 5 parts by '-".
> We see that the string name is logged appended to the message "Invalid UUID string: "
> In our error message example no value can be seen for name so it must be an empty string that was given to the method UUID.fromString(String name). An empty string obviously does not have 5 parts when split by '-'
> Where is the UUID str given to org.jgroups.util.UUID.fromString?
> Look around this line from the stack trace
> ---------------------------------------------------------------------------
> at org.jgroups.protocols.Discovery.read(Discovery.java:455)
> ---------------------------------------------------------------------------
> {code:java}
> /*437*/ protected List<PingData> read(InputStream in) {
> /*438*/ List<PingData> retval=null;
> /*439*/ try {
> /*440*/ while(true) {
> /*441*/ try {
> /*442*/ String name_str=Util.readToken(in);
> /*443*/ String uuid_str=Util.readToken(in);
> /*444*/ String addr_str=Util.readToken(in);
> /*445*/ String coord_str=Util.readToken(in);
> /*446*/ if(name_str == null || uuid_str == null || addr_str == null || coord_str == null)
> /*447*/ break;
> /*448*/
> /*449*/ UUID uuid=null;
> /*450*/ try {
> /*451*/ long tmp=Long.parseLong(uuid_str);
> /*452*/ uuid=new UUID(0, tmp);
> /*453*/ }
> /*454*/ catch(Throwable t) {
> /*455*/ uuid=UUID.fromString(uuid_str);
> /*456*/ }
> /*457*/
> /*458*/ PhysicalAddress phys_addr=new IpAddress(addr_str);
> /*459*/ boolean is_coordinator=coord_str.trim().equals("T") || coord_str.trim().equals("t");
> /*460*/
> /*461*/ if(retval == null)
> /*462*/ retval=new ArrayList<>();
> /*463*/ retval.add(new PingData(uuid, true, name_str, phys_addr).coord(is_coordinator));
> /*464*/ }
> /*465*/ catch(Throwable t) {
> /*466*/ log.error(Util.getMessage("FailedReadingLineOfInputStream"), t);
> /*467*/ }
> /*468*/ }
> /*469*/ return retval;
> /*470*/ }
> /*471*/ finally {
> /*472*/ Util.close(in);
> /*473*/ }
> /*474*/ }
> {code}
> Here from an input stream four values are read for the different servers in the jgroups cluster: name_str, uuid_str, addr_str and coord_str
> This happens in a while(true) loop.
> We can leave this loop only by a break.
> This break happens at line 447 when the condition in 446 is met:
> if(name_str == null || uuid_str == null || addr_str == null || coord_str == null)
> So if at least one of the four strings read before would be null we could leave this loop.
> We can see that the catch block simply logs the message but does not inerrupt the outer while loop.
> The string uuid_str is read into the local variable in line 443 by String uuid_str=Util.readToken(in)
> Lets have a look at Util.readToken:
> {code:java}
> /*1774*/ /** Returns whitespace-separated strings from the input stream, or null if the end of the stream has been reached */
> /*1775*/ public static String readToken(InputStream in) {
> /*1776*/ StringBuilder sb=new StringBuilder();
> /*1777*/ boolean first=true;
> /*1778*/ int ch;
> /*1779*/ while(true) {
> /*1780*/ try {
> /*1781*/ ch=in.read();
> /*1782*/ if(ch == -1)
> /*1783*/ return sb.length() > 0? sb.toString() : null;
> /*1784*/ if(Character.isWhitespace(ch)) {
> /*1785*/ if(first)
> /*1786*/ continue;
> /*1787*/ break;
> /*1788*/ }
> /*1789*/ sb.append((char)ch);
> /*1790*/ first=false;
> /*1791*/ }
> /*1792*/ catch(IOException e) {
> /*1793*/ break;
> /*1794*/ }
> /*1795*/ }
> /*1796*/ return sb.toString();
> /*1797*/ }
> {code}
> A new instance of StringBuilder is created at line 1776.
> The boolean variable first is set to true in line 1777
> Then a while(true) loop is started.
> It can only be left by a break.
> In the try block we try to read from the given input stream in.
> 1. If the read character is -1 ( end of the stream ) the while loop is left and a value is returned.
> If the string builder sb already has a length > 0 it will be converted to a string and returned. If sb is still empty we return a null.
> 2. If the character is a white space character and we are still at the beginning of the reading (first is true) we will continue until we find a none-whitespace character or the end of the stream. If first is no longer true when a white space character is read the break will bring us to the end of the loop.
> Here all read content is returned as a string converted from sb.
> 3. The character that was read is not a -1 and not a whitespace: We append it to sb and set first to false.
> 4. In case of an IOException the while loop is left, no log message is written.
> Here all read content is returned as a string converted from sb.
> The only possibility for this method to return an empty string (not null) would be: We encounter an IOException at the first reading from in or after only white space characters were read.
> Then the code on line 1796 would return an empty string.
> Now have a look at the code read of Discovery again:
> Reaching the end of the input stream in Util.readToken(in) would be the condition to end reading from the input stream and to return all found PingData as a list.
> With an empty string for every read string variable the break will never be reached and the while loop will not be left, writing an error message at the caught exception on the trial to convert the empty string in uuid_str to a valid UUID.
> So in case the provided input stream throws an IOException on every trial to read from it, we would be in an endless loop.
> We can have a look at which input stream we are in here
> Look around this line from the stack trace
> ---------------------------------------------------------------------------
> at org.jgroups.protocols.FILE_PING.readAll(FILE_PING.java:239)
> ---------------------------------------------------------------------------
> {code:java}
> /*256*/ protected void readAll(List<Address> members, String clustername, Responses responses) {
> /*257*/ File dir=new File(root_dir, clustername);
> /*253*/ if(!dir.exists())
> /*254*/ dir.mkdir();
> /*230*/
> /*231*/ File[] files=dir.listFiles(filter); // finds all files ending with '.list'
> /*232*/ for(File file: files) {
> /*233*/ List<PingData> list=null;
> /*234*/ // implementing a simple spin lock doing a few attempts to read the file
> /*235*/ // this is done since the file may be written in concurrency and may therefore not be readable
> /*236*/ for(int i=0; i < 3; i++) {
> /*237*/ if(file.exists()) {
> /*238*/ try {
> /*239*/ if((list=read(file)) != null)
> /*240*/ break;
> /*241*/ }
> /*242*/ catch(Exception e) {
> /*243*/ }
> /*244*/ }
> /*245*/ Util.sleep(50);
> /*246*/ }
> /*247*/
> /*248*/ if(list == null) {
> /*249*/ log.warn("failed reading " + file.getAbsolutePath());
> /*250*/ continue;
> /*251*/ }
> /*252*/ for(PingData data: list) {
> /*253*/ if(members == null || members.contains(data.getAddress()))
> /*254*/ responses.addResponse(data, true);
> /*255*/ if(local_addr != null && !local_addr.equals(data.getAddress()))
> /*256*/ addDiscoveryResponseToCaches(data.getAddress(), data.getLogicalName(), data.getPhysicalAddr());
> /*257*/ }
> /*258*/ }
> /*259*/ }
> {code}
> Here we read the ping data from a file in a directory that was scanned for all files with the extension .list.
> In our application server that would be one of these directories:
> [IS_SHARE]/system/jgroups/appserverSyncChannel
> [IS_SHARE]/system/jgroups/cacheSyncChannel
> [IS_SHARE]/system/jgroups/ormSyncChannel
> [IS_SHARE]/system/jgroups/tcmSyncChannel
> So my assumption is that our error occurs when somehow a file that just existed is not reachable anymore (if deleted or unreachable because of network issues) and the input stream for it gets unusable, throwing IOExceptions on every trial to read from it.
> My idea how to fix that would be to change the return value of Util readToken on line 1796 like this:
> {code:java}
> old: return sb.toString();
> new: return sb.length() > 0? sb.toString() : null;
> {code}
> Then we would not return an empty value on an IOException and could break the loop in Discovery for a better error handling.
> I already had a look at the code in the most recent version 5.0.4: All involved methods do look still the same.
> I assume we should file a bug report to the jgroups community.
> We suspect an endless loop in the jgroups code.
> The used jgroups version is 4.2.0.
> The warn log does not contain any relevant messages for jgroups at this time
>
> I can provide the original logs for analysis
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
- 1
- 0
[Red Hat JIRA] (WFLY-13956) TwoConnectorsEJBFailoverTestCase sometimes hangs when running with jboss-ejb-client 4.0.35
by Cheng Fang (Jira)
[ https://issues.redhat.com/browse/WFLY-13956?page=com.atlassian.jira.plugi... ]
Cheng Fang edited comment on WFLY-13956 at 10/12/20 10:34 AM:
--------------------------------------------------------------
The failed CI job build log shows a timeout from {{TwoConnectorsEJBFailoverTestCase}}:
{code:xml}
[15:55:12] : [org.wildfly:wildfly-ts-integ-clustering] [INFO] Running org.jboss.as.test.clustering.cluster.ejb.remote.TwoConnectorsEJBFailoverTestCase^M
[15:55:12]i: [Step 2/3] org.jboss.as.test.clustering.cluster.ejb.remote.TransactionalRemoteStatelessTestCase^M
[15:55:12]i: [org.jboss.as.test.clustering.cluster.ejb.remote.TransactionalRemoteStatelessTestCase] affinityCommit_http^M
[15:55:12]i: [org.jboss.as.test.clustering.cluster.ejb.remote.TransactionalRemoteStatelessTestCase] rollbackWithNoXAResourceEnlistment^M
[15:55:12]i: [org.jboss.as.test.clustering.cluster.ejb.remote.TransactionalRemoteStatelessTestCase] rollback_http^M
[15:55:12]i: [org.jboss.as.test.clustering.cluster.ejb.remote.TransactionalRemoteStatelessTestCase] affinityCommit_remoteHttp^M
[15:55:12]i: [org.jboss.as.test.clustering.cluster.ejb.remote.TransactionalRemoteStatelessTestCase] rollback_wildflyConfig^M
[15:55:12]i: [org.jboss.as.test.clustering.cluster.ejb.remote.TransactionalRemoteStatelessTestCase] rollback_remoteHttp^M
[15:55:12]i: [org.jboss.as.test.clustering.cluster.ejb.remote.TransactionalRemoteStatelessTestCase] directLookupFailure^M
[15:55:12]i: [org.jboss.as.test.clustering.cluster.ejb.remote.TransactionalRemoteStatelessTestCase] affinityNodeFailure^M
[15:55:12]i: [org.jboss.as.test.clustering.cluster.ejb.remote.TransactionalRemoteStatelessTestCase] affinityCommit_wildflyConfig^M
[17:18:50] : [org.wildfly:wildfly-ts-integ-clustering] [INFO] ^M
[17:18:50] : [org.wildfly:wildfly-ts-integ-clustering] [INFO] Results:^M
[17:18:50] : [org.wildfly:wildfly-ts-integ-clustering] [INFO] ^M
[17:18:50]W: [org.wildfly:wildfly-ts-integ-clustering] [WARNING] Tests run: 29, Failures: 0, Errors: 0, Skipped: 5^M
[17:18:50] : [org.wildfly:wildfly-ts-integ-clustering] [INFO] ^M
[17:18:50]W: [org.wildfly:wildfly-ts-integ-clustering] [ERROR] There was a timeout or other error in the fork^M
{code}
was (Author: cfang):
The CI job build log shows a timeout from {{TwoConnectorsEJBFailoverTestCase}}:
{code:xml}
[15:55:12] : [org.wildfly:wildfly-ts-integ-clustering] [INFO] Running org.jboss.as.test.clustering.cluster.ejb.remote.TwoConnectorsEJBFailoverTestCase^M
[15:55:12]i: [Step 2/3] org.jboss.as.test.clustering.cluster.ejb.remote.TransactionalRemoteStatelessTestCase^M
[15:55:12]i: [org.jboss.as.test.clustering.cluster.ejb.remote.TransactionalRemoteStatelessTestCase] affinityCommit_http^M
[15:55:12]i: [org.jboss.as.test.clustering.cluster.ejb.remote.TransactionalRemoteStatelessTestCase] rollbackWithNoXAResourceEnlistment^M
[15:55:12]i: [org.jboss.as.test.clustering.cluster.ejb.remote.TransactionalRemoteStatelessTestCase] rollback_http^M
[15:55:12]i: [org.jboss.as.test.clustering.cluster.ejb.remote.TransactionalRemoteStatelessTestCase] affinityCommit_remoteHttp^M
[15:55:12]i: [org.jboss.as.test.clustering.cluster.ejb.remote.TransactionalRemoteStatelessTestCase] rollback_wildflyConfig^M
[15:55:12]i: [org.jboss.as.test.clustering.cluster.ejb.remote.TransactionalRemoteStatelessTestCase] rollback_remoteHttp^M
[15:55:12]i: [org.jboss.as.test.clustering.cluster.ejb.remote.TransactionalRemoteStatelessTestCase] directLookupFailure^M
[15:55:12]i: [org.jboss.as.test.clustering.cluster.ejb.remote.TransactionalRemoteStatelessTestCase] affinityNodeFailure^M
[15:55:12]i: [org.jboss.as.test.clustering.cluster.ejb.remote.TransactionalRemoteStatelessTestCase] affinityCommit_wildflyConfig^M
[17:18:50] : [org.wildfly:wildfly-ts-integ-clustering] [INFO] ^M
[17:18:50] : [org.wildfly:wildfly-ts-integ-clustering] [INFO] Results:^M
[17:18:50] : [org.wildfly:wildfly-ts-integ-clustering] [INFO] ^M
[17:18:50]W: [org.wildfly:wildfly-ts-integ-clustering] [WARNING] Tests run: 29, Failures: 0, Errors: 0, Skipped: 5^M
[17:18:50] : [org.wildfly:wildfly-ts-integ-clustering] [INFO] ^M
[17:18:50]W: [org.wildfly:wildfly-ts-integ-clustering] [ERROR] There was a timeout or other error in the fork^M
{code}
> TwoConnectorsEJBFailoverTestCase sometimes hangs when running with jboss-ejb-client 4.0.35
> ------------------------------------------------------------------------------------------
>
> Key: WFLY-13956
> URL: https://issues.redhat.com/browse/WFLY-13956
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 21.0.0.Beta1
> Reporter: Cheng Fang
> Assignee: Cheng Fang
> Priority: Major
> Attachments: Screen Shot 2020-10-12 at 9.57.36 AM.png
>
>
> When upgrading jboss-ejb-client to version 4.0.35.Final, we noticed some WildFly CI jobs sometimes hang when running {{TwoConnectorsEJBFailoverTestCase}}, causing 100+ (e.g., 466) tests to fail:
> {code}
> RemoteElytronSingleSignOnTestCase.testSessionTimeoutDestroysSSOorg.jboss.as.test.clustering.cluster.sso.remote
> RemoteElytronSingleSignOnTestCase.testFormAuthSingleSignOnorg.jboss.as.test.clustering.cluster.sso.remote
> RemoteElytronSingleSignOnTestCase.testNoAuthSingleSignOnorg.jboss.as.test.clustering.cluster.sso.remote
> RemoteSingleSignOnTestCase.testSessionTimeoutDestroysSSOorg.jboss.as.test.clustering.cluster.sso.remote
> RemoteSingleSignOnTestCase.testFormAuthSingleSignOnorg.jboss.as.test.clustering.cluster.sso.remote
> RemoteSingleSignOnTestCase.testNoAuthSingleSignOnorg.jboss.as.test.clustering.cluster.sso.remote
> CoarseHotRodPersistenceWebFailoverTestCase.testGracefulUndeployFailoverorg.jboss.as.test.clustering.cluster.web.remote
> CoarseHotRodPersistenceWebFailoverTestCase.testNonPrimaryOwnerorg.jboss.as.test.clustering.cluster.web.remote
> CoarseHotRodPersistenceWebFailoverTestCase.testGracefulSimpleFailoverorg.jboss.as.test.clustering.cluster.web.remote
> CoarseHotRodSessionActivationTestCase.testorg.jboss.as.test.clustering.cluster.web.remote
> CoarseHotRodWebFailoverTestCase.testGracefulUndeployFailoverorg.jboss.as.test.clustering.cluster.web.remote
> CoarseHotRodWebFailoverTestCase.testNonPrimaryOwnerorg.jboss.as.test.clustering.cluster.web.remote
> CoarseHotRodWebFailoverTestCase.testGracefulSimpleFailoverorg.jboss.as.test.clustering.cluster.web.remote
> CoarseTransactionalHotRodWebFailoverTestCase.testGracefulUndeployFailoverorg.jboss.as.test.clustering.cluster.web.remote
> CoarseTransactionalHotRodWebFailoverTestCase.testNonPrimaryOwnerorg.jboss.as.test.clustering.cluster.web.remote
> CoarseTransactionalHotRodWebFailoverTestCase.testGracefulSimpleFailoverorg.jboss.as.test.clustering.cluster.web.remote
> FineHotRodPersistenceWebFailoverTestCase.testGracefulUndeployFailoverorg.jboss.as.test.clustering.cluster.web.remote
> {code}
> The error messages are like:
> {code}
> org.jboss.arquillian.container.spi.client.container.LifecycleException: The port 9990 is already in use. It means that either the server might be already running or there is another process using port 9990.
> Managed containers do not support connecting to running server instances due to the possible harmful effect of connecting to the wrong server.
> Please stop server (or another process) before running, change to another type of container (e.g. remote) or use jboss.socket.binding.port-offset variable to change the default port.
> To disable this check and allow Arquillian to connect to a running server, set allowConnectingToRunningServer to true in the container configuration
> {code}
> In a [successful CI job|https://ci.wildfly.org/buildConfiguration/WFPR/226438?], {{TwoConnectorsEJBFailoverTestCase}} runs 2 tests: {{testEJBClientUsingLegacyRemotingProtocol}} and {{testEJBClientUsingHttpUpgradeProtocol}}, each taking ~25 seconds to complete. See attached screenshot.
> But in a [failed CI job|https://ci.wildfly.org/buildConfiguration/WF_PullRequest_LinuxJdk11/2...], filtering by {{TwoConnectorsEJBFailoverTestCase}} gives no result, which means the test hangs at {{testEJBClientUsingLegacyRemotingProtocol}} and so the test runner hasn't been able to collect the result from either test.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
- 1
- 0
[Red Hat JIRA] (WFLY-13956) TwoConnectorsEJBFailoverTestCase sometimes hangs when running with jboss-ejb-client 4.0.35
by Cheng Fang (Jira)
[ https://issues.redhat.com/browse/WFLY-13956?page=com.atlassian.jira.plugi... ]
Cheng Fang commented on WFLY-13956:
-----------------------------------
The CI job build log shows a timeout from {{TwoConnectorsEJBFailoverTestCase}}:
{code:xml}
[15:55:12] : [org.wildfly:wildfly-ts-integ-clustering] [INFO] Running org.jboss.as.test.clustering.cluster.ejb.remote.TwoConnectorsEJBFailoverTestCase^M
[15:55:12]i: [Step 2/3] org.jboss.as.test.clustering.cluster.ejb.remote.TransactionalRemoteStatelessTestCase^M
[15:55:12]i: [org.jboss.as.test.clustering.cluster.ejb.remote.TransactionalRemoteStatelessTestCase] affinityCommit_http^M
[15:55:12]i: [org.jboss.as.test.clustering.cluster.ejb.remote.TransactionalRemoteStatelessTestCase] rollbackWithNoXAResourceEnlistment^M
[15:55:12]i: [org.jboss.as.test.clustering.cluster.ejb.remote.TransactionalRemoteStatelessTestCase] rollback_http^M
[15:55:12]i: [org.jboss.as.test.clustering.cluster.ejb.remote.TransactionalRemoteStatelessTestCase] affinityCommit_remoteHttp^M
[15:55:12]i: [org.jboss.as.test.clustering.cluster.ejb.remote.TransactionalRemoteStatelessTestCase] rollback_wildflyConfig^M
[15:55:12]i: [org.jboss.as.test.clustering.cluster.ejb.remote.TransactionalRemoteStatelessTestCase] rollback_remoteHttp^M
[15:55:12]i: [org.jboss.as.test.clustering.cluster.ejb.remote.TransactionalRemoteStatelessTestCase] directLookupFailure^M
[15:55:12]i: [org.jboss.as.test.clustering.cluster.ejb.remote.TransactionalRemoteStatelessTestCase] affinityNodeFailure^M
[15:55:12]i: [org.jboss.as.test.clustering.cluster.ejb.remote.TransactionalRemoteStatelessTestCase] affinityCommit_wildflyConfig^M
[17:18:50] : [org.wildfly:wildfly-ts-integ-clustering] [INFO] ^M
[17:18:50] : [org.wildfly:wildfly-ts-integ-clustering] [INFO] Results:^M
[17:18:50] : [org.wildfly:wildfly-ts-integ-clustering] [INFO] ^M
[17:18:50]W: [org.wildfly:wildfly-ts-integ-clustering] [WARNING] Tests run: 29, Failures: 0, Errors: 0, Skipped: 5^M
[17:18:50] : [org.wildfly:wildfly-ts-integ-clustering] [INFO] ^M
[17:18:50]W: [org.wildfly:wildfly-ts-integ-clustering] [ERROR] There was a timeout or other error in the fork^M
{code}
> TwoConnectorsEJBFailoverTestCase sometimes hangs when running with jboss-ejb-client 4.0.35
> ------------------------------------------------------------------------------------------
>
> Key: WFLY-13956
> URL: https://issues.redhat.com/browse/WFLY-13956
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 21.0.0.Beta1
> Reporter: Cheng Fang
> Assignee: Cheng Fang
> Priority: Major
> Attachments: Screen Shot 2020-10-12 at 9.57.36 AM.png
>
>
> When upgrading jboss-ejb-client to version 4.0.35.Final, we noticed some WildFly CI jobs sometimes hang when running {{TwoConnectorsEJBFailoverTestCase}}, causing 100+ (e.g., 466) tests to fail:
> {code}
> RemoteElytronSingleSignOnTestCase.testSessionTimeoutDestroysSSOorg.jboss.as.test.clustering.cluster.sso.remote
> RemoteElytronSingleSignOnTestCase.testFormAuthSingleSignOnorg.jboss.as.test.clustering.cluster.sso.remote
> RemoteElytronSingleSignOnTestCase.testNoAuthSingleSignOnorg.jboss.as.test.clustering.cluster.sso.remote
> RemoteSingleSignOnTestCase.testSessionTimeoutDestroysSSOorg.jboss.as.test.clustering.cluster.sso.remote
> RemoteSingleSignOnTestCase.testFormAuthSingleSignOnorg.jboss.as.test.clustering.cluster.sso.remote
> RemoteSingleSignOnTestCase.testNoAuthSingleSignOnorg.jboss.as.test.clustering.cluster.sso.remote
> CoarseHotRodPersistenceWebFailoverTestCase.testGracefulUndeployFailoverorg.jboss.as.test.clustering.cluster.web.remote
> CoarseHotRodPersistenceWebFailoverTestCase.testNonPrimaryOwnerorg.jboss.as.test.clustering.cluster.web.remote
> CoarseHotRodPersistenceWebFailoverTestCase.testGracefulSimpleFailoverorg.jboss.as.test.clustering.cluster.web.remote
> CoarseHotRodSessionActivationTestCase.testorg.jboss.as.test.clustering.cluster.web.remote
> CoarseHotRodWebFailoverTestCase.testGracefulUndeployFailoverorg.jboss.as.test.clustering.cluster.web.remote
> CoarseHotRodWebFailoverTestCase.testNonPrimaryOwnerorg.jboss.as.test.clustering.cluster.web.remote
> CoarseHotRodWebFailoverTestCase.testGracefulSimpleFailoverorg.jboss.as.test.clustering.cluster.web.remote
> CoarseTransactionalHotRodWebFailoverTestCase.testGracefulUndeployFailoverorg.jboss.as.test.clustering.cluster.web.remote
> CoarseTransactionalHotRodWebFailoverTestCase.testNonPrimaryOwnerorg.jboss.as.test.clustering.cluster.web.remote
> CoarseTransactionalHotRodWebFailoverTestCase.testGracefulSimpleFailoverorg.jboss.as.test.clustering.cluster.web.remote
> FineHotRodPersistenceWebFailoverTestCase.testGracefulUndeployFailoverorg.jboss.as.test.clustering.cluster.web.remote
> {code}
> The error messages are like:
> {code}
> org.jboss.arquillian.container.spi.client.container.LifecycleException: The port 9990 is already in use. It means that either the server might be already running or there is another process using port 9990.
> Managed containers do not support connecting to running server instances due to the possible harmful effect of connecting to the wrong server.
> Please stop server (or another process) before running, change to another type of container (e.g. remote) or use jboss.socket.binding.port-offset variable to change the default port.
> To disable this check and allow Arquillian to connect to a running server, set allowConnectingToRunningServer to true in the container configuration
> {code}
> In a [successful CI job|https://ci.wildfly.org/buildConfiguration/WFPR/226438?], {{TwoConnectorsEJBFailoverTestCase}} runs 2 tests: {{testEJBClientUsingLegacyRemotingProtocol}} and {{testEJBClientUsingHttpUpgradeProtocol}}, each taking ~25 seconds to complete. See attached screenshot.
> But in a [failed CI job|https://ci.wildfly.org/buildConfiguration/WF_PullRequest_LinuxJdk11/2...], filtering by {{TwoConnectorsEJBFailoverTestCase}} gives no result, which means the test hangs at {{testEJBClientUsingLegacyRemotingProtocol}} and so the test runner hasn't been able to collect the result from either test.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
- 1
- 0
[Red Hat JIRA] (WFLY-13956) TwoConnectorsEJBFailoverTestCase sometimes hangs when running with jboss-ejb-client 4.0.35
by Cheng Fang (Jira)
[ https://issues.redhat.com/browse/WFLY-13956?page=com.atlassian.jira.plugi... ]
Cheng Fang updated WFLY-13956:
------------------------------
Description:
When upgrading jboss-ejb-client to version 4.0.35.Final, we noticed some WildFly CI jobs sometimes hang when running {{TwoConnectorsEJBFailoverTestCase}}, causing 100+ (e.g., 466) tests to fail:
{code}
RemoteElytronSingleSignOnTestCase.testSessionTimeoutDestroysSSOorg.jboss.as.test.clustering.cluster.sso.remote
RemoteElytronSingleSignOnTestCase.testFormAuthSingleSignOnorg.jboss.as.test.clustering.cluster.sso.remote
RemoteElytronSingleSignOnTestCase.testNoAuthSingleSignOnorg.jboss.as.test.clustering.cluster.sso.remote
RemoteSingleSignOnTestCase.testSessionTimeoutDestroysSSOorg.jboss.as.test.clustering.cluster.sso.remote
RemoteSingleSignOnTestCase.testFormAuthSingleSignOnorg.jboss.as.test.clustering.cluster.sso.remote
RemoteSingleSignOnTestCase.testNoAuthSingleSignOnorg.jboss.as.test.clustering.cluster.sso.remote
CoarseHotRodPersistenceWebFailoverTestCase.testGracefulUndeployFailoverorg.jboss.as.test.clustering.cluster.web.remote
CoarseHotRodPersistenceWebFailoverTestCase.testNonPrimaryOwnerorg.jboss.as.test.clustering.cluster.web.remote
CoarseHotRodPersistenceWebFailoverTestCase.testGracefulSimpleFailoverorg.jboss.as.test.clustering.cluster.web.remote
CoarseHotRodSessionActivationTestCase.testorg.jboss.as.test.clustering.cluster.web.remote
CoarseHotRodWebFailoverTestCase.testGracefulUndeployFailoverorg.jboss.as.test.clustering.cluster.web.remote
CoarseHotRodWebFailoverTestCase.testNonPrimaryOwnerorg.jboss.as.test.clustering.cluster.web.remote
CoarseHotRodWebFailoverTestCase.testGracefulSimpleFailoverorg.jboss.as.test.clustering.cluster.web.remote
CoarseTransactionalHotRodWebFailoverTestCase.testGracefulUndeployFailoverorg.jboss.as.test.clustering.cluster.web.remote
CoarseTransactionalHotRodWebFailoverTestCase.testNonPrimaryOwnerorg.jboss.as.test.clustering.cluster.web.remote
CoarseTransactionalHotRodWebFailoverTestCase.testGracefulSimpleFailoverorg.jboss.as.test.clustering.cluster.web.remote
FineHotRodPersistenceWebFailoverTestCase.testGracefulUndeployFailoverorg.jboss.as.test.clustering.cluster.web.remote
{code}
The error messages are like:
{code}
org.jboss.arquillian.container.spi.client.container.LifecycleException: The port 9990 is already in use. It means that either the server might be already running or there is another process using port 9990.
Managed containers do not support connecting to running server instances due to the possible harmful effect of connecting to the wrong server.
Please stop server (or another process) before running, change to another type of container (e.g. remote) or use jboss.socket.binding.port-offset variable to change the default port.
To disable this check and allow Arquillian to connect to a running server, set allowConnectingToRunningServer to true in the container configuration
{code}
In a [successful CI job|https://ci.wildfly.org/buildConfiguration/WFPR/226438?], {{TwoConnectorsEJBFailoverTestCase}} runs 2 tests: {{testEJBClientUsingLegacyRemotingProtocol}} and {{testEJBClientUsingHttpUpgradeProtocol}}, each taking ~25 seconds to complete. See attached screenshot.
But in a [failed CI job|https://ci.wildfly.org/buildConfiguration/WF_PullRequest_LinuxJdk11/2...], filtering by {{TwoConnectorsEJBFailoverTestCase}} gives no result, which means the test hangs at {{testEJBClientUsingLegacyRemotingProtocol}} and so the test runner hasn't been able to collect the result from either test.
was:
When upgrading jboss-ejb-client to version 4.0.35.Final, we noticed some WildFly CI jobs sometimes hang when running {{TwoConnectorsEJBFailoverTestCase}}, causing 100+ (e.g., 466) tests to fail:
{code}
RemoteElytronSingleSignOnTestCase.testSessionTimeoutDestroysSSOorg.jboss.as.test.clustering.cluster.sso.remote
RemoteElytronSingleSignOnTestCase.testFormAuthSingleSignOnorg.jboss.as.test.clustering.cluster.sso.remote
RemoteElytronSingleSignOnTestCase.testNoAuthSingleSignOnorg.jboss.as.test.clustering.cluster.sso.remote
RemoteSingleSignOnTestCase.testSessionTimeoutDestroysSSOorg.jboss.as.test.clustering.cluster.sso.remote
RemoteSingleSignOnTestCase.testFormAuthSingleSignOnorg.jboss.as.test.clustering.cluster.sso.remote
RemoteSingleSignOnTestCase.testNoAuthSingleSignOnorg.jboss.as.test.clustering.cluster.sso.remote
CoarseHotRodPersistenceWebFailoverTestCase.testGracefulUndeployFailoverorg.jboss.as.test.clustering.cluster.web.remote
CoarseHotRodPersistenceWebFailoverTestCase.testNonPrimaryOwnerorg.jboss.as.test.clustering.cluster.web.remote
CoarseHotRodPersistenceWebFailoverTestCase.testGracefulSimpleFailoverorg.jboss.as.test.clustering.cluster.web.remote
CoarseHotRodSessionActivationTestCase.testorg.jboss.as.test.clustering.cluster.web.remote
CoarseHotRodWebFailoverTestCase.testGracefulUndeployFailoverorg.jboss.as.test.clustering.cluster.web.remote
CoarseHotRodWebFailoverTestCase.testNonPrimaryOwnerorg.jboss.as.test.clustering.cluster.web.remote
CoarseHotRodWebFailoverTestCase.testGracefulSimpleFailoverorg.jboss.as.test.clustering.cluster.web.remote
CoarseTransactionalHotRodWebFailoverTestCase.testGracefulUndeployFailoverorg.jboss.as.test.clustering.cluster.web.remote
CoarseTransactionalHotRodWebFailoverTestCase.testNonPrimaryOwnerorg.jboss.as.test.clustering.cluster.web.remote
CoarseTransactionalHotRodWebFailoverTestCase.testGracefulSimpleFailoverorg.jboss.as.test.clustering.cluster.web.remote
FineHotRodPersistenceWebFailoverTestCase.testGracefulUndeployFailoverorg.jboss.as.test.clustering.cluster.web.remote
{code}
The error messages are like:
{code}
org.jboss.arquillian.container.spi.client.container.LifecycleException: The port 9990 is already in use. It means that either the server might be already running or there is another process using port 9990.
Managed containers do not support connecting to running server instances due to the possible harmful effect of connecting to the wrong server.
Please stop server (or another process) before running, change to another type of container (e.g. remote) or use jboss.socket.binding.port-offset variable to change the default port.
To disable this check and allow Arquillian to connect to a running server, set allowConnectingToRunningServer to true in the container configuration
{code}
In a [successful CI job|https://ci.wildfly.org/buildConfiguration/WFPR/226438?], {{TwoConnectorsEJBFailoverTestCase}} runs 2 tests: {{testEJBClientUsingLegacyRemotingProtocol}} and {{testEJBClientUsingHttpUpgradeProtocol}}, each taking ~25 seconds to complete. See attached screenshot.
But in a [failed CI job|https://ci.wildfly.org/buildConfiguration/WF_PullRequest_LinuxJdk11/2...], filtering by {{TwoConnectorsEJBFailoverTestCase}} gives no result, which means the test hangs at {{testEJBClientUsingLegacyRemotingProtocol}}.
> TwoConnectorsEJBFailoverTestCase sometimes hangs when running with jboss-ejb-client 4.0.35
> ------------------------------------------------------------------------------------------
>
> Key: WFLY-13956
> URL: https://issues.redhat.com/browse/WFLY-13956
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 21.0.0.Beta1
> Reporter: Cheng Fang
> Assignee: Cheng Fang
> Priority: Major
> Attachments: Screen Shot 2020-10-12 at 9.57.36 AM.png
>
>
> When upgrading jboss-ejb-client to version 4.0.35.Final, we noticed some WildFly CI jobs sometimes hang when running {{TwoConnectorsEJBFailoverTestCase}}, causing 100+ (e.g., 466) tests to fail:
> {code}
> RemoteElytronSingleSignOnTestCase.testSessionTimeoutDestroysSSOorg.jboss.as.test.clustering.cluster.sso.remote
> RemoteElytronSingleSignOnTestCase.testFormAuthSingleSignOnorg.jboss.as.test.clustering.cluster.sso.remote
> RemoteElytronSingleSignOnTestCase.testNoAuthSingleSignOnorg.jboss.as.test.clustering.cluster.sso.remote
> RemoteSingleSignOnTestCase.testSessionTimeoutDestroysSSOorg.jboss.as.test.clustering.cluster.sso.remote
> RemoteSingleSignOnTestCase.testFormAuthSingleSignOnorg.jboss.as.test.clustering.cluster.sso.remote
> RemoteSingleSignOnTestCase.testNoAuthSingleSignOnorg.jboss.as.test.clustering.cluster.sso.remote
> CoarseHotRodPersistenceWebFailoverTestCase.testGracefulUndeployFailoverorg.jboss.as.test.clustering.cluster.web.remote
> CoarseHotRodPersistenceWebFailoverTestCase.testNonPrimaryOwnerorg.jboss.as.test.clustering.cluster.web.remote
> CoarseHotRodPersistenceWebFailoverTestCase.testGracefulSimpleFailoverorg.jboss.as.test.clustering.cluster.web.remote
> CoarseHotRodSessionActivationTestCase.testorg.jboss.as.test.clustering.cluster.web.remote
> CoarseHotRodWebFailoverTestCase.testGracefulUndeployFailoverorg.jboss.as.test.clustering.cluster.web.remote
> CoarseHotRodWebFailoverTestCase.testNonPrimaryOwnerorg.jboss.as.test.clustering.cluster.web.remote
> CoarseHotRodWebFailoverTestCase.testGracefulSimpleFailoverorg.jboss.as.test.clustering.cluster.web.remote
> CoarseTransactionalHotRodWebFailoverTestCase.testGracefulUndeployFailoverorg.jboss.as.test.clustering.cluster.web.remote
> CoarseTransactionalHotRodWebFailoverTestCase.testNonPrimaryOwnerorg.jboss.as.test.clustering.cluster.web.remote
> CoarseTransactionalHotRodWebFailoverTestCase.testGracefulSimpleFailoverorg.jboss.as.test.clustering.cluster.web.remote
> FineHotRodPersistenceWebFailoverTestCase.testGracefulUndeployFailoverorg.jboss.as.test.clustering.cluster.web.remote
> {code}
> The error messages are like:
> {code}
> org.jboss.arquillian.container.spi.client.container.LifecycleException: The port 9990 is already in use. It means that either the server might be already running or there is another process using port 9990.
> Managed containers do not support connecting to running server instances due to the possible harmful effect of connecting to the wrong server.
> Please stop server (or another process) before running, change to another type of container (e.g. remote) or use jboss.socket.binding.port-offset variable to change the default port.
> To disable this check and allow Arquillian to connect to a running server, set allowConnectingToRunningServer to true in the container configuration
> {code}
> In a [successful CI job|https://ci.wildfly.org/buildConfiguration/WFPR/226438?], {{TwoConnectorsEJBFailoverTestCase}} runs 2 tests: {{testEJBClientUsingLegacyRemotingProtocol}} and {{testEJBClientUsingHttpUpgradeProtocol}}, each taking ~25 seconds to complete. See attached screenshot.
> But in a [failed CI job|https://ci.wildfly.org/buildConfiguration/WF_PullRequest_LinuxJdk11/2...], filtering by {{TwoConnectorsEJBFailoverTestCase}} gives no result, which means the test hangs at {{testEJBClientUsingLegacyRemotingProtocol}} and so the test runner hasn't been able to collect the result from either test.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
- 1
- 0
[Red Hat JIRA] (WFLY-13956) TwoConnectorsEJBFailoverTestCase sometimes hangs when running with jboss-ejb-client 4.0.35
by Cheng Fang (Jira)
[ https://issues.redhat.com/browse/WFLY-13956?page=com.atlassian.jira.plugi... ]
Cheng Fang updated WFLY-13956:
------------------------------
Description:
When upgrading jboss-ejb-client to version 4.0.35.Final, we noticed some WildFly CI jobs sometimes hang when running {{TwoConnectorsEJBFailoverTestCase}}, causing 100+ (e.g., 466) tests to fail:
{code}
RemoteElytronSingleSignOnTestCase.testSessionTimeoutDestroysSSOorg.jboss.as.test.clustering.cluster.sso.remote
RemoteElytronSingleSignOnTestCase.testFormAuthSingleSignOnorg.jboss.as.test.clustering.cluster.sso.remote
RemoteElytronSingleSignOnTestCase.testNoAuthSingleSignOnorg.jboss.as.test.clustering.cluster.sso.remote
RemoteSingleSignOnTestCase.testSessionTimeoutDestroysSSOorg.jboss.as.test.clustering.cluster.sso.remote
RemoteSingleSignOnTestCase.testFormAuthSingleSignOnorg.jboss.as.test.clustering.cluster.sso.remote
RemoteSingleSignOnTestCase.testNoAuthSingleSignOnorg.jboss.as.test.clustering.cluster.sso.remote
CoarseHotRodPersistenceWebFailoverTestCase.testGracefulUndeployFailoverorg.jboss.as.test.clustering.cluster.web.remote
CoarseHotRodPersistenceWebFailoverTestCase.testNonPrimaryOwnerorg.jboss.as.test.clustering.cluster.web.remote
CoarseHotRodPersistenceWebFailoverTestCase.testGracefulSimpleFailoverorg.jboss.as.test.clustering.cluster.web.remote
CoarseHotRodSessionActivationTestCase.testorg.jboss.as.test.clustering.cluster.web.remote
CoarseHotRodWebFailoverTestCase.testGracefulUndeployFailoverorg.jboss.as.test.clustering.cluster.web.remote
CoarseHotRodWebFailoverTestCase.testNonPrimaryOwnerorg.jboss.as.test.clustering.cluster.web.remote
CoarseHotRodWebFailoverTestCase.testGracefulSimpleFailoverorg.jboss.as.test.clustering.cluster.web.remote
CoarseTransactionalHotRodWebFailoverTestCase.testGracefulUndeployFailoverorg.jboss.as.test.clustering.cluster.web.remote
CoarseTransactionalHotRodWebFailoverTestCase.testNonPrimaryOwnerorg.jboss.as.test.clustering.cluster.web.remote
CoarseTransactionalHotRodWebFailoverTestCase.testGracefulSimpleFailoverorg.jboss.as.test.clustering.cluster.web.remote
FineHotRodPersistenceWebFailoverTestCase.testGracefulUndeployFailoverorg.jboss.as.test.clustering.cluster.web.remote
{code}
The error messages are like:
{code}
org.jboss.arquillian.container.spi.client.container.LifecycleException: The port 9990 is already in use. It means that either the server might be already running or there is another process using port 9990.
Managed containers do not support connecting to running server instances due to the possible harmful effect of connecting to the wrong server.
Please stop server (or another process) before running, change to another type of container (e.g. remote) or use jboss.socket.binding.port-offset variable to change the default port.
To disable this check and allow Arquillian to connect to a running server, set allowConnectingToRunningServer to true in the container configuration
{code}
In a [successful CI job|https://ci.wildfly.org/buildConfiguration/WFPR/226438?], {{TwoConnectorsEJBFailoverTestCase}} runs 2 tests: {{testEJBClientUsingLegacyRemotingProtocol}} and {{testEJBClientUsingHttpUpgradeProtocol}}, each taking ~25 seconds to complete. See attached screenshot.
But in a [failed CI job|https://ci.wildfly.org/buildConfiguration/WF_PullRequest_LinuxJdk11/2...], filtering by {{TwoConnectorsEJBFailoverTestCase}} gives no result, which means the test hangs at {{testEJBClientUsingLegacyRemotingProtocol}}.
was:
When upgrading jboss-ejb-client to version 4.0.35.Final, we noticed some WildFly CI jobs sometimes hang when running {{TwoConnectorsEJBFailoverTestCase}}, causing 100+ (e.g., 466) tests to fail:
{code}
RemoteElytronSingleSignOnTestCase.testSessionTimeoutDestroysSSOorg.jboss.as.test.clustering.cluster.sso.remote
RemoteElytronSingleSignOnTestCase.testFormAuthSingleSignOnorg.jboss.as.test.clustering.cluster.sso.remote
RemoteElytronSingleSignOnTestCase.testNoAuthSingleSignOnorg.jboss.as.test.clustering.cluster.sso.remote
RemoteSingleSignOnTestCase.testSessionTimeoutDestroysSSOorg.jboss.as.test.clustering.cluster.sso.remote
RemoteSingleSignOnTestCase.testFormAuthSingleSignOnorg.jboss.as.test.clustering.cluster.sso.remote
RemoteSingleSignOnTestCase.testNoAuthSingleSignOnorg.jboss.as.test.clustering.cluster.sso.remote
CoarseHotRodPersistenceWebFailoverTestCase.testGracefulUndeployFailoverorg.jboss.as.test.clustering.cluster.web.remote
CoarseHotRodPersistenceWebFailoverTestCase.testNonPrimaryOwnerorg.jboss.as.test.clustering.cluster.web.remote
CoarseHotRodPersistenceWebFailoverTestCase.testGracefulSimpleFailoverorg.jboss.as.test.clustering.cluster.web.remote
CoarseHotRodSessionActivationTestCase.testorg.jboss.as.test.clustering.cluster.web.remote
CoarseHotRodWebFailoverTestCase.testGracefulUndeployFailoverorg.jboss.as.test.clustering.cluster.web.remote
CoarseHotRodWebFailoverTestCase.testNonPrimaryOwnerorg.jboss.as.test.clustering.cluster.web.remote
CoarseHotRodWebFailoverTestCase.testGracefulSimpleFailoverorg.jboss.as.test.clustering.cluster.web.remote
CoarseTransactionalHotRodWebFailoverTestCase.testGracefulUndeployFailoverorg.jboss.as.test.clustering.cluster.web.remote
CoarseTransactionalHotRodWebFailoverTestCase.testNonPrimaryOwnerorg.jboss.as.test.clustering.cluster.web.remote
CoarseTransactionalHotRodWebFailoverTestCase.testGracefulSimpleFailoverorg.jboss.as.test.clustering.cluster.web.remote
FineHotRodPersistenceWebFailoverTestCase.testGracefulUndeployFailoverorg.jboss.as.test.clustering.cluster.web.remote
{code}
In a [successful CI job|https://ci.wildfly.org/buildConfiguration/WFPR/226438?], {{TwoConnectorsEJBFailoverTestCase}} runs 2 tests: {{testEJBClientUsingLegacyRemotingProtocol}} and {{testEJBClientUsingHttpUpgradeProtocol}}, each taking ~25 seconds to complete. See attached screenshot. But in a [failed CI job|https://ci.wildfly.org/buildConfiguration/WF_PullRequest_LinuxJdk11/2...], filtering by {{TwoConnectorsEJBFailoverTestCase}} gives no result, which means the test hangs at {{testEJBClientUsingLegacyRemotingProtocol}}.
The error messages are like:
{code}
org.jboss.arquillian.container.spi.client.container.LifecycleException: The port 9990 is already in use. It means that either the server might be already running or there is another process using port 9990.
Managed containers do not support connecting to running server instances due to the possible harmful effect of connecting to the wrong server.
Please stop server (or another process) before running, change to another type of container (e.g. remote) or use jboss.socket.binding.port-offset variable to change the default port.
To disable this check and allow Arquillian to connect to a running server, set allowConnectingToRunningServer to true in the container configuration
{code}
> TwoConnectorsEJBFailoverTestCase sometimes hangs when running with jboss-ejb-client 4.0.35
> ------------------------------------------------------------------------------------------
>
> Key: WFLY-13956
> URL: https://issues.redhat.com/browse/WFLY-13956
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 21.0.0.Beta1
> Reporter: Cheng Fang
> Assignee: Cheng Fang
> Priority: Major
> Attachments: Screen Shot 2020-10-12 at 9.57.36 AM.png
>
>
> When upgrading jboss-ejb-client to version 4.0.35.Final, we noticed some WildFly CI jobs sometimes hang when running {{TwoConnectorsEJBFailoverTestCase}}, causing 100+ (e.g., 466) tests to fail:
> {code}
> RemoteElytronSingleSignOnTestCase.testSessionTimeoutDestroysSSOorg.jboss.as.test.clustering.cluster.sso.remote
> RemoteElytronSingleSignOnTestCase.testFormAuthSingleSignOnorg.jboss.as.test.clustering.cluster.sso.remote
> RemoteElytronSingleSignOnTestCase.testNoAuthSingleSignOnorg.jboss.as.test.clustering.cluster.sso.remote
> RemoteSingleSignOnTestCase.testSessionTimeoutDestroysSSOorg.jboss.as.test.clustering.cluster.sso.remote
> RemoteSingleSignOnTestCase.testFormAuthSingleSignOnorg.jboss.as.test.clustering.cluster.sso.remote
> RemoteSingleSignOnTestCase.testNoAuthSingleSignOnorg.jboss.as.test.clustering.cluster.sso.remote
> CoarseHotRodPersistenceWebFailoverTestCase.testGracefulUndeployFailoverorg.jboss.as.test.clustering.cluster.web.remote
> CoarseHotRodPersistenceWebFailoverTestCase.testNonPrimaryOwnerorg.jboss.as.test.clustering.cluster.web.remote
> CoarseHotRodPersistenceWebFailoverTestCase.testGracefulSimpleFailoverorg.jboss.as.test.clustering.cluster.web.remote
> CoarseHotRodSessionActivationTestCase.testorg.jboss.as.test.clustering.cluster.web.remote
> CoarseHotRodWebFailoverTestCase.testGracefulUndeployFailoverorg.jboss.as.test.clustering.cluster.web.remote
> CoarseHotRodWebFailoverTestCase.testNonPrimaryOwnerorg.jboss.as.test.clustering.cluster.web.remote
> CoarseHotRodWebFailoverTestCase.testGracefulSimpleFailoverorg.jboss.as.test.clustering.cluster.web.remote
> CoarseTransactionalHotRodWebFailoverTestCase.testGracefulUndeployFailoverorg.jboss.as.test.clustering.cluster.web.remote
> CoarseTransactionalHotRodWebFailoverTestCase.testNonPrimaryOwnerorg.jboss.as.test.clustering.cluster.web.remote
> CoarseTransactionalHotRodWebFailoverTestCase.testGracefulSimpleFailoverorg.jboss.as.test.clustering.cluster.web.remote
> FineHotRodPersistenceWebFailoverTestCase.testGracefulUndeployFailoverorg.jboss.as.test.clustering.cluster.web.remote
> {code}
> The error messages are like:
> {code}
> org.jboss.arquillian.container.spi.client.container.LifecycleException: The port 9990 is already in use. It means that either the server might be already running or there is another process using port 9990.
> Managed containers do not support connecting to running server instances due to the possible harmful effect of connecting to the wrong server.
> Please stop server (or another process) before running, change to another type of container (e.g. remote) or use jboss.socket.binding.port-offset variable to change the default port.
> To disable this check and allow Arquillian to connect to a running server, set allowConnectingToRunningServer to true in the container configuration
> {code}
> In a [successful CI job|https://ci.wildfly.org/buildConfiguration/WFPR/226438?], {{TwoConnectorsEJBFailoverTestCase}} runs 2 tests: {{testEJBClientUsingLegacyRemotingProtocol}} and {{testEJBClientUsingHttpUpgradeProtocol}}, each taking ~25 seconds to complete. See attached screenshot.
> But in a [failed CI job|https://ci.wildfly.org/buildConfiguration/WF_PullRequest_LinuxJdk11/2...], filtering by {{TwoConnectorsEJBFailoverTestCase}} gives no result, which means the test hangs at {{testEJBClientUsingLegacyRemotingProtocol}}.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
- 1
- 0
[Red Hat JIRA] (WFLY-13956) TwoConnectorsEJBFailoverTestCase sometimes hangs when running with jboss-ejb-client 4.0.35
by Cheng Fang (Jira)
[ https://issues.redhat.com/browse/WFLY-13956?page=com.atlassian.jira.plugi... ]
Cheng Fang updated WFLY-13956:
------------------------------
Description:
When upgrading jboss-ejb-client to version 4.0.35.Final, we noticed some WildFly CI jobs sometimes hang when running {{TwoConnectorsEJBFailoverTestCase}}, causing 100+ (e.g., 466) tests to fail:
{code}
RemoteElytronSingleSignOnTestCase.testSessionTimeoutDestroysSSOorg.jboss.as.test.clustering.cluster.sso.remote
RemoteElytronSingleSignOnTestCase.testFormAuthSingleSignOnorg.jboss.as.test.clustering.cluster.sso.remote
RemoteElytronSingleSignOnTestCase.testNoAuthSingleSignOnorg.jboss.as.test.clustering.cluster.sso.remote
RemoteSingleSignOnTestCase.testSessionTimeoutDestroysSSOorg.jboss.as.test.clustering.cluster.sso.remote
RemoteSingleSignOnTestCase.testFormAuthSingleSignOnorg.jboss.as.test.clustering.cluster.sso.remote
RemoteSingleSignOnTestCase.testNoAuthSingleSignOnorg.jboss.as.test.clustering.cluster.sso.remote
CoarseHotRodPersistenceWebFailoverTestCase.testGracefulUndeployFailoverorg.jboss.as.test.clustering.cluster.web.remote
CoarseHotRodPersistenceWebFailoverTestCase.testNonPrimaryOwnerorg.jboss.as.test.clustering.cluster.web.remote
CoarseHotRodPersistenceWebFailoverTestCase.testGracefulSimpleFailoverorg.jboss.as.test.clustering.cluster.web.remote
CoarseHotRodSessionActivationTestCase.testorg.jboss.as.test.clustering.cluster.web.remote
CoarseHotRodWebFailoverTestCase.testGracefulUndeployFailoverorg.jboss.as.test.clustering.cluster.web.remote
CoarseHotRodWebFailoverTestCase.testNonPrimaryOwnerorg.jboss.as.test.clustering.cluster.web.remote
CoarseHotRodWebFailoverTestCase.testGracefulSimpleFailoverorg.jboss.as.test.clustering.cluster.web.remote
CoarseTransactionalHotRodWebFailoverTestCase.testGracefulUndeployFailoverorg.jboss.as.test.clustering.cluster.web.remote
CoarseTransactionalHotRodWebFailoverTestCase.testNonPrimaryOwnerorg.jboss.as.test.clustering.cluster.web.remote
CoarseTransactionalHotRodWebFailoverTestCase.testGracefulSimpleFailoverorg.jboss.as.test.clustering.cluster.web.remote
FineHotRodPersistenceWebFailoverTestCase.testGracefulUndeployFailoverorg.jboss.as.test.clustering.cluster.web.remote
{code}
In a [successful CI job|https://ci.wildfly.org/buildConfiguration/WFPR/226438?], {{TwoConnectorsEJBFailoverTestCase}} runs 2 tests: {{testEJBClientUsingLegacyRemotingProtocol}} and {{testEJBClientUsingHttpUpgradeProtocol}}, each taking ~25 seconds to complete. See attached screenshot. But in a [failed CI job|https://ci.wildfly.org/buildConfiguration/WF_PullRequest_LinuxJdk11/2...], filtering by {{TwoConnectorsEJBFailoverTestCase}} gives no result, which means the test hangs at {{testEJBClientUsingLegacyRemotingProtocol}}.
The error messages are like:
{code}
org.jboss.arquillian.container.spi.client.container.LifecycleException: The port 9990 is already in use. It means that either the server might be already running or there is another process using port 9990.
Managed containers do not support connecting to running server instances due to the possible harmful effect of connecting to the wrong server.
Please stop server (or another process) before running, change to another type of container (e.g. remote) or use jboss.socket.binding.port-offset variable to change the default port.
To disable this check and allow Arquillian to connect to a running server, set allowConnectingToRunningServer to true in the container configuration
{code}
was:
When upgrading jboss-ejb-client to version 4.0.35.Final, we noticed some WildFly CI jobs sometimes hang when running {{TwoConnectorsEJBFailoverTestCase}}, causing 100+ (e.g., 466) tests to fail:
{code}
RemoteElytronSingleSignOnTestCase.testSessionTimeoutDestroysSSOorg.jboss.as.test.clustering.cluster.sso.remote
RemoteElytronSingleSignOnTestCase.testFormAuthSingleSignOnorg.jboss.as.test.clustering.cluster.sso.remote
RemoteElytronSingleSignOnTestCase.testNoAuthSingleSignOnorg.jboss.as.test.clustering.cluster.sso.remote
RemoteSingleSignOnTestCase.testSessionTimeoutDestroysSSOorg.jboss.as.test.clustering.cluster.sso.remote
RemoteSingleSignOnTestCase.testFormAuthSingleSignOnorg.jboss.as.test.clustering.cluster.sso.remote
RemoteSingleSignOnTestCase.testNoAuthSingleSignOnorg.jboss.as.test.clustering.cluster.sso.remote
CoarseHotRodPersistenceWebFailoverTestCase.testGracefulUndeployFailoverorg.jboss.as.test.clustering.cluster.web.remote
CoarseHotRodPersistenceWebFailoverTestCase.testNonPrimaryOwnerorg.jboss.as.test.clustering.cluster.web.remote
CoarseHotRodPersistenceWebFailoverTestCase.testGracefulSimpleFailoverorg.jboss.as.test.clustering.cluster.web.remote
CoarseHotRodSessionActivationTestCase.testorg.jboss.as.test.clustering.cluster.web.remote
CoarseHotRodWebFailoverTestCase.testGracefulUndeployFailoverorg.jboss.as.test.clustering.cluster.web.remote
CoarseHotRodWebFailoverTestCase.testNonPrimaryOwnerorg.jboss.as.test.clustering.cluster.web.remote
CoarseHotRodWebFailoverTestCase.testGracefulSimpleFailoverorg.jboss.as.test.clustering.cluster.web.remote
CoarseTransactionalHotRodWebFailoverTestCase.testGracefulUndeployFailoverorg.jboss.as.test.clustering.cluster.web.remote
CoarseTransactionalHotRodWebFailoverTestCase.testNonPrimaryOwnerorg.jboss.as.test.clustering.cluster.web.remote
CoarseTransactionalHotRodWebFailoverTestCase.testGracefulSimpleFailoverorg.jboss.as.test.clustering.cluster.web.remote
FineHotRodPersistenceWebFailoverTestCase.testGracefulUndeployFailoverorg.jboss.as.test.clustering.cluster.web.remote
{code}
The error messages are like:
{code}
org.jboss.arquillian.container.spi.client.container.LifecycleException: The port 9990 is already in use. It means that either the server might be already running or there is another process using port 9990.
Managed containers do not support connecting to running server instances due to the possible harmful effect of connecting to the wrong server.
Please stop server (or another process) before running, change to another type of container (e.g. remote) or use jboss.socket.binding.port-offset variable to change the default port.
To disable this check and allow Arquillian to connect to a running server, set allowConnectingToRunningServer to true in the container configuration
{code}
> TwoConnectorsEJBFailoverTestCase sometimes hangs when running with jboss-ejb-client 4.0.35
> ------------------------------------------------------------------------------------------
>
> Key: WFLY-13956
> URL: https://issues.redhat.com/browse/WFLY-13956
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 21.0.0.Beta1
> Reporter: Cheng Fang
> Assignee: Cheng Fang
> Priority: Major
> Attachments: Screen Shot 2020-10-12 at 9.57.36 AM.png
>
>
> When upgrading jboss-ejb-client to version 4.0.35.Final, we noticed some WildFly CI jobs sometimes hang when running {{TwoConnectorsEJBFailoverTestCase}}, causing 100+ (e.g., 466) tests to fail:
> {code}
> RemoteElytronSingleSignOnTestCase.testSessionTimeoutDestroysSSOorg.jboss.as.test.clustering.cluster.sso.remote
> RemoteElytronSingleSignOnTestCase.testFormAuthSingleSignOnorg.jboss.as.test.clustering.cluster.sso.remote
> RemoteElytronSingleSignOnTestCase.testNoAuthSingleSignOnorg.jboss.as.test.clustering.cluster.sso.remote
> RemoteSingleSignOnTestCase.testSessionTimeoutDestroysSSOorg.jboss.as.test.clustering.cluster.sso.remote
> RemoteSingleSignOnTestCase.testFormAuthSingleSignOnorg.jboss.as.test.clustering.cluster.sso.remote
> RemoteSingleSignOnTestCase.testNoAuthSingleSignOnorg.jboss.as.test.clustering.cluster.sso.remote
> CoarseHotRodPersistenceWebFailoverTestCase.testGracefulUndeployFailoverorg.jboss.as.test.clustering.cluster.web.remote
> CoarseHotRodPersistenceWebFailoverTestCase.testNonPrimaryOwnerorg.jboss.as.test.clustering.cluster.web.remote
> CoarseHotRodPersistenceWebFailoverTestCase.testGracefulSimpleFailoverorg.jboss.as.test.clustering.cluster.web.remote
> CoarseHotRodSessionActivationTestCase.testorg.jboss.as.test.clustering.cluster.web.remote
> CoarseHotRodWebFailoverTestCase.testGracefulUndeployFailoverorg.jboss.as.test.clustering.cluster.web.remote
> CoarseHotRodWebFailoverTestCase.testNonPrimaryOwnerorg.jboss.as.test.clustering.cluster.web.remote
> CoarseHotRodWebFailoverTestCase.testGracefulSimpleFailoverorg.jboss.as.test.clustering.cluster.web.remote
> CoarseTransactionalHotRodWebFailoverTestCase.testGracefulUndeployFailoverorg.jboss.as.test.clustering.cluster.web.remote
> CoarseTransactionalHotRodWebFailoverTestCase.testNonPrimaryOwnerorg.jboss.as.test.clustering.cluster.web.remote
> CoarseTransactionalHotRodWebFailoverTestCase.testGracefulSimpleFailoverorg.jboss.as.test.clustering.cluster.web.remote
> FineHotRodPersistenceWebFailoverTestCase.testGracefulUndeployFailoverorg.jboss.as.test.clustering.cluster.web.remote
> {code}
> In a [successful CI job|https://ci.wildfly.org/buildConfiguration/WFPR/226438?], {{TwoConnectorsEJBFailoverTestCase}} runs 2 tests: {{testEJBClientUsingLegacyRemotingProtocol}} and {{testEJBClientUsingHttpUpgradeProtocol}}, each taking ~25 seconds to complete. See attached screenshot. But in a [failed CI job|https://ci.wildfly.org/buildConfiguration/WF_PullRequest_LinuxJdk11/2...], filtering by {{TwoConnectorsEJBFailoverTestCase}} gives no result, which means the test hangs at {{testEJBClientUsingLegacyRemotingProtocol}}.
> The error messages are like:
> {code}
> org.jboss.arquillian.container.spi.client.container.LifecycleException: The port 9990 is already in use. It means that either the server might be already running or there is another process using port 9990.
> Managed containers do not support connecting to running server instances due to the possible harmful effect of connecting to the wrong server.
> Please stop server (or another process) before running, change to another type of container (e.g. remote) or use jboss.socket.binding.port-offset variable to change the default port.
> To disable this check and allow Arquillian to connect to a running server, set allowConnectingToRunningServer to true in the container configuration
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
- 1
- 0
[Red Hat JIRA] (WFLY-13956) TwoConnectorsEJBFailoverTestCase sometimes hangs when running with jboss-ejb-client 4.0.35
by Cheng Fang (Jira)
[ https://issues.redhat.com/browse/WFLY-13956?page=com.atlassian.jira.plugi... ]
Cheng Fang updated WFLY-13956:
------------------------------
Attachment: Screen Shot 2020-10-12 at 9.57.36 AM.png
> TwoConnectorsEJBFailoverTestCase sometimes hangs when running with jboss-ejb-client 4.0.35
> ------------------------------------------------------------------------------------------
>
> Key: WFLY-13956
> URL: https://issues.redhat.com/browse/WFLY-13956
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 21.0.0.Beta1
> Reporter: Cheng Fang
> Assignee: Cheng Fang
> Priority: Major
> Attachments: Screen Shot 2020-10-12 at 9.57.36 AM.png
>
>
> When upgrading jboss-ejb-client to version 4.0.35.Final, we noticed some WildFly CI jobs sometimes hang when running {{TwoConnectorsEJBFailoverTestCase}}, causing 100+ (e.g., 466) tests to fail:
> {code}
> RemoteElytronSingleSignOnTestCase.testSessionTimeoutDestroysSSOorg.jboss.as.test.clustering.cluster.sso.remote
> RemoteElytronSingleSignOnTestCase.testFormAuthSingleSignOnorg.jboss.as.test.clustering.cluster.sso.remote
> RemoteElytronSingleSignOnTestCase.testNoAuthSingleSignOnorg.jboss.as.test.clustering.cluster.sso.remote
> RemoteSingleSignOnTestCase.testSessionTimeoutDestroysSSOorg.jboss.as.test.clustering.cluster.sso.remote
> RemoteSingleSignOnTestCase.testFormAuthSingleSignOnorg.jboss.as.test.clustering.cluster.sso.remote
> RemoteSingleSignOnTestCase.testNoAuthSingleSignOnorg.jboss.as.test.clustering.cluster.sso.remote
> CoarseHotRodPersistenceWebFailoverTestCase.testGracefulUndeployFailoverorg.jboss.as.test.clustering.cluster.web.remote
> CoarseHotRodPersistenceWebFailoverTestCase.testNonPrimaryOwnerorg.jboss.as.test.clustering.cluster.web.remote
> CoarseHotRodPersistenceWebFailoverTestCase.testGracefulSimpleFailoverorg.jboss.as.test.clustering.cluster.web.remote
> CoarseHotRodSessionActivationTestCase.testorg.jboss.as.test.clustering.cluster.web.remote
> CoarseHotRodWebFailoverTestCase.testGracefulUndeployFailoverorg.jboss.as.test.clustering.cluster.web.remote
> CoarseHotRodWebFailoverTestCase.testNonPrimaryOwnerorg.jboss.as.test.clustering.cluster.web.remote
> CoarseHotRodWebFailoverTestCase.testGracefulSimpleFailoverorg.jboss.as.test.clustering.cluster.web.remote
> CoarseTransactionalHotRodWebFailoverTestCase.testGracefulUndeployFailoverorg.jboss.as.test.clustering.cluster.web.remote
> CoarseTransactionalHotRodWebFailoverTestCase.testNonPrimaryOwnerorg.jboss.as.test.clustering.cluster.web.remote
> CoarseTransactionalHotRodWebFailoverTestCase.testGracefulSimpleFailoverorg.jboss.as.test.clustering.cluster.web.remote
> FineHotRodPersistenceWebFailoverTestCase.testGracefulUndeployFailoverorg.jboss.as.test.clustering.cluster.web.remote
> {code}
> The error messages are like:
> {code}
> org.jboss.arquillian.container.spi.client.container.LifecycleException: The port 9990 is already in use. It means that either the server might be already running or there is another process using port 9990.
> Managed containers do not support connecting to running server instances due to the possible harmful effect of connecting to the wrong server.
> Please stop server (or another process) before running, change to another type of container (e.g. remote) or use jboss.socket.binding.port-offset variable to change the default port.
> To disable this check and allow Arquillian to connect to a running server, set allowConnectingToRunningServer to true in the container configuration
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
- 1
- 0
[Red Hat JIRA] (WFLY-13956) TwoConnectorsEJBFailoverTestCase sometimes hangs when running with jboss-ejb-client 4.0.35
by Cheng Fang (Jira)
[ https://issues.redhat.com/browse/WFLY-13956?page=com.atlassian.jira.plugi... ]
Cheng Fang updated WFLY-13956:
------------------------------
Description:
When upgrading jboss-ejb-client to version 4.0.35.Final, we noticed some WildFly CI jobs sometimes hang when running {{TwoConnectorsEJBFailoverTestCase}}, causing 100+ (e.g., 466) tests to fail:
{code}
RemoteElytronSingleSignOnTestCase.testSessionTimeoutDestroysSSOorg.jboss.as.test.clustering.cluster.sso.remote
RemoteElytronSingleSignOnTestCase.testFormAuthSingleSignOnorg.jboss.as.test.clustering.cluster.sso.remote
RemoteElytronSingleSignOnTestCase.testNoAuthSingleSignOnorg.jboss.as.test.clustering.cluster.sso.remote
RemoteSingleSignOnTestCase.testSessionTimeoutDestroysSSOorg.jboss.as.test.clustering.cluster.sso.remote
RemoteSingleSignOnTestCase.testFormAuthSingleSignOnorg.jboss.as.test.clustering.cluster.sso.remote
RemoteSingleSignOnTestCase.testNoAuthSingleSignOnorg.jboss.as.test.clustering.cluster.sso.remote
CoarseHotRodPersistenceWebFailoverTestCase.testGracefulUndeployFailoverorg.jboss.as.test.clustering.cluster.web.remote
CoarseHotRodPersistenceWebFailoverTestCase.testNonPrimaryOwnerorg.jboss.as.test.clustering.cluster.web.remote
CoarseHotRodPersistenceWebFailoverTestCase.testGracefulSimpleFailoverorg.jboss.as.test.clustering.cluster.web.remote
CoarseHotRodSessionActivationTestCase.testorg.jboss.as.test.clustering.cluster.web.remote
CoarseHotRodWebFailoverTestCase.testGracefulUndeployFailoverorg.jboss.as.test.clustering.cluster.web.remote
CoarseHotRodWebFailoverTestCase.testNonPrimaryOwnerorg.jboss.as.test.clustering.cluster.web.remote
CoarseHotRodWebFailoverTestCase.testGracefulSimpleFailoverorg.jboss.as.test.clustering.cluster.web.remote
CoarseTransactionalHotRodWebFailoverTestCase.testGracefulUndeployFailoverorg.jboss.as.test.clustering.cluster.web.remote
CoarseTransactionalHotRodWebFailoverTestCase.testNonPrimaryOwnerorg.jboss.as.test.clustering.cluster.web.remote
CoarseTransactionalHotRodWebFailoverTestCase.testGracefulSimpleFailoverorg.jboss.as.test.clustering.cluster.web.remote
FineHotRodPersistenceWebFailoverTestCase.testGracefulUndeployFailoverorg.jboss.as.test.clustering.cluster.web.remote
{code}
The error messages are like:
{code}
org.jboss.arquillian.container.spi.client.container.LifecycleException: The port 9990 is already in use. It means that either the server might be already running or there is another process using port 9990.
Managed containers do not support connecting to running server instances due to the possible harmful effect of connecting to the wrong server.
Please stop server (or another process) before running, change to another type of container (e.g. remote) or use jboss.socket.binding.port-offset variable to change the default port.
To disable this check and allow Arquillian to connect to a running server, set allowConnectingToRunningServer to true in the container configuration
{code}
was:
When upgrading jboss-ejb-client to version 4.0.35.Final, we noticed some WildFly CI jobs sometimes hang when running {{TwoConnectorsEJBFailoverTestCase}}, causing 100+ (e.g., 466) tests to fail:
{code}
RemoteElytronSingleSignOnTestCase.testSessionTimeoutDestroysSSOorg.jboss.as.test.clustering.cluster.sso.remote
RemoteElytronSingleSignOnTestCase.testFormAuthSingleSignOnorg.jboss.as.test.clustering.cluster.sso.remote
RemoteElytronSingleSignOnTestCase.testNoAuthSingleSignOnorg.jboss.as.test.clustering.cluster.sso.remote
RemoteSingleSignOnTestCase.testSessionTimeoutDestroysSSOorg.jboss.as.test.clustering.cluster.sso.remote
RemoteSingleSignOnTestCase.testFormAuthSingleSignOnorg.jboss.as.test.clustering.cluster.sso.remote
RemoteSingleSignOnTestCase.testNoAuthSingleSignOnorg.jboss.as.test.clustering.cluster.sso.remote
CoarseHotRodPersistenceWebFailoverTestCase.testGracefulUndeployFailoverorg.jboss.as.test.clustering.cluster.web.remote
CoarseHotRodPersistenceWebFailoverTestCase.testNonPrimaryOwnerorg.jboss.as.test.clustering.cluster.web.remote
CoarseHotRodPersistenceWebFailoverTestCase.testGracefulSimpleFailoverorg.jboss.as.test.clustering.cluster.web.remote
CoarseHotRodSessionActivationTestCase.testorg.jboss.as.test.clustering.cluster.web.remote
CoarseHotRodWebFailoverTestCase.testGracefulUndeployFailoverorg.jboss.as.test.clustering.cluster.web.remote
CoarseHotRodWebFailoverTestCase.testNonPrimaryOwnerorg.jboss.as.test.clustering.cluster.web.remote
CoarseHotRodWebFailoverTestCase.testGracefulSimpleFailoverorg.jboss.as.test.clustering.cluster.web.remote
CoarseTransactionalHotRodWebFailoverTestCase.testGracefulUndeployFailoverorg.jboss.as.test.clustering.cluster.web.remote
CoarseTransactionalHotRodWebFailoverTestCase.testNonPrimaryOwnerorg.jboss.as.test.clustering.cluster.web.remote
CoarseTransactionalHotRodWebFailoverTestCase.testGracefulSimpleFailoverorg.jboss.as.test.clustering.cluster.web.remote
FineHotRodPersistenceWebFailoverTestCase.testGracefulUndeployFailoverorg.jboss.as.test.clustering.cluster.web.remote
{code}
> TwoConnectorsEJBFailoverTestCase sometimes hangs when running with jboss-ejb-client 4.0.35
> ------------------------------------------------------------------------------------------
>
> Key: WFLY-13956
> URL: https://issues.redhat.com/browse/WFLY-13956
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 21.0.0.Beta1
> Reporter: Cheng Fang
> Assignee: Cheng Fang
> Priority: Major
> Attachments: Screen Shot 2020-10-12 at 9.57.36 AM.png
>
>
> When upgrading jboss-ejb-client to version 4.0.35.Final, we noticed some WildFly CI jobs sometimes hang when running {{TwoConnectorsEJBFailoverTestCase}}, causing 100+ (e.g., 466) tests to fail:
> {code}
> RemoteElytronSingleSignOnTestCase.testSessionTimeoutDestroysSSOorg.jboss.as.test.clustering.cluster.sso.remote
> RemoteElytronSingleSignOnTestCase.testFormAuthSingleSignOnorg.jboss.as.test.clustering.cluster.sso.remote
> RemoteElytronSingleSignOnTestCase.testNoAuthSingleSignOnorg.jboss.as.test.clustering.cluster.sso.remote
> RemoteSingleSignOnTestCase.testSessionTimeoutDestroysSSOorg.jboss.as.test.clustering.cluster.sso.remote
> RemoteSingleSignOnTestCase.testFormAuthSingleSignOnorg.jboss.as.test.clustering.cluster.sso.remote
> RemoteSingleSignOnTestCase.testNoAuthSingleSignOnorg.jboss.as.test.clustering.cluster.sso.remote
> CoarseHotRodPersistenceWebFailoverTestCase.testGracefulUndeployFailoverorg.jboss.as.test.clustering.cluster.web.remote
> CoarseHotRodPersistenceWebFailoverTestCase.testNonPrimaryOwnerorg.jboss.as.test.clustering.cluster.web.remote
> CoarseHotRodPersistenceWebFailoverTestCase.testGracefulSimpleFailoverorg.jboss.as.test.clustering.cluster.web.remote
> CoarseHotRodSessionActivationTestCase.testorg.jboss.as.test.clustering.cluster.web.remote
> CoarseHotRodWebFailoverTestCase.testGracefulUndeployFailoverorg.jboss.as.test.clustering.cluster.web.remote
> CoarseHotRodWebFailoverTestCase.testNonPrimaryOwnerorg.jboss.as.test.clustering.cluster.web.remote
> CoarseHotRodWebFailoverTestCase.testGracefulSimpleFailoverorg.jboss.as.test.clustering.cluster.web.remote
> CoarseTransactionalHotRodWebFailoverTestCase.testGracefulUndeployFailoverorg.jboss.as.test.clustering.cluster.web.remote
> CoarseTransactionalHotRodWebFailoverTestCase.testNonPrimaryOwnerorg.jboss.as.test.clustering.cluster.web.remote
> CoarseTransactionalHotRodWebFailoverTestCase.testGracefulSimpleFailoverorg.jboss.as.test.clustering.cluster.web.remote
> FineHotRodPersistenceWebFailoverTestCase.testGracefulUndeployFailoverorg.jboss.as.test.clustering.cluster.web.remote
> {code}
> The error messages are like:
> {code}
> org.jboss.arquillian.container.spi.client.container.LifecycleException: The port 9990 is already in use. It means that either the server might be already running or there is another process using port 9990.
> Managed containers do not support connecting to running server instances due to the possible harmful effect of connecting to the wrong server.
> Please stop server (or another process) before running, change to another type of container (e.g. remote) or use jboss.socket.binding.port-offset variable to change the default port.
> To disable this check and allow Arquillian to connect to a running server, set allowConnectingToRunningServer to true in the container configuration
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
- 1
- 0
[Red Hat JIRA] (DROOLS-5718) Avoid regenerating ANC source files just to get the indexableConstraint
by Luca Molteni (Jira)
Luca Molteni created DROOLS-5718:
------------------------------------
Summary: Avoid regenerating ANC source files just to get the indexableConstraint
Key: DROOLS-5718
URL: https://issues.redhat.com/browse/DROOLS-5718
Project: Drools
Issue Type: Enhancement
Reporter: Luca Molteni
Assignee: Luca Molteni
Currently, when reading a compiled alpha network instance from the classloader of a kjar created using the maven plugin, we still need to regenerate the source code to get the
FieldExtractor/IndexableConstraint, as it's parsed during the source code generation but not persisted in the kjar compilation
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
- 1
- 0
[Red Hat JIRA] (WFLY-13956) TwoConnectorsEJBFailoverTestCase sometimes hangs when running with jboss-ejb-client 4.0.35
by Cheng Fang (Jira)
[ https://issues.redhat.com/browse/WFLY-13956?page=com.atlassian.jira.plugi... ]
Cheng Fang updated WFLY-13956:
------------------------------
Description:
When upgrading jboss-ejb-client to version 4.0.35.Final, we noticed some WildFly CI jobs sometimes hang when running {{TwoConnectorsEJBFailoverTestCase}}, causing 100+ (e.g., 466) tests to fail:
{code}
RemoteElytronSingleSignOnTestCase.testSessionTimeoutDestroysSSOorg.jboss.as.test.clustering.cluster.sso.remote
RemoteElytronSingleSignOnTestCase.testFormAuthSingleSignOnorg.jboss.as.test.clustering.cluster.sso.remote
RemoteElytronSingleSignOnTestCase.testNoAuthSingleSignOnorg.jboss.as.test.clustering.cluster.sso.remote
RemoteSingleSignOnTestCase.testSessionTimeoutDestroysSSOorg.jboss.as.test.clustering.cluster.sso.remote
RemoteSingleSignOnTestCase.testFormAuthSingleSignOnorg.jboss.as.test.clustering.cluster.sso.remote
RemoteSingleSignOnTestCase.testNoAuthSingleSignOnorg.jboss.as.test.clustering.cluster.sso.remote
CoarseHotRodPersistenceWebFailoverTestCase.testGracefulUndeployFailoverorg.jboss.as.test.clustering.cluster.web.remote
CoarseHotRodPersistenceWebFailoverTestCase.testNonPrimaryOwnerorg.jboss.as.test.clustering.cluster.web.remote
CoarseHotRodPersistenceWebFailoverTestCase.testGracefulSimpleFailoverorg.jboss.as.test.clustering.cluster.web.remote
CoarseHotRodSessionActivationTestCase.testorg.jboss.as.test.clustering.cluster.web.remote
CoarseHotRodWebFailoverTestCase.testGracefulUndeployFailoverorg.jboss.as.test.clustering.cluster.web.remote
CoarseHotRodWebFailoverTestCase.testNonPrimaryOwnerorg.jboss.as.test.clustering.cluster.web.remote
CoarseHotRodWebFailoverTestCase.testGracefulSimpleFailoverorg.jboss.as.test.clustering.cluster.web.remote
CoarseTransactionalHotRodWebFailoverTestCase.testGracefulUndeployFailoverorg.jboss.as.test.clustering.cluster.web.remote
CoarseTransactionalHotRodWebFailoverTestCase.testNonPrimaryOwnerorg.jboss.as.test.clustering.cluster.web.remote
CoarseTransactionalHotRodWebFailoverTestCase.testGracefulSimpleFailoverorg.jboss.as.test.clustering.cluster.web.remote
FineHotRodPersistenceWebFailoverTestCase.testGracefulUndeployFailoverorg.jboss.as.test.clustering.cluster.web.remote
{code}
was:
When upgrading jboss-ejb-client to version 4.0.35.Final, we noticed some WildFly CI jobs sometimes hang when running {{TwoConnectorsEJBFailoverTestCase}}, causing 100+ (e.g., 466) tests to fail:
{{RemoteElytronSingleSignOnTestCase.testSessionTimeoutDestroysSSOorg.jboss.as.test.clustering.cluster.sso.remote}}
{{RemoteElytronSingleSignOnTestCase.testFormAuthSingleSignOnorg.jboss.as.test.clustering.cluster.sso.remote}}
{{RemoteElytronSingleSignOnTestCase.testNoAuthSingleSignOnorg.jboss.as.test.clustering.cluster.sso.remote}}
{{RemoteSingleSignOnTestCase.testSessionTimeoutDestroysSSOorg.jboss.as.test.clustering.cluster.sso.remote}}
{{RemoteSingleSignOnTestCase.testFormAuthSingleSignOnorg.jboss.as.test.clustering.cluster.sso.remote}}
{{RemoteSingleSignOnTestCase.testNoAuthSingleSignOnorg.jboss.as.test.clustering.cluster.sso.remote}}
{{CoarseHotRodPersistenceWebFailoverTestCase.testGracefulUndeployFailoverorg.jboss.as.test.clustering.cluster.web.remote}}
{{CoarseHotRodPersistenceWebFailoverTestCase.testNonPrimaryOwnerorg.jboss.as.test.clustering.cluster.web.remote}}
{{CoarseHotRodPersistenceWebFailoverTestCase.testGracefulSimpleFailoverorg.jboss.as.test.clustering.cluster.web.remote}}
{{CoarseHotRodSessionActivationTestCase.testorg.jboss.as.test.clustering.cluster.web.remote}}
{{CoarseHotRodWebFailoverTestCase.testGracefulUndeployFailoverorg.jboss.as.test.clustering.cluster.web.remote}}
{{CoarseHotRodWebFailoverTestCase.testNonPrimaryOwnerorg.jboss.as.test.clustering.cluster.web.remote}}
{{CoarseHotRodWebFailoverTestCase.testGracefulSimpleFailoverorg.jboss.as.test.clustering.cluster.web.remote}}
{{CoarseTransactionalHotRodWebFailoverTestCase.testGracefulUndeployFailoverorg.jboss.as.test.clustering.cluster.web.remote}}
{{CoarseTransactionalHotRodWebFailoverTestCase.testNonPrimaryOwnerorg.jboss.as.test.clustering.cluster.web.remote}}
{{CoarseTransactionalHotRodWebFailoverTestCase.testGracefulSimpleFailoverorg.jboss.as.test.clustering.cluster.web.remote}}
{{FineHotRodPersistenceWebFailoverTestCase.testGracefulUndeployFailoverorg.jboss.as.test.clustering.cluster.web.remote}}
> TwoConnectorsEJBFailoverTestCase sometimes hangs when running with jboss-ejb-client 4.0.35
> ------------------------------------------------------------------------------------------
>
> Key: WFLY-13956
> URL: https://issues.redhat.com/browse/WFLY-13956
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 21.0.0.Beta1
> Reporter: Cheng Fang
> Assignee: Cheng Fang
> Priority: Major
>
> When upgrading jboss-ejb-client to version 4.0.35.Final, we noticed some WildFly CI jobs sometimes hang when running {{TwoConnectorsEJBFailoverTestCase}}, causing 100+ (e.g., 466) tests to fail:
> {code}
> RemoteElytronSingleSignOnTestCase.testSessionTimeoutDestroysSSOorg.jboss.as.test.clustering.cluster.sso.remote
> RemoteElytronSingleSignOnTestCase.testFormAuthSingleSignOnorg.jboss.as.test.clustering.cluster.sso.remote
> RemoteElytronSingleSignOnTestCase.testNoAuthSingleSignOnorg.jboss.as.test.clustering.cluster.sso.remote
> RemoteSingleSignOnTestCase.testSessionTimeoutDestroysSSOorg.jboss.as.test.clustering.cluster.sso.remote
> RemoteSingleSignOnTestCase.testFormAuthSingleSignOnorg.jboss.as.test.clustering.cluster.sso.remote
> RemoteSingleSignOnTestCase.testNoAuthSingleSignOnorg.jboss.as.test.clustering.cluster.sso.remote
> CoarseHotRodPersistenceWebFailoverTestCase.testGracefulUndeployFailoverorg.jboss.as.test.clustering.cluster.web.remote
> CoarseHotRodPersistenceWebFailoverTestCase.testNonPrimaryOwnerorg.jboss.as.test.clustering.cluster.web.remote
> CoarseHotRodPersistenceWebFailoverTestCase.testGracefulSimpleFailoverorg.jboss.as.test.clustering.cluster.web.remote
> CoarseHotRodSessionActivationTestCase.testorg.jboss.as.test.clustering.cluster.web.remote
> CoarseHotRodWebFailoverTestCase.testGracefulUndeployFailoverorg.jboss.as.test.clustering.cluster.web.remote
> CoarseHotRodWebFailoverTestCase.testNonPrimaryOwnerorg.jboss.as.test.clustering.cluster.web.remote
> CoarseHotRodWebFailoverTestCase.testGracefulSimpleFailoverorg.jboss.as.test.clustering.cluster.web.remote
> CoarseTransactionalHotRodWebFailoverTestCase.testGracefulUndeployFailoverorg.jboss.as.test.clustering.cluster.web.remote
> CoarseTransactionalHotRodWebFailoverTestCase.testNonPrimaryOwnerorg.jboss.as.test.clustering.cluster.web.remote
> CoarseTransactionalHotRodWebFailoverTestCase.testGracefulSimpleFailoverorg.jboss.as.test.clustering.cluster.web.remote
> FineHotRodPersistenceWebFailoverTestCase.testGracefulUndeployFailoverorg.jboss.as.test.clustering.cluster.web.remote
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
- 1
- 0