November 2015 - jboss-jira - Jboss List Archives

[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)

10 years, 7 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)

10 years, 7 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)

10 years, 7 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)

10 years, 7 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)

10 years, 7 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)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1984) NPE while creating a dynamic FORK channel

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1984?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-1984: -------------------------------- The test code you attached works perfectly for me if you comment {{setDiscardOwnMessages(true)}}. If I only run 1 instance, messages from self will be discarded. No NPE. > NPE while creating a dynamic FORK channel > ----------------------------------------- > > Key: JGRP-1984 > URL: https://issues.jboss.org/browse/JGRP-1984 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.6.4 > Reporter: Ramesh Reddy > Assignee: Bela Ban > Fix For: 3.6.7 > > Attachments: RpcForkDispatcherTest.java, tcp-shared.xml > > > I am trying to create a ForkChannel based on the example in docs with code, when FORK protocol not present in the main stack > {code} > channel=new JChannel("tcp.xml")); > channel.connect("RpcDispatcherTestGroup"); > ForkChannel forkChannel = new ForkChannel(channel, "test-rpc", name, true, ProtocolStack.BELOW, FRAG2.class); > forkChannel.connect("test-rpc"); > {code} > this ends with > {code} > Exception in thread "main" java.lang.NullPointerException > at org.jgroups.protocols.FORK.createForkStack(FORK.java:199) > at org.jgroups.fork.ForkChannel.<init>(ForkChannel.java:79) > at org.teiid.systemmodel.RpcDispatcherTest.start(RpcDispatcherTest.java:32) > at org.teiid.systemmodel.RpcDispatcherTest.main(RpcDispatcherTest.java:54 > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1977) More redundant initial join logic to avoid becoming a fake coordinator

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1977?page=com.atlassian.jira.plugin.... ] Bela Ban resolved JGRP-1977. ---------------------------- Resolution: Rejected If an IGMP join message followed by a multicast causes the multicast to be dropped, then I consider this an incorrect network configuration. Even sending the discovery message multiple times may not help, as you indicated the merge only happen multiple minutes later. It seems the multicast routing table on a switch is not updated for multiple minutes. > More redundant initial join logic to avoid becoming a fake coordinator > ---------------------------------------------------------------------- > > Key: JGRP-1977 > URL: https://issues.jboss.org/browse/JGRP-1977 > Project: JGroups > Issue Type: Enhancement > Reporter: Osamu Nagano > Assignee: Bela Ban > Fix For: 3.6.7 > > > If the very initial JGroups discovery packet is lost, it is never recovered by the current GMS join logic. The node will be a standalone coordinator then merges after several minutes. > This can happen if a new node reside in another network segment and a switch between the segments requires some time to establish a new multicast route. Currently, there is no enough time between IGMP join (by {{MulticastSocket#joinGroup()}}) and the JGroups discovery packet and the later is lost in such a network environment. Because the number of nodes can be very large, configuring a static route in the switch is not reasonable. > Specifically, in method {{org.jgroups.protocols.pbcast.ClientGmsImpl#joinInternal()}}, part of {{gms.getDownProtocol().down(Event.FIND_INITIAL_MBRS_EVT)}} is outside of the retry loop of GMS.max_join_attempts and GMS.join_timeout. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5725) Attribute "secure" not migrated to Undertow subsystem

by Francesco Marchioni (JIRA)

[ https://issues.jboss.org/browse/WFLY-5725?page=com.atlassian.jira.plugin.... ] Francesco Marchioni commented on WFLY-5725: ------------------------------------------- Hi Stuart, well we checked also with the attribute and X-Forwarded-Proto setting, but the behaviour is still the same. From what I can see in org.wildfly.extension.undertow.HttpListenerService the method isSecure always returns false: {code:java} @Override public boolean isSecure() { return false; } {code} On the other hand, we found out that using an apache proxy pass based on *ajp* (ajp://host:port) it does work, so that would be the workaround until the bug is solved. > Attribute "secure" not migrated to Undertow subsystem > ----------------------------------------------------- > > Key: WFLY-5725 > URL: https://issues.jboss.org/browse/WFLY-5725 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Environment: RHEL 7.1 > Reporter: Francesco Marchioni > Assignee: Stuart Douglas > Labels: ea, undertow > > We need to migrate the following EAP 6 configuration from the web subsystem: > <subsystem xmlns="urn:jboss:domain:web:2.1" default-virtual-server="default-host" native="false"> > <connector name="http" protocol="HTTP/1.1" scheme="http" socket-binding="http"/> > <connector name="httpconfidential" protocol="HTTP/1.1" scheme="http" socket-binding="httpsecure" secure="true" enabled="true"/> > <virtual-server name="default-host" enable-welcome-root="true"> > <alias name="localhost"/> > <alias name="example.com"/> > </virtual-server> > </subsystem> > This configuration uses the *secure="true" * attribute to support the transport-guarantee to CONFIDENTIAL which is required by our applications. (We don't use https in EAP which is configured only on the Apache Web server that serves request to EAP 6) > The configuration has been migrated into EAP 7.0.0 Alpha using the CLI /subsystem=web:migrate command. Although no warnings are shown, the resulting configuration *does not contain the attribute "secure"* : > <subsystem xmlns="urn:jboss:domain:undertow:3.0"> > <buffer-cache name="default"/> > <server name="default-server"> > <http-listener name="http" socket-binding="http"/> > <http-listener name="httpconfidential" socket-binding="httpsecure"/> > <host name="default-host" alias="localhost, example.com"> > <location name="/" handler="welcome-content"/> > </host> > </server> > <servlet-container name="default"> > <jsp-config/> > </servlet-container> > <handlers> > <file name="welcome-content" path="${jboss.home.dir}/welcome-content"/> > </handlers> > </subsystem> > Is there any plan to provide backward compatiblity for the secure attribute in EAP 7 ? -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1977) More redundant initial join logic to avoid becoming a fake coordinator

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JGRP-1977?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on JGRP-1977: ----------------------------------------------- Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1281218|https://bugzilla.redhat.com/show_bug.cgi?id=1281218] from NEW to ASSIGNED > More redundant initial join logic to avoid becoming a fake coordinator > ---------------------------------------------------------------------- > > Key: JGRP-1977 > URL: https://issues.jboss.org/browse/JGRP-1977 > Project: JGroups > Issue Type: Enhancement > Reporter: Osamu Nagano > Assignee: Bela Ban > Fix For: 3.6.7 > > > If the very initial JGroups discovery packet is lost, it is never recovered by the current GMS join logic. The node will be a standalone coordinator then merges after several minutes. > This can happen if a new node reside in another network segment and a switch between the segments requires some time to establish a new multicast route. Currently, there is no enough time between IGMP join (by {{MulticastSocket#joinGroup()}}) and the JGroups discovery packet and the later is lost in such a network environment. Because the number of nodes can be very large, configuring a static route in the switch is not reasonable. > Specifically, in method {{org.jgroups.protocols.pbcast.ClientGmsImpl#joinInternal()}}, part of {{gms.getDownProtocol().down(Event.FIND_INITIAL_MBRS_EVT)}} is outside of the retry loop of GMS.max_join_attempts and GMS.join_timeout. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

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 November 2015