July 2013 - jboss-jira - Jboss List Archives

[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: ------------------------------ Attachment: jboss-as-domain.sh.patch jboss-as-standalone.sh.patch > 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 > Attachments: jboss-as-domain.sh.patch, jboss-as-standalone.sh.patch > > > 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

13 years

1
0
0 / 0

[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

13 years

1
0
0 / 0

[JBoss JIRA] (WFLY-1619) JBOSS_CONSOLE_LOG

by Dhruv Ahuja (JIRA)

Dhruv Ahuja created WFLY-1619: --------------------------------- Summary: JBOSS_CONSOLE_LOG Key: WFLY-1619 URL: https://issues.jboss.org/browse/WFLY-1619 Project: WildFly Issue Type: Enhancement Reporter: Dhruv Ahuja Priority: Minor -- 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

13 years

1
0
0 / 0

[JBoss JIRA] (WFLY-1618) Access Control - User to Role Mapping

by Darran Lofthouse (JIRA)

Darran Lofthouse created WFLY-1618: -------------------------------------- Summary: Access Control - User to Role Mapping Key: WFLY-1618 URL: https://issues.jboss.org/browse/WFLY-1618 Project: WildFly Issue Type: Task Components: Domain Management Reporter: Darran Lofthouse Assignee: Darran Lofthouse Priority: Critical Fix For: 8.0.0.Alpha3 -- 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

13 years

1
0
0 / 0

[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

13 years

1
0
0 / 0

[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

13 years

1
0
0 / 0

[JBoss JIRA] (WFLY-1611) Add ability to relax the password rules for management/application realm users

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-1611?page=com.atlassian.jira.plugin.... ] Darran Lofthouse commented on WFLY-1611: ---------------------------------------- Agreed, this should be configurable - closely related is another task requesting that before the password is prompted for we display the current password requirements, would be advisable to tackle both at the same time. Due to time constraints it is unlikely I will get to this in 2013 and if I do it would be towards the end so any volunteers are welcome to take a look. > Add ability to relax the password rules for management/application realm users > ------------------------------------------------------------------------------ > > Key: WFLY-1611 > URL: https://issues.jboss.org/browse/WFLY-1611 > Project: WildFly > Issue Type: Feature Request > Components: Security > Affects Versions: 8.0.0.Alpha2 > Reporter: jaikiran pai > Assignee: Darran Lofthouse > Fix For: Awaiting Volunteers > > > Currently the user creation scripts (add-user.sh/add-user.bat) for adding users to the Management/Application realm enforce certain password rules. It would be good to allow a way to relax some of these rules typically in development/personal machines. A discussion about this is available in here which proposes certain ideas http://lists.jboss.org/pipermail/jboss-as7-dev/2012-October/006997.html -- 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

13 years

1
0
0 / 0

[JBoss JIRA] (WFLY-1611) Add ability to relax the password rules for management/application realm users

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-1611?page=com.atlassian.jira.plugin.... ] Darran Lofthouse updated WFLY-1611: ----------------------------------- Fix Version/s: Awaiting Volunteers > Add ability to relax the password rules for management/application realm users > ------------------------------------------------------------------------------ > > Key: WFLY-1611 > URL: https://issues.jboss.org/browse/WFLY-1611 > Project: WildFly > Issue Type: Feature Request > Components: Security > Affects Versions: 8.0.0.Alpha2 > Reporter: jaikiran pai > Assignee: Darran Lofthouse > Fix For: Awaiting Volunteers > > > Currently the user creation scripts (add-user.sh/add-user.bat) for adding users to the Management/Application realm enforce certain password rules. It would be good to allow a way to relax some of these rules typically in development/personal machines. A discussion about this is available in here which proposes certain ideas http://lists.jboss.org/pipermail/jboss-as7-dev/2012-October/006997.html -- 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

13 years

1
0
0 / 0

[JBoss JIRA] (WFLY-1616) Release core console 1.5.4 (HAL Dependency)

by Harald Pehl (JIRA)

[ https://issues.jboss.org/browse/WFLY-1616?page=com.atlassian.jira.plugin.... ] Harald Pehl resolved WFLY-1616. ------------------------------- Resolution: Done Released > Release core console 1.5.4 (HAL Dependency) > ------------------------------------------- > > Key: WFLY-1616 > URL: https://issues.jboss.org/browse/WFLY-1616 > Project: WildFly > Issue Type: Feature Request > Components: Web Console > Reporter: Heiko Braun > Assignee: Harald Pehl > > As a dependency for HAL extensions -- 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

13 years

1
0
0 / 0

[JBoss JIRA] (JGRP-1643) Change license to Apache License 2.0

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1643?page=com.atlassian.jira.plugin.... ] Bela Ban resolved JGRP-1643. ---------------------------- Resolution: Done > Change license to Apache License 2.0 > ------------------------------------ > > Key: JGRP-1643 > URL: https://issues.jboss.org/browse/JGRP-1643 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.4 > > > Change the license from LGPL 2.1 to AL 2.0. This includes the following tasks: > * Identify all contributors who have code in master (to be 3.4) > * Remove contributors who are Red Hat employees (work-for-hire) > * Remove contributors who were Red Hat employees at the time of the contribution > * Contact the remaining contributors and ask for their permission to change the license > * Change the web site to list both LGPL 2.1 (<= 3.3) and AL 2.0 (>= 3.4) licenses > * Change LICENSE in master: include both licenses, state that code <= 3.3 is licensed under LGPL 2.1 and later code is licensed under AL 2.0 -- 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

13 years

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira July 2013