November 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JGRP-1966) Specify logger name for LogRecord in JDKLogImpl

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1966?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-1966: -------------------------------- Not sure I understand what the issue is. Also, I've never used either JDK logging or sl4j. Can you submit a pull request to fix what you perceive to be the issue? Meanwhile, I'm closing this one, feel free to reopen once you have a PR. > Specify logger name for LogRecord in JDKLogImpl > ----------------------------------------------- > > Key: JGRP-1966 > URL: https://issues.jboss.org/browse/JGRP-1966 > Project: JGroups > Issue Type: Enhancement > Affects Versions: 3.6.6 > Reporter: George Zalizko > Assignee: Bela Ban > Priority: Minor > Fix For: 3.6.7 > > > I use Spring Boot with logback. > For logging I have pattern: > {code}%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} %C{30}:%L - %msg%n{code} > And in console I see: > {code} > 16:19:32.062 [OOB-1,yphis-cluster-web,George-THINKPAD-35404] WARN unknown.jul.logger org.jgroups.logging.JDKLogImpl:49 - JGRP000010: packet from 192.168.50.123:45588 has different version (3.2.8) than ours (3.6.6); packet is discarded{code} > This happens because LogRecord created in org.jgroups.logging.JDKLogImpl doesn't have loggerName and when org.slf4j.bridge.SLF4JBridgeHandler make org.slf4j.Logger from java.util.logging.LogRecord he sets logger name as org.slf4j.bridge.SLF4JBridgeHandler#UNKNOWN_LOGGER_NAME that's "unknown.jul.logger" > Actually I don't know is it done specially or not, but I can't find any comments/solutions for that. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1966) Specify logger name for LogRecord in JDKLogImpl

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1966?page=com.atlassian.jira.plugin.... ] Bela Ban resolved JGRP-1966. ---------------------------- Resolution: Won't Fix > Specify logger name for LogRecord in JDKLogImpl > ----------------------------------------------- > > Key: JGRP-1966 > URL: https://issues.jboss.org/browse/JGRP-1966 > Project: JGroups > Issue Type: Enhancement > Affects Versions: 3.6.6 > Reporter: George Zalizko > Assignee: Bela Ban > Priority: Minor > Fix For: 3.6.7 > > > I use Spring Boot with logback. > For logging I have pattern: > {code}%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} %C{30}:%L - %msg%n{code} > And in console I see: > {code} > 16:19:32.062 [OOB-1,yphis-cluster-web,George-THINKPAD-35404] WARN unknown.jul.logger org.jgroups.logging.JDKLogImpl:49 - JGRP000010: packet from 192.168.50.123:45588 has different version (3.2.8) than ours (3.6.6); packet is discarded{code} > This happens because LogRecord created in org.jgroups.logging.JDKLogImpl doesn't have loggerName and when org.slf4j.bridge.SLF4JBridgeHandler make org.slf4j.Logger from java.util.logging.LogRecord he sets logger name as org.slf4j.bridge.SLF4JBridgeHandler#UNKNOWN_LOGGER_NAME that's "unknown.jul.logger" > Actually I don't know is it done specially or not, but I can't find any comments/solutions for that. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5699) Upgrade common-collections to 3.2.2

by Christian Heinemann (JIRA)

