[JBoss JIRA] (JGRP-2025) Counter enhancements
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2025?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2025:
---------------------------
Fix Version/s: 4.x
(was: 4.1)
> Counter enhancements
> --------------------
>
> Key: JGRP-2025
> URL: https://issues.jboss.org/browse/JGRP-2025
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.x
>
>
> * Add option to _not_ use a backup coordinator and instead run a reconciliation round on a view change in which the new coordinator asks everyone for their counter values. Perhaps use some simple timestamping mechanism to resolve conflicts
> * Add async operations, ie. returning {{CompletableFutures}}.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[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.x
(was: 4.1)
> 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.x
>
>
> 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
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (JGRP-2129) Schema generation fails on JDK9
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2129?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2129:
---------------------------
Fix Version/s: 4.x
(was: 4.1)
> Schema generation fails on JDK9
> -------------------------------
>
> Key: JGRP-2129
> URL: https://issues.jboss.org/browse/JGRP-2129
> Project: JGroups
> Issue Type: Task
> Reporter: Radoslav Husar
> Assignee: Bela Ban
> Priority: Minor
> Labels: jdk9
> Fix For: 4.x
>
>
> Not going to be a problem for a while until base is compiled with JDK9 by default, but just in case.
> {noformat}
> main:
> [mkdir] Created dir: /Users/rhusar/git/jgroups/target/schema
> [java] java.lang.ExceptionInInitializerError
> [java] at org.apache.tools.ant.taskdefs.ExecuteJava.execute(ExecuteJava.java:194)
> [java] at org.apache.tools.ant.taskdefs.Java.run(Java.java:771)
> [java] at org.apache.tools.ant.taskdefs.Java.executeJava(Java.java:221)
> [java] at org.apache.tools.ant.taskdefs.Java.executeJava(Java.java:135)
> [java] at org.apache.tools.ant.taskdefs.Java.execute(Java.java:108)
> [java] at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291)
> [java] at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native Method)
> [java] at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
> [java] at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)
> [java] at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:537)
> [java] at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
> [java] at org.apache.tools.ant.Task.perform(Task.java:348)
> [java] at org.apache.tools.ant.Target.execute(Target.java:390)
> [java] at org.apache.tools.ant.Target.performTasks(Target.java:411)
> [java] at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1399)
> [java] at org.apache.tools.ant.Project.executeTarget(Project.java:1368)
> [java] at org.apache.maven.plugin.antrun.AntRunMojo.execute(AntRunMojo.java:327)
> [java] at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
> [java] at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)
> [java] at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> [java] at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> [java] at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
> [java] at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
> [java] at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> [java] at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
> [java] at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
> [java] at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
> [java] at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
> [java] at org.apache.maven.cli.MavenCli.execute(MavenCli.java:863)
> [java] at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
> [java] at org.apache.maven.cli.MavenCli.main(MavenCli.java:199)
> [java] at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native Method)
> [java] at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
> [java] at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)
> [java] at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:537)
> [java] at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> [java] at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> [java] at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> [java] at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> [java] Caused by: java.lang.ExceptionInInitializerError
> [java] at org.jgroups.conf.ClassConfigurator.<clinit>(ClassConfigurator.java:56)
> [java] at org.jgroups.protocols.ASYM_ENCRYPT.<clinit>(ASYM_ENCRYPT.java:55)
> [java] at java.lang.Class.forName0(java.base@9-ea/Native Method)
> [java] at java.lang.Class.forName(java.base@9-ea/Class.java:291)
> [java] at org.jgroups.util.XMLSchemaGenerator.getClasses(XMLSchemaGenerator.java:127)
> [java] at org.jgroups.util.XMLSchemaGenerator.generateProtocolSchema(XMLSchemaGenerator.java:106)
> [java] at org.jgroups.util.XMLSchemaGenerator.main(XMLSchemaGenerator.java:80)
> [java] at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native Method)
> [java] at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
> [java] at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)
> [java] at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:537)
> [java] at org.apache.tools.ant.taskdefs.ExecuteJava.run(ExecuteJava.java:217)
> [java] at org.apache.tools.ant.taskdefs.ExecuteJava.execute(ExecuteJava.java:152)
> [java] ... 38 more
> [java] Caused by: java.lang.NullPointerException
> [java] at org.jgroups.conf.ClassConfigurator.init(ClassConfigurator.java:229)
> [java] at org.jgroups.conf.ClassConfigurator.<clinit>(ClassConfigurator.java:53)
> [java] ... 50 more
> [java] Java Result: -1
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (JGRP-1680) RDMA based transport
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1680?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1680:
---------------------------
Fix Version/s: 4.x
(was: 4.1)
> RDMA based transport
> --------------------
>
> Key: JGRP-1680
> URL: https://issues.jboss.org/browse/JGRP-1680
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.x
>
>
> Investigate whether an RDMA based transport makes sense.
> Advantages:
> * Speed, low latency (TCP/IP is bypassed entirely)
> * Low CPU usage
> Disadvantages:
> * JNI/C code
> ** Such a transport implementation would have to live outside of the JGroups repo
> ** Maintainability nightmare: the C code would also have to be ported to various OSes
> *** Investigate Java based libs (IBM's jVerbs) and C based libs (Apache Portable Runtime?)
> * High memory use, growing with cluster size: similarly to TCP, a 'group multicast' would involve N-1 sends. RDMA requires a Queue Pair (QP) for each destination. Each QP requires pinned memory (receive and send buffer), so each node would have to reserve (pin) N-1 memory buffers [1]
> ** OTOH, we may not use many group multicasts, e.g. with Infinispan's partial replication (DIST mode)
> * High cost of RDMA adapters, NICs and wiring: only a very small fraction of users would run such a transport.
> [1] http://www.hpcwire.com/hpcwire/2006-08-18/a_critique_of_rdma-1.html
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (JGRP-809) Copyless stack
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-809?page=com.atlassian.jira.plugin.s... ]
Bela Ban updated JGRP-809:
--------------------------
Fix Version/s: 4.x
(was: 4.1)
> Copyless stack
> --------------
>
> Key: JGRP-809
> URL: https://issues.jboss.org/browse/JGRP-809
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.x
>
> Attachments: Buf.java, BufAllocator.java, Message.java
>
>
> Currently (as of 2.7), the transport reads the contents of a received packet into a buffer, then passes a *copy* of the buffer to a thread from the OOB or incoming thread pools. To prevent this copy, we can
> - have the receiver read only the version and OOB flag (to see which thread pool to dispatch the packet to)
> - pass a ref to the socket to a thread from the incoming of OOB pool, have that thread read the packet and return
> - each thread in the pool has its own buffer into which the buffer is read from the socket
> Possibly use NIO: we can install a selector and get woken up whenever data to be read is present. At that point, we can pass the ref to the socket to the handler thread and return immediately. NIO with channels for multicast sockets is available only in JDK 7 (or 8?), so this is a bit off... However, we can already implement this with reading the version and flags bytes and then passing the socket to the handler
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (JGRP-815) Scatter/Gather to avoid copying
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-815?page=com.atlassian.jira.plugin.s... ]
Bela Ban updated JGRP-815:
--------------------------
Fix Version/s: 4.x
(was: 4.1)
> Scatter/Gather to avoid copying
> -------------------------------
>
> Key: JGRP-815
> URL: https://issues.jboss.org/browse/JGRP-815
> Project: JGroups
> Issue Type: Sub-task
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.x
>
> Attachments: bla10.java, bla9.java
>
>
> When we invoke Channel.send(), we pass a bufffer to JGroups. At the transport level, JGroups marshals the sender and destination address, plus all headers and the buffer into a new byte[] buffer, which is then passed to the socket (DatagramSocket, MulticastSocket, Socket).
> We cannot do gathering writes on a DatagramSocket because DatagramSocket doesn't expose this functionality, contrary to a DatagramChannel.
> We could avoid having to copy the user's buffer by using gathering writes: effectively passing to the socket NIO ByteBuffers containing:
> 1: Src and dest address plus flags, plus possibly size
> 2: The marshalled headers
> 3: The buffer passed to JGroups by the user
> We can obtain a gathering-write channel as follows:
> ByteBuffer[] buffers; // contains the 3 byte buffers above
> DatagramSocket sock;
> DatagramChannel ch=sock.getChannel();
> ch.write(buffers, 0, length); // length is the number of bytes of the total marshalled message
> This is supported by a GatheringByteChannel.
> I don't think there's currently a need to do scattered reads, but this needs to get investigated more. Also investigate whether MulticastSockets support gathering writes (whether they expose the correct DatagramChannel).
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFCORE-2670) list-add doesn't work for nested list of child attribute
by Harald Pehl (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2670?page=com.atlassian.jira.plugi... ]
Harald Pehl commented on WFCORE-2670:
-------------------------------------
[~brian.stansberry] can you give a rough estimate when this will be fixed. There's a HAL issue depending on this issue: JBEAP-10238.
I'm planing to release HAL for DR19 next Friday (2017-05-19). If we want to include this fix into DR19 we need some time ahead to apply the fix to HAL.
> list-add doesn't work for nested list of child attribute
> --------------------------------------------------------
>
> Key: WFCORE-2670
> URL: https://issues.jboss.org/browse/WFCORE-2670
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Claudio Miranda
> Assignee: Brian Stansberry
> Priority: Critical
>
> The list-add doesn't work for a child of an attribute as in the example below
> Add a dir-context first
> {code}
> /profile=full/subsystem=elytron/dir-context=dir2:add(url="ldap://test")
> {code}
> Add a ldap-realm
> {code}
> /profile=full/subsystem=elytron/ldap-realm=foobar2:add(dir-context=dir2,identity-mapping={rdn-identifier=test})
> {
> "outcome" => "success",
> "result" => undefined,
> "server-groups" => {"main-server-group" => {"host" => {"master" => {"server-one" => {"response" => {
> "outcome" => "success",
> "response-headers" => {"process-state" => "reload-required"}
> }}}}}}
> }
> {code}
> This is the command to add the item to the list
> {code}
> /profile=full/subsystem=elytron/ldap-realm=foobar2:list-add(name=identity-mapping.new-identity-attributes,value={name=key2,value=["val1","val2"]})
> {
> "outcome" => "failed",
> "result" => undefined,
> "server-groups" => undefined,
> "rolled-back" => true
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months