[JBoss JIRA] (JBASMP-47) execute-commands on EAP6.1.0
by wiktorowski maximilien (JIRA)
wiktorowski maximilien created JBASMP-47:
--------------------------------------------
Summary: execute-commands on EAP6.1.0
Key: JBASMP-47
URL: https://issues.jboss.org/browse/JBASMP-47
Project: JBoss AS Maven Plugins
Issue Type: Bug
Affects Versions: 7.4.Final
Reporter: wiktorowski maximilien
Assignee: James Perkins
I'm trying to use execute-commands goal with EAP 6.1.0 and got :
Failed to initialize CLI context: Failed to parse jboss-cli.xml: Unexpected element: resolve-parameter-values.
CLI dependency should be updated:
[INFO] Plugin Resolved: jboss-as-maven-plugin-7.4.Final.jar
.....
[INFO] Plugin Dependency Resolved: jboss-as-cli-7.1.2.Final.jar
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 10 months
[JBoss JIRA] (JGRP-1637) Counters overflow
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1637?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-1637 at 7/1/13 8:16 AM:
--------------------------------------------------------
Another example prone to overflow are counters of the number of bytes sent/received. Investigate use of BigInteger.
was (Author: belaban):
Another example prone to overflow are counters of the number of bytes sent/received. Investigate use of BigInteger / BigLong (?)
> Counters overflow
> -----------------
>
> Key: JGRP-1637
> URL: https://issues.jboss.org/browse/JGRP-1637
> Project: JGroups
> Issue Type: Task
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 3.4
>
>
> We have some counters which might see a lot of increments. Investigate which counters are affected (and how) by a potential wraparound, e.g. longs wrap around at 2^63 and go negative.
> For example, storing delivery times in nanoseconds and totalling that number could end up with an overflow as e.g. 2ms = 2000000ns, for 1 million msgs/sec would overflow in roughly 7 weeks ! That's the reason org.jgroups.util.Average was created: instead of totalling delivery time and the number of deliveries to compute avg delivery time, we only maintain a fixed array of delivery times, and its elements are randomly overwritten with new values, so we only keep the (more or less) most recent N values to compute the average.
> Using a long for a message sequence number should not be an issue: even if we send 1 million messages / sec, we could send for roughly 290'000 years !
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 10 months
[JBoss JIRA] (WFLY-878) Message-Driven Beans doesn't support DeliveryActive activation config property
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-878?page=com.atlassian.jira.plugin.s... ]
Jeff Mesnil updated WFLY-878:
-----------------------------
Summary: Message-Driven Beans doesn't support DeliveryActive activation config property (was: Hornetq adapter doesn't implement ActivationConfigProperty DeliveryActive)
> Message-Driven Beans doesn't support DeliveryActive activation config property
> ------------------------------------------------------------------------------
>
> Key: WFLY-878
> URL: https://issues.jboss.org/browse/WFLY-878
> Project: WildFly
> Issue Type: Bug
> Components: EE, EJB, JMS
> Environment: Windows 64 bit
> Reporter: Prasad Deshpande
> Assignee: Jeff Mesnil
>
> I get this warning on AS7.1.1 console, seems that ActivationConfigProperty DeliveryActive is not implemented by hornetq-ra, could we please have it as earlier JMS implementation of JMS had it & application that were using it will fail with AS7 now..?
> 16:04:30,794 WARN [org.jboss.ejb3] (MSC service thread 1-16) JBAS014105: ActivationConfigProperty DeliveryActive will be ignored since it is not allowed by resource adapter: hornetq-ra
> Thanks,
> Prasad
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 10 months
[JBoss JIRA] (JGRP-1637) Counters overflow
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1637?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1637:
--------------------------------
Another example prone to overflow are counters of the number of bytes sent/received. Investigate use of BigInteger / BigLong (?)
> Counters overflow
> -----------------
>
> Key: JGRP-1637
> URL: https://issues.jboss.org/browse/JGRP-1637
> Project: JGroups
> Issue Type: Task
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 3.4
>
>
> We have some counters which might see a lot of increments. Investigate which counters are affected (and how) by a potential wraparound, e.g. longs wrap around at 2^63 and go negative.
> For example, storing delivery times in nanoseconds and totalling that number could end up with an overflow as e.g. 2ms = 2000000ns, for 1 million msgs/sec would overflow in roughly 7 weeks ! That's the reason org.jgroups.util.Average was created: instead of totalling delivery time and the number of deliveries to compute avg delivery time, we only maintain a fixed array of delivery times, and its elements are randomly overwritten with new values, so we only keep the (more or less) most recent N values to compute the average.
> Using a long for a message sequence number should not be an issue: even if we send 1 million messages / sec, we could send for roughly 290'000 years !
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 10 months
[JBoss JIRA] (WFLY-1619) Output to JBOSS_CONSOLE_LOG should be Appended to allow Truncate for Log Rotation
by Dhruv Ahuja (JIRA)
[ https://issues.jboss.org/browse/WFLY-1619?page=com.atlassian.jira.plugin.... ]
Dhruv Ahuja updated WFLY-1619:
------------------------------
Summary: Output to JBOSS_CONSOLE_LOG should be Appended to allow Truncate for Log Rotation (was: JBOSS_CONSOLE_LOG)
Affects Version/s: 8.0.0.Alpha2
Description:
The init scripts (jboss-as-domain.sh and jboss-as-standalone.sh) use the BASH redirect operator {{>}} to write output meant for the console upon starting the service to, by default, the console.log file. Truncating this file (for perhaps log rotation) whilst the service is running has proven to be ineffective due to this mode of writing.
Please see a related issue: JBAS-6361 . Also, a useful discussion on the use of {{>}} and {{>>}} (append) operators relevant in this context can be found at: http://stackoverflow.com/questions/980283/truncating-a-file-while-its-bei... .
Component/s: Scripts
> Output to JBOSS_CONSOLE_LOG should be Appended to allow Truncate for Log Rotation
> ---------------------------------------------------------------------------------
>
> Key: WFLY-1619
> URL: https://issues.jboss.org/browse/WFLY-1619
> Project: WildFly
> Issue Type: Enhancement
> Components: Scripts
> Affects Versions: 8.0.0.Alpha2
> Reporter: Dhruv Ahuja
> Priority: Minor
>
> The init scripts (jboss-as-domain.sh and jboss-as-standalone.sh) use the BASH redirect operator {{>}} to write output meant for the console upon starting the service to, by default, the console.log file. Truncating this file (for perhaps log rotation) whilst the service is running has proven to be ineffective due to this mode of writing.
> Please see a related issue: JBAS-6361 . Also, a useful discussion on the use of {{>}} and {{>>}} (append) operators relevant in this context can be found at: http://stackoverflow.com/questions/980283/truncating-a-file-while-its-bei... .
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 10 months
[JBoss JIRA] (WFLY-1617) Upgrade maven-enforcer-plugin for MApache Maven 3.1.x support
by Emmanuel Hugonnet (JIRA)
Emmanuel Hugonnet created WFLY-1617:
---------------------------------------
Summary: Upgrade maven-enforcer-plugin for MApache Maven 3.1.x support
Key: WFLY-1617
URL: https://issues.jboss.org/browse/WFLY-1617
Project: WildFly
Issue Type: Enhancement
Components: Build System
Affects Versions: 8.0.0.Alpha3
Reporter: Emmanuel Hugonnet
Assignee: Paul Gier
When building wildlfy with Apache Maven 3.1.0-alpha1 it complains on missing classes when using the maven-enforcer-plugin.
Upgrading the maven-enforcer-plugin to version 1.3 enables the build to run successfully on Apache Maven 3.1.0-alpha1 and 3.0.5.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 10 months
[JBoss JIRA] (JGRP-1644) NAKACK2 violates FIFO property
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1644?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1644:
--------------------------------
I started looking into this issue now.
So what exactly do you do ? Can you come up with a small program that reproduces the issue ?
Re concurrent calling of receive(): JGroups guarantees that regular (not OOB!) messages are delivered FIFO per sender. So messages A1 and A2 from A will be delivered A1 -> A2, but if there's a message from B, it will be delivered in parallel to A1 and A2.
You realize that using multiple threads, *application ordering* of messages can get incorrect, but you said that you only send from 1 thread, so that should be fine.
> NAKACK2 violates FIFO property
> ------------------------------
>
> Key: JGRP-1644
> URL: https://issues.jboss.org/browse/JGRP-1644
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.3.1
> Environment: Ubuntu 12.04 LTS, kernel 3.2.0-24-generic #39-Ubuntu SMP Mon May 21 16:52:17 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux, Java 1.7.0_21
> Reporter: Vadim Tsesko
> Assignee: Bela Ban
> Fix For: 3.4
>
> Attachments: TCP-NAKACK2.png, UDP-NAKACK2-NAKACK.png
>
>
> In the [documentation documentation|http://www.jgroups.org/manual/html/protlist.html#ReliableMe...] it is stated that:
> {quote}
> NAKACK provides reliable delivery and FIFO (= First In First Out) properties for messages sent to all nodes in a cluster.
> {quote}
> and
> {quote}
> NAKACK2 was introduced in 3.1 and is a successor to NAKACK (at some point it will replace NAKACK). It has the same properties as NAKACK, but its implementation is faster and uses less memory, plus it creates fewer tasks in the timer.
> {quote}
> I have observed that sometimes multicast messages are received out of order.
> We use the following protocol stack configuration:
> {code:xml}
> <config xmlns="urn:org:jgroups"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="urn:org:jgroups http://www.jgroups.org/schema/JGroups-3.3.xsd">
> <UDP bind_addr="match-interface:$interface"
> bind_interface="$interface"
> bind_port="$unicastPort"
> ip_ttl="128"
> mcast_addr="$multicastGroup"
> mcast_port="$multicastPort"
> singleton_name="udp-transport"/>
> <PING return_entire_cache="true"
> break_on_coord_rsp="false"/>
> <MERGE3/>
> <FD_SOCK/>
> <FD_ALL/>
> <VERIFY_SUSPECT/>
> <BARRIER/>
> <pbcast.NAKACK print_stability_history_on_failed_xmit="true"/>
> <pbcast.STABLE/>
> <pbcast.GMS/>
> <MFC max_credits="8M"/>
> <FRAG2/>
> <RSVP/>
> </config>
> {code}
> As you can see, mostly we use the defaults.
> The messages are being sent from a single thread using the following code:
> {code:java}
> channel.send(new Message(null, msg))
> {code}
> Each message has size from 300 KB up to 4 MB. The message rate is 1-5 messages per second.
> We have a sequential counter inside each message being sent. Sometimes the messages are received out of order, for instance:
> {code}
> #1198
> #1199
> #1200
> #1202
> #1201
> #1203
> #1204
> {code}
> If we replace {{NAKACK2}} by {{NAKACK}} the problem disappears -- everything works as expected (FIFO).
> If we replace JGroups-based transport by ZeroMQ-based transport (actually running over EPGM and being used for a year) everything works as expected (FIFO) -- just to let you know, that there are no bugs in out message numbering logic.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 10 months