[ https://issues.jboss.org/browse/WFLY-5699?page=com.atlassian.jira.plugin.... ] Christian Heinemann commented on WFLY-5699: ------------------------------------------- Fix version should be assigned to 10.0.0.CR5. > Upgrade common-collections to 3.2.2 > ----------------------------------- > > Key: WFLY-5699 > URL: https://issues.jboss.org/browse/WFLY-5699 > Project: WildFly > Issue Type: Component Upgrade > Reporter: Tomaz Cerar > Assignee: Tomaz Cerar > > Upgrade to address the serialization exploit -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1990) Headers: use 1 array rather than 2

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1990?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-1990: -------------------------------- If we do these optimizations, we need to make sure that the wire format doesn't change. Shouldn't be the case anyway, as we're still sending IDs and header, for each header. > Headers: use 1 array rather than 2 > ---------------------------------- > > Key: JGRP-1990 > URL: https://issues.jboss.org/browse/JGRP-1990 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.6.7 > > > Currently, {{Headers}} uses 1 array for ids and 1 for the actual headers. Experiment whether joining them into one array makes sense, e.g.: > {noformat} > | id-1 | hdr-1 | id-2 | hdr-2 | ... | id-n | hdr-n | > {noformat} > This saves 4 bytes (compressed OOPs) for an array ref, plus the overhead of the array itself. Plus, resizing only has to be applied to 1 array. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1990) Headers: use 1 array rather than 2

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1990?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-1990: -------------------------------- Further optimizations: * Remove the IDs altogether and add a field {{id}} to the {{Header}} class * Remove class {{Headers}} and use a {{Header[] hdrs}} array in {{Message}} directly. Provide methods for reading and writing of headers > Headers: use 1 array rather than 2 > ---------------------------------- > > Key: JGRP-1990 > URL: https://issues.jboss.org/browse/JGRP-1990 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.6.7 > > > Currently, {{Headers}} uses 1 array for ids and 1 for the actual headers. Experiment whether joining them into one array makes sense, e.g.: > {noformat} > | id-1 | hdr-1 | id-2 | hdr-2 | ... | id-n | hdr-n | > {noformat} > This saves 4 bytes (compressed OOPs) for an array ref, plus the overhead of the array itself. Plus, resizing only has to be applied to 1 array. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1985) Message: make initial size of headers configurable

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1985?page=com.atlassian.jira.plugin.... ] Bela Ban resolved JGRP-1985. ---------------------------- Resolution: Done > Message: make initial size of headers configurable > -------------------------------------------------- > > Key: JGRP-1985 > URL: https://issues.jboss.org/browse/JGRP-1985 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.6.7 > > > By default a message creates a {{Headers}} instance of 3. This is usually enough (transport, either {{NAKACK2}} or {{UNICAST3}}, and possibly fragmentation). However, if a message needs 4 or more headers, there's a resize which is an additional copy of 2 small arrays. > Goal: make the initial headers size configurable. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1990) Headers: use 1 array rather than 2

by Bela Ban (JIRA)

Bela Ban created JGRP-1990: ------------------------------ Summary: Headers: use 1 array rather than 2 Key: JGRP-1990 URL: https://issues.jboss.org/browse/JGRP-1990 Project: JGroups Issue Type: Enhancement Reporter: Bela Ban Assignee: Bela Ban Fix For: 3.6.7 Currently, {{Headers}} uses 1 array for ids and 1 for the actual headers. Experiment whether joining them into one array makes sense, e.g.: {noformat} | id-1 | hdr-1 | id-2 | hdr-2 | ... | id-n | hdr-n | {noformat} This saves 4 bytes (compressed OOPs) for an array ref, plus the overhead of the array itself. Plus, resizing only has to be applied to 1 array. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1985) Message: make initial size of headers configurable

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1985?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-1985: -------------------------------- Done via system property {{jgroups.msg.default_headers}} > Message: make initial size of headers configurable > -------------------------------------------------- > > Key: JGRP-1985 > URL: https://issues.jboss.org/browse/JGRP-1985 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.6.7 > > > By default a message creates a {{Headers}} instance of 3. This is usually enough (transport, either {{NAKACK2}} or {{UNICAST3}}, and possibly fragmentation). However, if a message needs 4 or more headers, there's a resize which is an additional copy of 2 small arrays. > Goal: make the initial headers size configurable. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5742) Fix test coverage for @RunAs in servlets

by Ondrej Lukas (JIRA)

