July 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JGRP-2065) RoundTrip: latency is high compared to RoundTripTcp/RoundTripServer

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2065?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2065: -------------------------------- Created a bunch of additional bundlers: {{RingBufferBundler}}, {{RingBufferBundlerLockless}} and {{RingBufferBundlerLockless2}}. This needs to be revisited in 4.1, but is postponed until then as I need to go back to working on releasing 4.0 (and its API changes). > RoundTrip: latency is high compared to RoundTripTcp/RoundTripServer > ------------------------------------------------------------------- > > Key: JGRP-2065 > URL: https://issues.jboss.org/browse/JGRP-2065 > Project: JGroups > Issue Type: Task > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 4.0 > > > {{RoundTrip}} is a simple test between 2 members measuring round-trip latency. The sender continually sends a message, the receiver receives it and sends the response, and the sender unblocks when the response is received. Then the sender sends the next message. > The time for the request is then logged at the sender and a min/avg/max value is computed (probably changed to histograms later). > {{RoundTrip}} uses a JGroups channel, configured with {{-props}}, e.g. {{-props ~/tcp.xml}}. > {{RoundTripTcp}} does the same, but uses direct TCP sockets (no JGroups) for communication. > {{RoundTripServer}} uses the client-server classes of JGroups for communication, but no channel is used. > Round trip times (both processes on the same box, a Mac mini): > * {{RoundTrip}} (with {{tcp.xml}} shipped with JGroups): *110 us* > * {{RoundTripTcp}}: *46 us* > * {{RoundTripServer}}: *49 us* > Note that the client/server classes used by {{RoundTripServer}} are also used by the TCP transport (configured in {{tcp.xml}}. > {{RoundTripServer}} is ~6% slower than {{RoundTripTcp}}, but that can be attributed to the additional work the former has to do (e.g. connection reaping etc). This is something we can focus on later. > The big difference are the 110 us for {{RoundTrip}}. The goal is to find out what causes this and eliminate it. Since {{RoundTrip}} and {{RoundTripServer}} use the same underlying client/server classes in JGroups, let's compare these 2. > Tasks: > * Remove all protocols other than TCP in the running stack: (e.g. {{probe.sh remove-protocol=MFC}}). I already did this and the diff was negligible, but let's run this again > * Try various bundlers (e.g. NoBundler) > * Reduce threads in the threadpools, possibly disable (regular and OOB) thread pools (replace with DirectExecutor) > * The default is 1 sender thread, but try with multiple threads > * Measure perf between sending a message (in the bundler) and receiving it -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1869) TP.registerProbeHandler not thread safe

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JGRP-1869?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on JGRP-1869: ----------------------------------------------- Jiří Bílek <jbilek(a)redhat.com> changed the Status of [bug 1336088|https://bugzilla.redhat.com/show_bug.cgi?id=1336088] from ON_QA to VERIFIED > TP.registerProbeHandler not thread safe > --------------------------------------- > > Key: JGRP-1869 > URL: https://issues.jboss.org/browse/JGRP-1869 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.2.12 > Reporter: Dennis Reed > Assignee: Bela Ban > Priority: Minor > Fix For: 3.5 > > > TP.registerProbeHandlers is not thread safe since it modifies preregistered_probe_handlers outside of any synchronization. > If a thread calls this method while another thread is inside startDiagnostics (which can happen easily with a shared transport), it can cause a NullPointerException when startDiagnostics is looping through preregistered_probe_handlers. > Access to preregistered_probe_handlers should be synchronized. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1911) Use consensus for some subsystems

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1911?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-1911: --------------------------- Fix Version/s: 4.1 (was: 4.0) > Use consensus for some subsystems > --------------------------------- > > Key: JGRP-1911 > URL: https://issues.jboss.org/browse/JGRP-1911 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 4.1 > > > Provide options for several subsystems to run with consensus, e.g. > * {{SEQUENCER}} > * {{CENTRAL_LOCK}} > * {{COUNTER}} > * {{TOA}} > * Clustered singletons etc > For example, with the current impl of distributed counters ({{COUNTER}}), the same counter can be available multiple times if we have a split brain. It is currently up to the user to merge counters with different values after a split brain heals. > This is OK, but we should provide a second implementation, based on jgroups-raft, which uses consensus to determine the counter maintainer in a split brain scenario. This will forfeit availability in favor of consistency. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1914) S3_PING doesn't work with S3 buckets created in Frankfurt region

by Ali Hopyar (JIRA)

[ https://issues.jboss.org/browse/JGRP-1914?page=com.atlassian.jira.plugin.... ] Ali Hopyar commented on JGRP-1914: ---------------------------------- Hi Mark, It is good to hear that. Thanks for information. > S3_PING doesn't work with S3 buckets created in Frankfurt region > ----------------------------------------------------------------- > > Key: JGRP-1914 > URL: https://issues.jboss.org/browse/JGRP-1914 > Project: JGroups > Issue Type: Bug > Reporter: Gleb Leonov > Assignee: Bela Ban > Fix For: 4.1 > > Attachments: AWS4.png > > > I tried to use S3_PING with access and secret key pair. However, I got 400 (Bad Request) error. After some investigation, I found that modern S3 buckets created in Frankfurt needs amazon v4 authentication, which needs hmac-sha256. But now S3_PING supports only hmac-sha1, so I see no way to use S3_PING with buckets in Frankfurt region. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6402) EJBs accessible too early (spec violation)

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-6402?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-6402: ----------------------------------------------- Brad Maxwell <bmaxwell(a)redhat.com> changed the Status of [bug 1350355|https://bugzilla.redhat.com/show_bug.cgi?id=1350355] from ASSIGNED to POST > EJBs accessible too early (spec violation) > ------------------------------------------ > > Key: WFLY-6402 > URL: https://issues.jboss.org/browse/WFLY-6402 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 10.0.0.Final > Reporter: Brad Maxwell > Assignee: Fedor Gavrilov > Labels: downstream_dependency > Attachments: auto-test-reproducer.zip > > > {code} > EJB 3.1 spec, section 4.8.1: > "If the Startup annotation appears on the Singleton bean class or if the Singleton has been designated via the deployment descriptor as requiring eager initialization, the container must initialize the Singleton bean instance during the application startup sequence. The container must initialize all such startup-time Singletons before any external client requests (that is, client requests originating outside of the application) are delivered to any enterprise bean components in the application. > {code} > Wildlfy does not implement this correctly, and allows calls to other EJBs before a @Startup @Singleton finishes its @PostConstruct call. > This Jira ticket handles two PR's on WFLY: > https://github.com/wildfly/wildfly/pull/8824 (that is already merged) > and https://github.com/wildfly/wildfly/pull/8989 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1523) RestartParentResourceRemoveHandler should fail when removing non-existing resources

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1523?page=com.atlassian.jira.plugi... ] James Perkins updated WFCORE-1523: ---------------------------------- Fix Version/s: 2.2.0.CR6 (was: 2.2.0.CR5) > RestartParentResourceRemoveHandler should fail when removing non-existing resources > ----------------------------------------------------------------------------------- > > Key: WFCORE-1523 > URL: https://issues.jboss.org/browse/WFCORE-1523 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management, Security > Affects Versions: 2.1.0.Final > Reporter: Ondrej Lukas > Assignee: Brian Stansberry > Priority: Minor > Labels: 2.2 > Fix For: 3.0.0.Alpha1, 2.2.0.CR6 > > > In case when non-existent policy-module is removed through Management CLI, operation should finish with failure. However it finishes with outcome success and nothing is changed. It can be confusing since wrong command seems same as correct command. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6402) EJBs accessible too early (spec violation)

by Brad Maxwell (JIRA)

[ https://issues.jboss.org/browse/WFLY-6402?page=com.atlassian.jira.plugin.... ] Brad Maxwell updated WFLY-6402: ------------------------------- Git Pull Request: https://github.com/wildfly/wildfly/pull/8824, https://github.com/wildfly/wildfly/pull/9009 (was: https://github.com/wildfly/wildfly/pull/8824, https://github.com/wildfly/wildfly/pull/8989, https://github.com/wildfly/wildfly/pull/9009) > EJBs accessible too early (spec violation) > ------------------------------------------ > > Key: WFLY-6402 > URL: https://issues.jboss.org/browse/WFLY-6402 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 10.0.0.Final > Reporter: Brad Maxwell > Assignee: Fedor Gavrilov > Labels: downstream_dependency > Attachments: auto-test-reproducer.zip > > > {code} > EJB 3.1 spec, section 4.8.1: > "If the Startup annotation appears on the Singleton bean class or if the Singleton has been designated via the deployment descriptor as requiring eager initialization, the container must initialize the Singleton bean instance during the application startup sequence. The container must initialize all such startup-time Singletons before any external client requests (that is, client requests originating outside of the application) are delivered to any enterprise bean components in the application. > {code} > Wildlfy does not implement this correctly, and allows calls to other EJBs before a @Startup @Singleton finishes its @PostConstruct call. > This Jira ticket handles two PR's on WFLY: > https://github.com/wildfly/wildfly/pull/8824 (that is already merged) > and https://github.com/wildfly/wildfly/pull/8989 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6402) EJBs accessible too early (spec violation)

by Brad Maxwell (JIRA)

[ https://issues.jboss.org/browse/WFLY-6402?page=com.atlassian.jira.plugin.... ] Brad Maxwell updated WFLY-6402: ------------------------------- Git Pull Request: https://github.com/wildfly/wildfly/pull/8824, https://github.com/wildfly/wildfly/pull/8989, https://github.com/wildfly/wildfly/pull/9009 (was: https://github.com/wildfly/wildfly/pull/8824, https://github.com/wildfly/wildfly/pull/8989) > EJBs accessible too early (spec violation) > ------------------------------------------ > > Key: WFLY-6402 > URL: https://issues.jboss.org/browse/WFLY-6402 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 10.0.0.Final > Reporter: Brad Maxwell > Assignee: Fedor Gavrilov > Labels: downstream_dependency > Attachments: auto-test-reproducer.zip > > > {code} > EJB 3.1 spec, section 4.8.1: > "If the Startup annotation appears on the Singleton bean class or if the Singleton has been designated via the deployment descriptor as requiring eager initialization, the container must initialize the Singleton bean instance during the application startup sequence. The container must initialize all such startup-time Singletons before any external client requests (that is, client requests originating outside of the application) are delivered to any enterprise bean components in the application. > {code} > Wildlfy does not implement this correctly, and allows calls to other EJBs before a @Startup @Singleton finishes its @PostConstruct call. > This Jira ticket handles two PR's on WFLY: > https://github.com/wildfly/wildfly/pull/8824 (that is already merged) > and https://github.com/wildfly/wildfly/pull/8989 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-234) Inconsistent synchronization in ConfigurationFile

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-234?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFCORE-234: ------------------------------------ Fix Version/s: 3.0.0.Alpha4 (was: 3.0.0.Alpha3) > Inconsistent synchronization in ConfigurationFile > ------------------------------------------------- > > Key: WFCORE-234 > URL: https://issues.jboss.org/browse/WFCORE-234 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 1.0.0.Alpha11 > Reporter: Brian Stansberry > Fix For: 3.0.0.Alpha4 > > > ConfigurationFile synchronizes on itself in some places and not in others. This may cause problems, particularly with the history dir. > The one that comes to mind is successfulBoot is synchronized, but all the methods called by ConfigurationFilePersistenceResource are not. The latter is called with the controller lock held, but the former is not. So there's a possibility of two threads interacting with the files concurrently if an operation executes immediately after boot. > The deployment scanner schedules such an op, so it's possible. Currently the schedule is for 200 ms after deployment-scanner add runs during boot. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-13) End users can call non-published management API operations

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-13?page=com.atlassian.jira.plugin.... ] Brian Stansberry updated WFCORE-13: ----------------------------------- Fix Version/s: 3.0.0.Alpha4 (was: 3.0.0.Alpha3) > End users can call non-published management API operations > ---------------------------------------------------------- > > Key: WFCORE-13 > URL: https://issues.jboss.org/browse/WFCORE-13 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Ladislav Thon > Labels: EAP > Fix For: 3.0.0.Alpha4 > > > It's not possible to call "non-published" operations (those that are not visible in the resource tree, e.g. {{describe}}) via JMX, while it's entirely possible to call them via CLI (e.g. {{/subsystem=security:describe}}) and other management interfaces. > The problem lies in the fact that {{ModelControllerMBeanHelper.invoke}} method checks {{if (!accessControl.isExecutableOperation(operationName))}} and the {{isExecutableOperation}} method assumes that the operation will be visible in the resource tree. In fact, there is a comment stating _should not happen_, but now we know that it indeed _can_ happen. > What's more, it gives a misleading error message. The {{isExecutableOperation}} returns {{false}} for unknown operations, which results in {{Not authorized to invoke operation}} message. Which is wrong in two different ways simultaneously: 1. the problem isn't authorization, but the fact that the operation can't be found; 2. the user (e.g. in the {{SuperUser}} role) _is_ authorized. > I'm considering this low priority, because 1. JMX is likely to be very rarely used to access the management interface, 2. hiding information isn't nearly as important as leaking them, 3. non-published operations aren't nearly as important as the published ones. It's worth a JIRA nevertheless. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 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 July 2016