[JBoss JIRA] (WFCORE-1146) Research behavior of fork with ProcessBuilder on modern JVMs
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1146?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1146:
-------------------------------------
Component/s: Domain Management
> Research behavior of fork with ProcessBuilder on modern JVMs
> ------------------------------------------------------------
>
> Key: WFCORE-1146
> URL: https://issues.jboss.org/browse/WFCORE-1146
> Project: WildFly Core
> Issue Type: Task
> Components: Domain Management
> Reporter: David Lloyd
>
> Right now our Process Controller exists for two primary reasons:
> # fork() misbehaves for large processes on some OSes, causing leaks or crashes
> # if the HC crashes, the PC can respawn it
> We have never (afaik) seen #2 happen. We need to verify whether #1 is still true on modern JVMs on the following operating systems:
> * Linux
> * Solaris
> * IBM OSes
> * Windows
> * BSDs
> * Mac OS X
> Test by creating processes with large heap and lots of concurrent file descriptor activity while forking to see what happens.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 7 months
[JBoss JIRA] (WFLY-5750) Hibernate 5 hibernate-java8 jar is missing
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-5750?page=com.atlassian.jira.plugin.... ]
Scott Marlow closed WFLY-5750.
------------------------------
Resolution: Done
> Hibernate 5 hibernate-java8 jar is missing
> ------------------------------------------
>
> Key: WFLY-5750
> URL: https://issues.jboss.org/browse/WFLY-5750
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 10.0.0.CR4
> Reporter: Juergen Zimmermann
> Assignee: Scott Marlow
> Fix For: 10.0.0.CR5
>
>
> In $JBOSS_HOME/modules/system/layers/base/org/hibernate/main are these JARs:
> * hibernate-core
> * hibernate-entitymanager
> * hibernate-envers
> However, org.hibernate:hibernate-java8 is missing. This JAR enables the use of Instant, LocalDate, LocalDateTime LocalTime, ... being part of the new time API in JDK 8.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 7 months
[JBoss JIRA] (WFLY-5790) Use a separate interface for JGroups sockets
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-5790?page=com.atlassian.jira.plugin.... ]
Brian Stansberry reassigned WFLY-5790:
--------------------------------------
Assignee: Paul Ferraro (was: Brian Stansberry)
[~jason.greene][~pferraro] My experimental PR passed CI and I know you wanted to get this done, Jason, so I created a JIRA and changed my PRs commit message to reflect it.
I'm assigning this over to you, though, Paul, as your team would know better if there are any gotchas here, particularly any testsuite tweaks that are necessary to ensure the test servers are using the expected addresses. My PR has the basic change to the xslt that's used to change the default addresses to IPv6.
> Use a separate interface for JGroups sockets
> --------------------------------------------
>
> Key: WFLY-5790
> URL: https://issues.jboss.org/browse/WFLY-5790
> Project: WildFly
> Issue Type: Enhancement
> Components: Clustering, Domain Management
> Reporter: Brian Stansberry
> Assignee: Paul Ferraro
> Fix For: 10.0.0.Final
>
>
> Our standard configs currently use the "public" interface for the JGroups sockets. However, best practice is to put intra-cluster traffic on a separate network from the network handling end user requests, both for possible performance reasons and to reduce the risk of exposing clustering to unwanted, possibly malevolent, traffic.
> Since that is best practice, our standard configs should reflect that. So we'll create a new 'private' interface to go along with the existing 'public', 'management', and 'unsecure' ones, and use it for the JGroups sockets.
> The default address will be ${jboss.bind.address.private:127.0.0.1} consistent with the others.
> Users using our standard configs who wish to use -b startup switches to control the network address will need to add -bprivate=<theaddress> to the startup command. Simply using -b=<theaddress> will no longer affect the JGroups traffic if our standard configs are used.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 7 months
[JBoss JIRA] (WFLY-5790) Use a separate interface for JGroups sockets
by Brian Stansberry (JIRA)
Brian Stansberry created WFLY-5790:
--------------------------------------
Summary: Use a separate interface for JGroups sockets
Key: WFLY-5790
URL: https://issues.jboss.org/browse/WFLY-5790
Project: WildFly
Issue Type: Enhancement
Components: Clustering, Domain Management
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Fix For: 10.0.0.Final
Our standard configs currently use the "public" interface for the JGroups sockets. However, best practice is to put intra-cluster traffic on a separate network from the network handling end user requests, both for possible performance reasons and to reduce the risk of exposing clustering to unwanted, possibly malevolent, traffic.
Since that is best practice, our standard configs should reflect that. So we'll create a new 'private' interface to go along with the existing 'public', 'management', and 'unsecure' ones, and use it for the JGroups sockets.
The default address will be ${jboss.bind.address.private:127.0.0.1} consistent with the others.
Users using our standard configs who wish to use -b startup switches to control the network address will need to add -bprivate=<theaddress> to the startup command. Simply using -b=<theaddress> will no longer affect the JGroups traffic if our standard configs are used.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 7 months
[JBoss JIRA] (WFLY-847) Strange hangup during stopping of server - must be killed by SIGKILL
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-847?page=com.atlassian.jira.plugin.s... ]
Brian Stansberry resolved WFLY-847.
-----------------------------------
Resolution: Out of Date
Given the discussion on [bug 899797|https://bugzilla.redhat.com/show_bug.cgi?id=899797] it is likely the original reported issue was fixed long ago. Please reopen if you can reproduce this with WildFly 10.
> Strange hangup during stopping of server - must be killed by SIGKILL
> --------------------------------------------------------------------
>
> Key: WFLY-847
> URL: https://issues.jboss.org/browse/WFLY-847
> Project: WildFly
> Issue Type: Bug
> Components: Server
> Reporter: Pavel Janousek
> Priority: Critical
>
> During investigation another JIRA (AS7-3607) I've affected by another issue too.
> Let say - you have machine after successful reboot. You should prepare network environment as described in AS7-3607, the only one difference is you must disable loopback interface too (ip link set dev lo down).
> Now, when you try to start AS7, everything is OK, more precisely is the same as in other issue (AS7-3607).
> BUT - when you hit Ctrl-C now - you try to stop server - it hang-up and report only:
> {code}
> 17:05:23,502 INFO [org.jboss.as] (Controller Boot Thread) JBoss EAP 6.0.0.Alpha2 (AS 7.1.0.CR1-redhat-1) started in 14012ms - Started 158 of 228 services (68 services are passive or on-demand)
> ^C17:05:50,274 INFO [org.jboss.as.messaging] (MSC service thread 1-2) JBAS011605: Unbound messaging object to jndi name java:/queue/test
> 17:05:50,279 INFO [org.jboss.as.osgi] (MSC service thread 1-1) JBAS011921: Stopping OSGi Framework
> 17:05:50,279 INFO [org.jboss.as.messaging] (MSC service thread 1-2) JBAS011605: Unbound messaging object to jndi name java:/RemoteConnectionFactory
> 17:05:50,282 INFO [org.jboss.as.messaging] (MSC service thread 1-2) JBAS011605: Unbound messaging object to jndi name java:/ConnectionFactory
> 17:05:50,341 INFO [org.jboss.as.logging] JBAS011503: Restored bootstrap log handlers
> 17:05:50,350 INFO [jacorb.poa] POA IRPOA destroyed
> 17:05:50,381 INFO [org.hornetq.core.server.impl.HornetQServerImpl] HornetQ Server version 2.2.7.Final (HQ_2_2_7_FINAL_AS7, 121) [3fe9aa6a-4d86-11e1-b2c6-000000000001] stopped
> 17:05:50,411 INFO [jacorb.poa] POA Naming destroyed
> 17:05:50,434 INFO [jacorb.poa] POA RootPOA destroyed
> 17:05:50,440 INFO [com.arjuna.ats.jbossatx] ARJUNA032018: Destroying TransactionManagerService
> 17:05:50,442 INFO [com.arjuna.ats.jbossatx] ARJUNA032014: Stopping transaction recovery manager
> 17:05:50,441 INFO [jacorb.orb] prepare ORB for shutdown...
> 17:05:50,442 INFO [jacorb.orb] ORB going down...
> 17:05:50,446 INFO [jacorb.orb.iiop] Listener exited
> 17:05:50,447 INFO [jacorb.orb] ORB shutdown complete
> 17:05:50,447 INFO [jacorb.orb] ORB run, exit
> ^Z
> [1]+ Stopped ./standalone.sh
> [pjanouse@fedora15-vrt1 bin]$ kill -9 %1
> [1]+ Killed ./standalone.sh
> [pjanouse@fedora15-vrt1 bin]$
> {code}
> As you can see, it can be killed only by SIGKILL signal.
> More strange is when you now enable loopback interface again (ip link set dev lo up), start/stop sequence works fine (as expected).
> And the strangest is when you disable loopback again, it works fine as in previous step - everything works as you can expect. I think it is related to some network issue, but I can't be more precise now, I can't find any other aspect why it is occurred after reboot only.
> I try also several attempts (loopback interface disabled) during let say 10 minutes (due to attempt to eliminate resolver/DNS timeouts etc.), but until I did up/down sequence in lo interface, behavior was the same - only SIGKILL stops it.
> I try it several times, after several reboot my instance inside VirtualBox and behavior is the same - so it isn't accind situation. So I hope it isn't related to only network stack implementation/virtualization inside VirtualBox and is reproducible in another linux box too.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 7 months
[JBoss JIRA] (WFCORE-851) Remoting Subsystem RemoteOutboundConnectionService is caching ConnectionURI causing issues when DNS changes
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-851?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on WFCORE-851:
------------------------------------------------
Brad Maxwell <bmaxwell(a)redhat.com> changed the Status of [bug 1248156|https://bugzilla.redhat.com/show_bug.cgi?id=1248156] from ASSIGNED to POST
> Remoting Subsystem RemoteOutboundConnectionService is caching ConnectionURI causing issues when DNS changes
> -----------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-851
> URL: https://issues.jboss.org/browse/WFCORE-851
> Project: WildFly Core
> Issue Type: Bug
> Components: Remoting
> Reporter: Brad Maxwell
> Assignee: David Lloyd
>
> Description of problem:
> EJB CLient was configured with DNS FQDN to configure access to a remote EJB. If run a simple test adding an entry in /etc/hosts file pointing that FQDN to localhost for tests everything works. However, after finish the tests and remove the entry, the client still connects to localhost instead of resolve the new IP address. Even adding networkaddress.cache.ttl=30 inside security settings didn't work too.
> How reproducible:
> Everytime you use DNS names to connect to a remote EJB.
> Steps to Reproduce:
> 1. Configure a simple client that connects to a remote EJB using dns name
> 2. add an entry in /etc/hosts mapping the dns name to localhost
> 3. run the client code
> 4. remove the entry in /etc/hosts
> 5. run the client code again
> Actual results:
> EJB remote is still reached from localhost
> Expected results:
> After changing DNS record EJB will be reached in this new address
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 7 months
[JBoss JIRA] (WFCORE-1175) CLI prints unexpected ANSI characters to output with "echo" command
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1175?page=com.atlassian.jira.plugi... ]
James Perkins updated WFCORE-1175:
----------------------------------
Fix Version/s: 2.0.5.Final
(was: 2.0.4.Final)
> CLI prints unexpected ANSI characters to output with "echo" command
> -------------------------------------------------------------------
>
> Key: WFCORE-1175
> URL: https://issues.jboss.org/browse/WFCORE-1175
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Affects Versions: 2.0.3.Final
> Reporter: Marek Kopecký
> Assignee: Ståle Pedersen
> Priority: Blocker
> Fix For: 2.0.5.Final
>
>
> *Description of problem:*
> CLI prints unexpected ANSI character to output with "echo" command.
> * This is regression against EAP 7.0.0.DR13
> * This is blocker for GA release.
> * This is not beta blocker.
> * This is probably AESH issue, so I assign [~stalep], but it is also CLI issue, so [~aloubyansky] may be assigned to this
> *How reproducible:*
> Always
> *Steps to Reproduce:*
> # ./standalone.sh
> # ./jboss-cli.sh --connect controller=127.0.0.1 command="echo test-echo" > out.txt
> # vim out.txt
> #* "cat out.txt" can't be used for reproducing, because console hide unexpected ANSI characters
> *Actual results:*
> {noformat}
> ^[[0G^[[2Ktest-echo
> {noformat}
> *Expected results:*
> {noformat}
> test-echo
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 7 months
[JBoss JIRA] (WFCORE-1128) Improve the subsystem test schema test coverage
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1128?page=com.atlassian.jira.plugi... ]
James Perkins updated WFCORE-1128:
----------------------------------
Fix Version/s: 2.0.5.Final
(was: 2.0.4.Final)
> Improve the subsystem test schema test coverage
> -----------------------------------------------
>
> Key: WFCORE-1128
> URL: https://issues.jboss.org/browse/WFCORE-1128
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 2.0.1.Final
> Reporter: Kabir Khan
> Assignee: Kabir Khan
> Fix For: 2.0.5.Final
>
>
> Currently the way to enable the AbstractSubsystemBaseTest testSchema() and testSchemaOfSubsystemTemplates() tests is to override getSubsystemXsdPath() and getSubsystemTemplatePaths().
> Rather than making it explicit to turn on, it should be explicit to turn off.
> Also the current way of doing this uses Assume.assumeTrue() to check if a test has provided a schema file, which provides a lot of ignored test noise in the test output. If the xsd should not be tested, methods should instead override testSchema() or testSchemaOfSubsystemTemplates() and provide an empty implementation with a comment saying why it is not important.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 7 months
[JBoss JIRA] (WFLY-5770) Lock TimeoutException on CacheRegistry.close()
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-5770?page=com.atlassian.jira.plugin.... ]
Paul Ferraro updated WFLY-5770:
-------------------------------
Summary: Lock TimeoutException on CacheRegistry.close() (was: TimeoutException on CacheRegistry.close())
> Lock TimeoutException on CacheRegistry.close()
> ----------------------------------------------
>
> Key: WFLY-5770
> URL: https://issues.jboss.org/browse/WFLY-5770
> Project: WildFly
> Issue Type: Task
> Components: Clustering
> Affects Versions: 10.0.0.CR4
> Reporter: Radoslav Husar
> Assignee: Richard Achmatowicz
>
> Just happened on node shutdown when testing locally.
> {noformat}
> 19:22:21,114 INFO [org.wildfly.extension.undertow] (MSC service thread 1-7) WFLYUT0004: Undertow 1.3.7.Final stopping
> 19:22:21,114 ERROR [stderr] (ServerService Thread Pool -- 82) Exception in thread "ServerService Thread Pool -- 82" org.infinispan.util.concurrent.TimeoutException: Could not acquire lock on node2 in behalf of transaction GlobalTransaction:<node2>:4223:local. Current owner GlobalTransaction:<node2>:4217:local.
> 19:22:21,115 ERROR [stderr] (ServerService Thread Pool -- 82) at org.infinispan.util.concurrent.locks.impl.DefaultPendingLockManager.timeout(DefaultPendingLockManager.java:224)
> 19:22:21,115 ERROR [stderr] (ServerService Thread Pool -- 82) at org.infinispan.util.concurrent.locks.impl.DefaultPendingLockManager.checkForPendingLock(DefaultPendingLockManager.java:196)
> 19:22:21,115 ERROR [stderr] (ServerService Thread Pool -- 82) at org.infinispan.util.concurrent.locks.impl.DefaultPendingLockManager.awaitPendingTransactionsForKey(DefaultPendingLockManager.java:115)
> 19:22:21,115 ERROR [stderr] (ServerService Thread Pool -- 82) at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.checkPendingAndLockKey(AbstractTxLockingInterceptor.java:190)
> 19:22:21,115 ERROR [stderr] (ServerService Thread Pool -- 82) at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.lockOrRegisterBackupLock(AbstractTxLockingInterceptor.java:115)
> 19:22:21,115 ERROR [stderr] (ServerService Thread Pool -- 82) at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitDataWriteCommand(PessimisticLockingInterceptor.java:121)
> 19:22:21,115 ERROR [stderr] (ServerService Thread Pool -- 82) at org.infinispan.interceptors.locking.AbstractLockingInterceptor.visitRemoveCommand(AbstractLockingInterceptor.java:71)
> 19:22:21,115 ERROR [stderr] (ServerService Thread Pool -- 82) at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:59)
> 19:22:21,115 ERROR [stderr] (ServerService Thread Pool -- 82) at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> 19:22:21,115 ERROR [stderr] (ServerService Thread Pool -- 82) at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:113)
> 19:22:21,115 ERROR [stderr] (ServerService Thread Pool -- 82) at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:48)
> 19:22:21,115 ERROR [stderr] (ServerService Thread Pool -- 82) at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:59)
> 19:22:21,115 ERROR [stderr] (ServerService Thread Pool -- 82) at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> 19:22:21,116 ERROR [stderr] (ServerService Thread Pool -- 82) at org.infinispan.interceptors.TxInterceptor.enlistWriteAndInvokeNext(TxInterceptor.java:366)
> 19:22:21,116 ERROR [stderr] (ServerService Thread Pool -- 82) at org.infinispan.interceptors.TxInterceptor.visitRemoveCommand(TxInterceptor.java:230)
> 19:22:21,116 ERROR [stderr] (ServerService Thread Pool -- 82) at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:59)
> 19:22:21,116 ERROR [stderr] (ServerService Thread Pool -- 82) at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> 19:22:21,116 ERROR [stderr] (ServerService Thread Pool -- 82) at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:113)
> 19:22:21,116 ERROR [stderr] (ServerService Thread Pool -- 82) at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:48)
> 19:22:21,116 ERROR [stderr] (ServerService Thread Pool -- 82) at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:59)
> 19:22:21,116 ERROR [stderr] (ServerService Thread Pool -- 82) at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> 19:22:21,116 ERROR [stderr] (ServerService Thread Pool -- 82) at org.infinispan.statetransfer.StateTransferInterceptor.handleTxWriteCommand(StateTransferInterceptor.java:304)
> 19:22:21,116 ERROR [stderr] (ServerService Thread Pool -- 82) at org.infinispan.statetransfer.StateTransferInterceptor.handleWriteCommand(StateTransferInterceptor.java:286)
> 19:22:21,116 ERROR [stderr] (ServerService Thread Pool -- 82) at org.infinispan.statetransfer.StateTransferInterceptor.visitRemoveCommand(StateTransferInterceptor.java:123)
> 19:22:21,116 ERROR [stderr] (ServerService Thread Pool -- 82) at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:59)
> 19:22:21,116 ERROR [stderr] (ServerService Thread Pool -- 82) at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> 19:22:21,116 ERROR [stderr] (ServerService Thread Pool -- 82) at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:102)
> 19:22:21,116 ERROR [stderr] (ServerService Thread Pool -- 82) at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:71)
> 19:22:21,116 ERROR [stderr] (ServerService Thread Pool -- 82) at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:48)
> 19:22:21,116 ERROR [stderr] (ServerService Thread Pool -- 82) at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:59)
> 19:22:21,117 ERROR [stderr] (ServerService Thread Pool -- 82) at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:336)
> 19:22:21,117 ERROR [stderr] (ServerService Thread Pool -- 82) at org.infinispan.cache.impl.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1634)
> 19:22:21,117 ERROR [stderr] (ServerService Thread Pool -- 82) at org.infinispan.cache.impl.CacheImpl.removeInternal(CacheImpl.java:558)
> 19:22:21,117 ERROR [stderr] (ServerService Thread Pool -- 82) at org.infinispan.cache.impl.CacheImpl.remove(CacheImpl.java:549)
> 19:22:21,117 ERROR [stderr] (ServerService Thread Pool -- 82) at org.infinispan.cache.impl.DecoratedCache.remove(DecoratedCache.java:452)
> 19:22:21,117 ERROR [stderr] (ServerService Thread Pool -- 82) at org.infinispan.cache.impl.AbstractDelegatingCache.remove(AbstractDelegatingCache.java:296)
> 19:22:21,117 ERROR [stderr] (ServerService Thread Pool -- 82) at org.wildfly.clustering.server.registry.CacheRegistry.lambda$close$0(CacheRegistry.java:101)
> 19:22:21,117 ERROR [stderr] (ServerService Thread Pool -- 82) at org.wildfly.clustering.service.concurrent.StampedLockServiceExecutor.close(StampedLockServiceExecutor.java:55)
> 19:22:21,117 ERROR [stderr] (ServerService Thread Pool -- 82) at org.wildfly.clustering.server.registry.CacheRegistry.close(CacheRegistry.java:96)
> 19:22:21,117 ERROR [stderr] (ServerService Thread Pool -- 82) at org.wildfly.clustering.server.registry.CacheRegistryFactory$1.close(CacheRegistryFactory.java:56)
> 19:22:21,117 ERROR [stderr] (ServerService Thread Pool -- 82) at org.wildfly.clustering.server.registry.RegistryBuilder.stop(RegistryBuilder.java:88)
> 19:22:21,117 ERROR [stderr] (ServerService Thread Pool -- 82) at org.wildfly.clustering.service.AsynchronousServiceBuilder$2.run(AsynchronousServiceBuilder.java:130)
> 19:22:21,117 ERROR [stderr] (ServerService Thread Pool -- 82) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> 19:22:21,118 ERROR [stderr] (ServerService Thread Pool -- 82) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 19:22:21,118 ERROR [stderr] (ServerService Thread Pool -- 82) at java.lang.Thread.run(Thread.java:745)
> 19:22:21,118 ERROR [stderr] (ServerService Thread Pool -- 82) at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> 19:22:21,118 ERROR [stderr] (ServerService Thread Pool -- 82) Suppressed: org.infinispan.commons.CacheException: javax.transaction.RollbackException: Transaction marked as rollback only.
> 19:22:21,118 ERROR [stderr] (ServerService Thread Pool -- 82) at org.wildfly.clustering.ee.infinispan.ActiveTransactionBatch.close(ActiveTransactionBatch.java:50)
> 19:22:21,118 ERROR [stderr] (ServerService Thread Pool -- 82) at org.wildfly.clustering.server.registry.CacheRegistry.lambda$close$0(CacheRegistry.java:102)
> 19:22:21,118 ERROR [stderr] (ServerService Thread Pool -- 82) ... 9 more
> 19:22:21,118 ERROR [stderr] (ServerService Thread Pool -- 82) Caused by: javax.transaction.RollbackException: Transaction marked as rollback only.
> 19:22:21,118 ERROR [stderr] (ServerService Thread Pool -- 82) at org.infinispan.transaction.tm.DummyTransaction.setRollbackOnly(DummyTransaction.java:146)
> 19:22:21,118 ERROR [stderr] (ServerService Thread Pool -- 82) at org.infinispan.interceptors.TxInterceptor.enlistWriteAndInvokeNext(TxInterceptor.java:374)
> 19:22:21,118 ERROR [stderr] (ServerService Thread Pool -- 82) at org.infinispan.interceptors.TxInterceptor.visitRemoveCommand(TxInterceptor.java:230)
> 19:22:21,118 ERROR [stderr] (ServerService Thread Pool -- 82) at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:59)
> 19:22:21,119 ERROR [stderr] (ServerService Thread Pool -- 82) at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> 19:22:21,119 ERROR [stderr] (ServerService Thread Pool -- 82) at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:113)
> 19:22:21,119 ERROR [stderr] (ServerService Thread Pool -- 82) at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:48)
> 19:22:21,119 ERROR [stderr] (ServerService Thread Pool -- 82) at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:59)
> 19:22:21,119 ERROR [stderr] (ServerService Thread Pool -- 82) at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> 19:22:21,119 ERROR [stderr] (ServerService Thread Pool -- 82) at org.infinispan.statetransfer.StateTransferInterceptor.handleTxWriteCommand(StateTransferInterceptor.java:304)
> 19:22:21,119 ERROR [stderr] (ServerService Thread Pool -- 82) at org.infinispan.statetransfer.StateTransferInterceptor.handleWriteCommand(StateTransferInterceptor.java:286)
> 19:22:21,119 ERROR [stderr] (ServerService Thread Pool -- 82) at org.infinispan.statetransfer.StateTransferInterceptor.visitRemoveCommand(StateTransferInterceptor.java:123)
> 19:22:21,119 ERROR [stderr] (ServerService Thread Pool -- 82) at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:59)
> 19:22:21,119 ERROR [stderr] (ServerService Thread Pool -- 82) at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> 19:22:21,119 ERROR [stderr] (ServerService Thread Pool -- 82) at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:102)
> 19:22:21,119 ERROR [stderr] (ServerService Thread Pool -- 82) at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:71)
> 19:22:21,119 ERROR [stderr] (ServerService Thread Pool -- 82) at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:48)
> 19:22:21,119 ERROR [stderr] (ServerService Thread Pool -- 82) at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:59)
> 19:22:21,119 ERROR [stderr] (ServerService Thread Pool -- 82) at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:336)
> 19:22:21,119 ERROR [stderr] (ServerService Thread Pool -- 82) at org.infinispan.cache.impl.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1634)
> 19:22:21,119 ERROR [stderr] (ServerService Thread Pool -- 82) at org.infinispan.cache.impl.CacheImpl.removeInternal(CacheImpl.java:558)
> 19:22:21,120 ERROR [stderr] (ServerService Thread Pool -- 82) at org.infinispan.cache.impl.CacheImpl.remove(CacheImpl.java:549)
> 19:22:21,120 ERROR [stderr] (ServerService Thread Pool -- 82) at org.infinispan.cache.impl.DecoratedCache.remove(DecoratedCache.java:452)
> 19:22:21,120 ERROR [stderr] (ServerService Thread Pool -- 82) at org.infinispan.cache.impl.AbstractDelegatingCache.remove(AbstractDelegatingCache.java:296)
> 19:22:21,120 ERROR [stderr] (ServerService Thread Pool -- 82) at org.wildfly.clustering.server.registry.CacheRegistry.lambda$close$0(CacheRegistry.java:101)
> 19:22:21,120 ERROR [stderr] (ServerService Thread Pool -- 82) ... 9 more
> 19:22:31,124 WARN [org.infinispan.transaction.impl.TransactionTable] (ServerService Thread Pool -- 88) ISPN000100: Stopping, but there are 1 local transactions and 0 remote transactions that did not finish in time.
> 19:22:31,125 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 88) WFLYCLINF0003: Stopped routing cache from web container
> 19:22:31,128 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-7) ISPN000080: Disconnecting JGroups channel web
> 19:22:31,128 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-7) ISPN000082: Stopping the RpcDispatcher for channel web
> 19:22:31,141 INFO [org.jboss.as] (MSC service thread 1-5) WFLYSRV0050: WildFly Full 10.0.0.CR5-SNAPSHOT (WildFly Core 2.0.3.Final) stopped in 25086ms
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 7 months
[JBoss JIRA] (WFCORE-1175) CLI prints unexpected ANSI characters to output with "echo" command
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1175?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1175:
-------------------------------------
Fix Version/s: 2.0.4.Final
I'm scheduling this for 2.0.4 even though I know it won't get done for that (release is in progress.) I just want it to automatically get rescheduled to 2.0.5 once that is created so it stays visible for the pending release.
> CLI prints unexpected ANSI characters to output with "echo" command
> -------------------------------------------------------------------
>
> Key: WFCORE-1175
> URL: https://issues.jboss.org/browse/WFCORE-1175
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Affects Versions: 2.0.3.Final
> Reporter: Marek Kopecký
> Assignee: Ståle Pedersen
> Priority: Blocker
> Fix For: 2.0.4.Final
>
>
> *Description of problem:*
> CLI prints unexpected ANSI character to output with "echo" command.
> * This is regression against EAP 7.0.0.DR13
> * This is blocker for GA release.
> * This is not beta blocker.
> * This is probably AESH issue, so I assign [~stalep], but it is also CLI issue, so [~aloubyansky] may be assigned to this
> *How reproducible:*
> Always
> *Steps to Reproduce:*
> # ./standalone.sh
> # ./jboss-cli.sh --connect controller=127.0.0.1 command="echo test-echo" > out.txt
> # vim out.txt
> #* "cat out.txt" can't be used for reproducing, because console hide unexpected ANSI characters
> *Actual results:*
> {noformat}
> ^[[0G^[[2Ktest-echo
> {noformat}
> *Expected results:*
> {noformat}
> test-echo
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 7 months