[ https://issues.jboss.org/browse/WFLY-5742?page=com.atlassian.jira.plugin.... ] Ondrej Lukas moved JBEAP-2027 to WFLY-5742: ------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-5742 (was: JBEAP-2027) Workflow: GIT Pull Request workflow (was: CDW v1) Component/s: Security Test Suite (was: Security) (was: Test Suite) Target Release: (was: 7.0.0.GA) Affects Version/s: 10.0.0.CR4 (was: 7.0.0.DR12) > Fix test coverage for @RunAs in servlets > ---------------------------------------- > > Key: WFLY-5742 > URL: https://issues.jboss.org/browse/WFLY-5742 > Project: WildFly > Issue Type: Bug > Components: Security, Test Suite > Affects Versions: 10.0.0.CR4 > Reporter: Ondrej Lukas > Assignee: Ondrej Lukas > > Test coverage for {{@RunAs}} annotated servlets testing is not sufficient in the server. > The {{WebSecurityRunAsTestCase}} in {{testsuite/integration/basic}} doesn't test the behavior correctly as mentioned in [this comment|https://issues.jboss.org/browse/WFLY-5015?focusedCommentId=131008...] of WFLY-5015. > I suggest to move the coverage to manualmode to be able to test also the behavior of {{@RunAs}} annotated {{HttpServlet.destroy()}} method during AS server shutdown. > Possible "sun-shine" test scenario: > * prepare deployment > ** use init parameter to configure path to a file which will serve as exceptions-counter for the application > ** add EJB annotated with {{@RolesAllowed("Admin")}} > ** add {{@RunAs("Admin")}} annotated servlet which calls the EJB in {{init()}}, {{doGet()}} and {{destroy()}} methods - if exception is thrown it increases the counter in the file (init param) > * start server > * deploy the test deployment > * make call to the servlet > * stop the server > * start the server again > * make call to the servlet > * undeploy test deployment > * check the counter (in file) if the exceptions count is 0 > Create "cloudy" scenarios based on modifications of the "sun-shine" one. (E.g. alter the run-as role name used in servlet and check the EJB call falls in all cases) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5477) Failback fails with ActiveMQIllegalStateException during synchronization with live server

by Jeff Mesnil (JIRA)

[ https://issues.jboss.org/browse/WFLY-5477?page=com.atlassian.jira.plugin.... ] Jeff Mesnil resolved WFLY-5477. ------------------------------- Fix Version/s: 10.0.0.CR5 Resolution: Done Underlying Artemis issue has been fixed in 1.1.0.wildfly-008 > Failback fails with ActiveMQIllegalStateException during synchronization with live server > ----------------------------------------------------------------------------------------- > > Key: WFLY-5477 > URL: https://issues.jboss.org/browse/WFLY-5477 > Project: WildFly > Issue Type: Bug > Components: JMS > Affects Versions: 10.0.0.CR2 > Reporter: Miroslav Novak > Assignee: Clebert Suconic > Priority: Blocker > Fix For: 10.0.0.CR5 > > Attachments: backup-logs.zip, live-logs.zip, mdb-server-logs.zip, standalone-full-ha-backup.xml, standalone-full-ha-live.xml, standalone-full-ha-mdb.xml > > > Sometimes happens that synchronization between live and backup fails during failback with exception ActiveMQIllegalStateException. It causes that live does not activate and backup stops so none of the servers is active to serve clients. > Test scenario: > 1. Start 2 EAP 7.0.0.DR11 servers with Artemis configured in dedicated topology with replicated journal > -- 1st EAP server has Artemis configured as live, 2nd EAP server has Artemis configured as backup > -- queues InQueue and OutQueue are deployed > 2. Send 2000 messages to InQueue to 1st server (live) > 3. Start 3rd EAP 7.0.0.DR11 server with MDB consuming from remote InQueue and sending to remote OutQueue in XA transaction > -- resource adapter is configured for failover > 4. Kill live server when MDB is processing messages > 5. Wait for backup to activate and failover to happen > 6. Start live server again and wait for failback > In step 6. sometimes happens that synchronization between live and backup fails during failback with exception: > {code} > 10:05:13,493 ERROR [org.apache.activemq.artemis.core.server] (AMQ119000: Activation for server ActiveMQServerImpl::serverUUID=null) AMQ224000: Failure in initialisation: ActiveMQIllegalStateException[errorType=I > LLEGAL_STATE message=AMQ119026: Backup Server was not yet in sync with live] > at org.apache.activemq.artemis.core.server.impl.SharedNothingBackupActivation.run(SharedNothingBackupActivation.java:232) [artemis-server-1.1.0.jar:1.1.0] > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_60] > {code} > and live server never activates. Also backup server stops with: > {code} > 10:05:17,846 INFO [org.apache.activemq.artemis.core.server] (Thread-108) AMQ221002: Apache ActiveMQ Artemis Message Broker version 1.1.0 [706b0cb8-6b69-11e5-904d-fd646d33ece8] stopped > 10:05:17,846 INFO [org.apache.activemq.artemis.core.server] (Thread-108) AMQ221039: Restarting as Replicating backup server after live restart > {code} > so live/backup pair is dead and server with MDB looses connection. > Attaching logs from servers and configurations. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira November 2015