[JBoss JIRA] (WFCORE-3556) Unexpected output with grep '^no\(fork\|group\)'
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3556?page=com.atlassian.jira.plugi... ]
Jeff Mesnil resolved WFCORE-3556.
---------------------------------
Fix Version/s: 5.0.0.Alpha2
Resolution: Done
> Unexpected output with grep '^no\(fork\|group\)'
> ------------------------------------------------
>
> Key: WFCORE-3556
> URL: https://issues.jboss.org/browse/WFCORE-3556
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Reporter: Katerina Novotna
> Assignee: Jean-Francois Denise
> Fix For: 5.0.0.Alpha2
>
>
> *Description of problem:*
> Aesh grep command doesn't return expected result. The same command with bash grep gives 'nofork' result.
> *Actual results:*
> [standalone@embedded /] echo nofork | grep '^no\(fork\|group\)'
> [standalone@embedded /]
> *Expected results:*
> [standalone@embedded /] echo nofork | grep '^no\(fork\|group\)'
> [standalone@embedded /] nofork
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (DROOLS-1792) [Guided Decision Table] Default value of a column is not validated with the field data type
by Jozef Marko (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1792?page=com.atlassian.jira.plugi... ]
Jozef Marko resolved DROOLS-1792.
---------------------------------
Resolution: Done
> [Guided Decision Table] Default value of a column is not validated with the field data type
> -------------------------------------------------------------------------------------------
>
> Key: DROOLS-1792
> URL: https://issues.jboss.org/browse/DROOLS-1792
> Project: Drools
> Issue Type: Bug
> Components: Guided Decision Table Editor
> Affects Versions: 7.0.0.Beta5
> Reporter: Jozef Marko
> Assignee: Jozef Marko
> Labels: dtable_testday_preparation, qe-suggest-pre-7.0.0.Final, qe-test-day, reported-by-qe
> Fix For: 7.7.0.Final
>
>
> During definition of a condition or an action column, user has possibility to specify 'Default value' for this column. The problem is that the default value is not validated with the field data type. In practice it means that even when the column expects only _Integer_ values (because of the field data type), the default value still can be some _String_ value. The 'Default value' inputs should be validated like particular cells of the guided decision table. In those cells the user is not able to put _String_ value into the cell where are expected only _Integer_ values.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFCORE-3667) Wildfly 12 : jboss-cli.sh in infinite loop
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3667?page=com.atlassian.jira.plugi... ]
Jeff Mesnil resolved WFCORE-3667.
---------------------------------
Fix Version/s: 5.0.0.Alpha2
Resolution: Done
> Wildfly 12 : jboss-cli.sh in infinite loop
> -------------------------------------------
>
> Key: WFCORE-3667
> URL: https://issues.jboss.org/browse/WFCORE-3667
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Environment: ubuntu 16.06 lxd container
> java version "1.8.0_161" oracle
> v12 migrated from v11
> Reporter: Gaétan QUENTIN
> Assignee: Jean-Francois Denise
> Priority: Critical
> Labels: regression
> Fix For: 5.0.0.Alpha2
>
> Attachments: aesh-readline-1.5.jar, jboss-cli-logging.properties, jboss-cli.25300, jboss-cli.log, term.txt
>
>
> i cannot use anymore the jboss-cli.sh to connect to the contoller since i migrated from v11 to 12:
>
> wildfly@java2:/opt/Wildfly$ ls -la
> drwxr-xr-x 1 root root 156 Mar 3 20:36 jboss-server-migration
> drwxr-xr-x 1 root root 454 Mar 4 00:09 overlays
> drwxr-xr-x 1 root root 166 Mar 4 11:43 scripts
> drwxr-xr-x 1 root root 236 Oct 24 05:30 wildfly-11.0.0.Final
> drwxr-xr-x 1 root root 236 Mar 1 07:29 wildfly-12.0.0.Final
> lrwxrwxrwx 1 root root 20 Mar 4 12:49 wildfly-current -> wildfly-12.0.0.Final
>
>
> my wildfly management console is on 172.20.12.192.
> v12 has been migrated from v11 with the jboss-server-migration tool. Applications and app manager works fine and the wildfly instance controller is well binded on the requested ip.
>
>
> with wildfly-current link on -> wildfly-11.0.0.Final:
>
> this works perfectly:
> (cd /opt/Wildfly/wildfly-current/bin && ./jboss-cli.sh -c -u=xx -p=xx --controller=http-remoting://172.20.12.192:9990)
>
>
> with wildfly-current -> wildfly-12.0.0.Final:
> this go in infinite loop until crash :
> (cd /opt/Wildfly/wildfly-current/bin && ./jboss-cli.sh -c -u=xx -p=xx --controller=http-remoting://172.20.12.192:9990)
>
> output:
>
> '[standalone@172.20.12.192:9990' is not a valid operation name.
> [standalone@172.20.12.192:9990 /] '[standalone@172.20.12.192:9990' is not a valid operation name.
> ''[standalone@172.20.12.192:9990'' is not a valid operation name.
> [standalone@172.20.12.192:9990 /] [standalone@172.20.12.192:9990 /] ''[standalone@172.20.12.192:9990'' is not a valid operation name.
> '[standalone@172.20.12.192:9990' is not a valid operation name.
> [standalone@172.20.12.192:9990 /] '''[standalone@172.20.12.192:9990''' is not a valid operation name.
> ''''[standalone@172.20.12.192:9990'''' is not a valid operation name.
> [standalone@172.20.12.192:9990 /] [standalone@172.20.12.192:9990 /] [standalone@172.20.12.192:9990 /] [standalone@172.20.12.192:9990 /] ''[standalone@172.20.12.192:9990'' is not a valid oper is not a valid operation name.
> '[standalone@172.20.12.192:9990' is not a valid operation name.
> [standalone@172.20.12.192:9990 /] '''''[standalone@172.20.12.192:9990''''' is not a valid operation name.
> ''''''[standalone@172.20.12.192:9990'''''' is not a valid operation name.
> attached is a strace capture file (one of thousands) of jboss-cli .
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFLY-10105) [Artemis 2.x upgrade] Undelivered messages in cluster test with JDBC persistent store
by Erich Duda (JIRA)
Erich Duda created WFLY-10105:
---------------------------------
Summary: [Artemis 2.x upgrade] Undelivered messages in cluster test with JDBC persistent store
Key: WFLY-10105
URL: https://issues.jboss.org/browse/WFLY-10105
Project: WildFly
Issue Type: Bug
Components: JMS
Reporter: Erich Duda
Assignee: Jeff Mesnil
Priority: Blocker
Attachments: server1-logs.zip, server2-logs.zip, test.log.zip
*Scenario:*
* There are two Wildfly servers in cluster. Both use JDBC persistence store.
* Producer sends 6000 messages to server 1.
* After all messages are sent, server 2 is killed and restarted.
* Receiver receives messages from server 2.
*Expectation:* All messages sent by producer are received by receiver from server 2.
*Reality:* Only 5055 messages from 6000 are received.
*Blocker* priority was set because it is regression against previous versions of Wildfly.
The issue was hit with Artemis 2.5.0 with https://github.com/jmesnil/wildfly/tree/WFLY-9407_upgrade_artemis_2.4.0_w... (commit 51dd8102f103ccb0470a3cfc8713d3f9bdb1b65d)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFLY-10104) [Artemis 2.x Upgrade] Failover does not work with HTTP conncetors/acceptors
by Michal Toth (JIRA)
Michal Toth created WFLY-10104:
----------------------------------
Summary: [Artemis 2.x Upgrade] Failover does not work with HTTP conncetors/acceptors
Key: WFLY-10104
URL: https://issues.jboss.org/browse/WFLY-10104
Project: WildFly
Issue Type: Bug
Components: JMS
Affects Versions: 13.0.0.Beta1
Reporter: Michal Toth
Assignee: Jeff Mesnil
Priority: Blocker
Attachments: clients.log, server1.log, server2.log, test.log
Failover does not work with HTTP connectors/acceptors.
*Scenario:*
# There are two Wildfly servers configured as Live-Backup pair
# There is one JMS producer and one JMS receiver which sends/receives messages
# Live server is several times killed and restarted.
*Expectation:* Always when the Live server is killed or restarted, clients do failover or failback.
*Reality*: Sometimes happens that clients don't do failover.
*Users impact:* One of basics feature of HA, failover, does not work properly.
*Blocker* priority was set because this is regression against previous releases of Wildfly.
*Detail description of issue*
In the trace logs it can be seen that clients send HTTP handshake request to active backup, but the handshake fails. All checks (and logs) say that the backup is active in this time period. I tried to run the test with Netty connectors/acceptors and I didn't see this issue.
{code:title=Backup log}
07:52:47,856 WARN [org.apache.activemq.artemis.core.server] (Thread-2 (ActiveMQ-IO-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$6@1f01f347)) AMQ222029: Could not locate page transaction 3 995, ignoring message on position PagePositionImpl [pageNr=2, messageNr=55, recordID=-1] on address=jms.queue.testQueue queue=jms.queue.testQueue
07:52:47,856 WARN [org.apache.activemq.artemis.core.server] (Thread-2 (ActiveMQ-IO-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$6@1f01f347)) AMQ222029: Could not locate page transaction 3 995, ignoring message on position PagePositionImpl [pageNr=2, messageNr=56, recordID=-1] on address=jms.queue.testQueue queue=jms.queue.testQueue
07:52:47,863 INFO [org.apache.activemq.artemis.core.server] (AMQ119000: Activation for server ActiveMQServerImpl::serverUUID=null) AMQ221005: Deleting pending large message as it was not completed: Pair[a=2147485068, b=2147485067]
07:52:47,863 INFO [org.apache.activemq.artemis.core.server] (AMQ119000: Activation for server ActiveMQServerImpl::serverUUID=null) AMQ221005: Deleting pending large message as it was not completed: Pair[a=2147485076, b=2147485075]
07:52:47,864 INFO [org.apache.activemq.artemis.core.server] (AMQ119000: Activation for server ActiveMQServerImpl::serverUUID=null) AMQ221005: Deleting pending large message as it was not completed: Pair[a=2147484450, b=2147484449]
07:52:47,864 INFO [org.apache.activemq.artemis.core.server] (AMQ119000: Activation for server ActiveMQServerImpl::serverUUID=null) AMQ221005: Deleting pending large message as it was not completed: Pair[a=2147485072, b=2147485071]
07:52:47,864 INFO [org.apache.activemq.artemis.core.server] (AMQ119000: Activation for server ActiveMQServerImpl::serverUUID=null) AMQ221005: Deleting pending large message as it was not completed: Pair[a=2147484454, b=2147484453]
07:52:47,866 WARN [org.apache.activemq.artemis.core.client] (activemq-discovery-group-thread-dg-group1) AMQ212034: There are more than one servers on the network broadcasting the same node id. You will see this message exactly once (per node) if a node is restarted, in which case it can be safely ignored. But if it is logged continuously it means you really do have more than one node on the same network active concurrently with the same node id. This could occur if you have a backup node active at the same time as its live node. nodeID=0dee81c9-2d9d-11e8-ba3f-cc3d825f79a4
07:52:47,867 INFO [org.apache.activemq.artemis.core.server] (AMQ119000: Activation for server ActiveMQServerImpl::serverUUID=null) AMQ221007: Server is now live
{code}
{code:title=Clients log}
07:52:49,274 Thread-80 (ActiveMQ-client-global-threads) DEBUG [org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector:726] Remote destination: localhost/127.0.0.1:9080
07:52:49,274 Thread-79 (ActiveMQ-client-global-threads) DEBUG [org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl:1040] Connector towards NettyConnector [host=localhost, port=8080, httpEnabled=false, httpUpgradeEnabled=true, useServlet=false, servletPath=/messaging/ActiveMQServlet, sslEnabled=false, useNio=true, activemqServerName=default, httpUpgradeEndpoint=acceptor] failed
07:52:49,275 Thread-79 (ActiveMQ-client-global-threads) DEBUG [org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl:1081] Trying backup config = TransportConfiguration(name=connector, factory=org-apache-activemq-artemis-core-remoting-impl-netty-NettyConnectorFactory) ?httpUpgradeEndpoint=acceptor&activemqServerName=default&httpUpgradeEnabled=true&port=9080&host=localhost
07:52:49,275 Thread-79 (ActiveMQ-client-global-threads) DEBUG [org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector:447] Connector NettyConnector [host=localhost, port=9080, httpEnabled=false, httpUpgradeEnabled=true, useServlet=false, servletPath=/messaging/ActiveMQServlet, sslEnabled=false, useNio=true, activemqServerName=default, httpUpgradeEndpoint=acceptor] using native epoll
07:52:49,275 Thread-80 (ActiveMQ-client-global-threads) DEBUG [org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector:797] Sending HTTP request DefaultHttpRequest(decodeResult: success, version: HTTP/1.1)
GET HTTP/1.1
host: localhost
upgrade: activemq-remoting
connection: upgrade
activemqServerName: default
httpUpgradeEndpoint: acceptor
Sec-ActiveMQRemoting-Key: QWV3bCfgh75NjWH3pZV5Ew==
07:52:49,275 Thread-79 (ActiveMQ-client-global-threads) DEBUG [org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector:601] AMQ211002: Started EPOLL Netty Connector version 4.1.16.Final to localhost:9080
07:52:49,275 Thread-79 (ActiveMQ-client-global-threads) DEBUG [org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector:726] Remote destination: localhost/127.0.0.1:9080
07:52:49,276 Thread-79 (ActiveMQ-client-global-threads) DEBUG [org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector:797] Sending HTTP request DefaultHttpRequest(decodeResult: success, version: HTTP/1.1)
GET HTTP/1.1
host: localhost
upgrade: activemq-remoting
connection: upgrade
activemqServerName: default
httpUpgradeEndpoint: acceptor
Sec-ActiveMQRemoting-Key: P9xBwRk1eZP5QjDWjqYuIg==
07:52:49,276 Thread-2 (ActiveMQ-client-netty-threads) DEBUG [org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector$HttpUpgradeHandler:876] Received msg=DefaultHttpResponse(decodeResult: success, version: HTTP/1.1)
HTTP/1.1 200 OK
Connection: keep-alive
Last-Modified: Thu, 22 Mar 2018 06:47:03 GMT
Content-Length: 2426
Content-Type: text/html
Accept-Ranges: bytes
Date: Thu, 22 Mar 2018 06:52:49 GMT
07:52:49,276 Thread-2 (ActiveMQ-client-netty-threads) DEBUG [org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector$HttpUpgradeHandler:903] AMQ214023: HTTP Handshake failed, received DefaultHttpResponse(decodeResult: success, version: HTTP/1.1)
HTTP/1.1 200 OK
Connection: keep-alive
Last-Modified: Thu, 22 Mar 2018 06:47:03 GMT
Content-Length: 2426
Content-Type: text/html
Accept-Ranges: bytes
Date: Thu, 22 Mar 2018 06:52:49 GMT
07:52:49,276 Thread-2 (ActiveMQ-client-netty-threads) DEBUG [org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector$HttpUpgradeHandler:876] Received msg=DefaultHttpContent(data: PooledSlicedByteBuf(ridx: 0, widx: 829, cap: 829/829, unwrapped: PooledUnsafeDirectByteBuf(ridx: 1024, widx: 1024, cap: 1024)), decoderResult: success)
07:52:49,276 Thread-2 (ActiveMQ-client-netty-threads) DEBUG [org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector$HttpUpgradeHandler:903] AMQ214023: HTTP Handshake failed, received DefaultHttpContent(data: PooledSlicedByteBuf(ridx: 0, widx: 829, cap: 829/829, unwrapped: PooledUnsafeDirectByteBuf(ridx: 1024, widx: 1024, cap: 1024)), decoderResult: success)
07:52:49,277 Thread-80 (ActiveMQ-client-global-threads) DEBUG [org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl:1040] Connector towards NettyConnector [host=localhost, port=9080, httpEnabled=false, httpUpgradeEnabled=true, useServlet=false, servletPath=/messaging/ActiveMQServlet, sslEnabled=false, useNio=true, activemqServerName=default, httpUpgradeEndpoint=acceptor] failed
{code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFLY-10103) [Artemis 2.x Upgrade] Unable to announce backup
by Michal Toth (JIRA)
Michal Toth created WFLY-10103:
----------------------------------
Summary: [Artemis 2.x Upgrade] Unable to announce backup
Key: WFLY-10103
URL: https://issues.jboss.org/browse/WFLY-10103
Project: WildFly
Issue Type: Bug
Components: JMS
Affects Versions: 13.0.0.Beta1
Reporter: Michal Toth
Assignee: Jeff Mesnil
Priority: Blocker
Attachments: server1.log, server2.log, test.log
In shared store HA test scenario it sometimes happens that backup repeatedly prints the error message \[1\]. When the live is killed later, the backup doesn't become active.
*Users impact:* High availability feature does not work properly.
*Blocker* priority was set because it is regression against previous release of Wildfly.
In this particular test Netty connectors/acceptors are used.
\[1\]
{code}
12:07:26,617 WARN [org.apache.activemq.artemis.core.server] (Thread-1 (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$5@ea5272e)) AMQ222137: Unable to announce backup, retrying: ActiveMQConnectionTimedOutException[errorType=CONNECTION_TIMEDOUT message=AMQ119012: Timed out waiting to receive initial broadcast from cluster]
at org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.createSessionFactory(ServerLocatorImpl.java:761) [artemis-core-client-2.5.0.jar:2.5.0]
at org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.connect(ServerLocatorImpl.java:637) [artemis-core-client-2.5.0.jar:2.5.0]
at org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.connect(ServerLocatorImpl.java:619) [artemis-core-client-2.5.0.jar:2.5.0]
at org.apache.activemq.artemis.core.server.cluster.BackupManager$BackupConnector$1.run(BackupManager.java:246) [artemis-server-2.5.0.jar:2.5.0]
at org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:42) [artemis-commons-2.5.0.jar:2.5.0]
at org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:31) [artemis-commons-2.5.0.jar:2.5.0]
at org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:66) [artemis-commons-2.5.0.jar:2.5.0]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [rt.jar:1.8.0_162]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [rt.jar:1.8.0_162]
at org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118) [artemis-commons-2.5.0.jar:2.5.0]
{code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFLY-10102) JCA RA inflow connections are not always well balanced
by Erich Duda (JIRA)
Erich Duda created WFLY-10102:
---------------------------------
Summary: JCA RA inflow connections are not always well balanced
Key: WFLY-10102
URL: https://issues.jboss.org/browse/WFLY-10102
Project: WildFly
Issue Type: Bug
Components: JMS
Affects Versions: 12.0.0.Final
Reporter: Erich Duda
Assignee: Jeff Mesnil
Attachments: server1-trace.1.zip, server1-trace.2.zip, server1-trace.3.zip, server1-trace.zip, server1.zip, server2-logs.zip, server3-logs.zip, server4-logs.zip, test.log.zip
*Scenario*
* There are 4 Wildfly servers. Severs 1, 3 are in cluster.
* Queue InQueue is deployed to servers 1,3.
* Servers 2 and 4 have RA configured to connect to servers 1 and 3 server.
* Start servers 1,3 and send 10000 (~1Kb) messages to InQueue
* Start servers 2,4 with MDB consuming messages from InQueue and sending to OutQueue.
* When MDBs are processing messages, restart (clean shutdown and start) servers in this order: 1,2,4,3
* Wait until all messages are processed.
* Measure number of consumers on InQueue on servers 1 and 3.
* Difference between number of consumers must be <= 2.
*Expectation:* Number of consumers on servers 1 and 3 are almost equal.
*Reality:* Number of consumers on servers 1 and 3 are sometimes different. E.g. server 1 has 19 consumers and server 3 has 11 consumers.
Note: this is not regression. I can see this issue also with Artemis 1.5.x.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFLY-3588) Undertow subsystem should support arbitrary options
by cnsgithub cnsgithub (JIRA)
[ https://issues.jboss.org/browse/WFLY-3588?page=com.atlassian.jira.plugin.... ]
cnsgithub cnsgithub commented on WFLY-3588:
-------------------------------------------
This is now giving me some headache due to this new option in latest undertow jars
UndertowOptions.ALLOW_UNESCAPED_CHARACTERS_IN_URL -> false
Now certain URL calls with characters containing unescaped values like { do not work anymore (I know that it technically not RFC1738 conform), but it was working before, and i need to still support this..
Is there any way to add this into Wildfly without patching the undertow jar?
> Undertow subsystem should support arbitrary options
> ---------------------------------------------------
>
> Key: WFLY-3588
> URL: https://issues.jboss.org/browse/WFLY-3588
> Project: WildFly
> Issue Type: Feature Request
> Components: Web (Undertow)
> Reporter: Stuart Douglas
> Assignee: Tomaz Cerar
>
> At the moment all well known options are hard coded in the schema. We should also support dynamic options where the class name is specified. This will allow the use of user defined options.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month