[{"_1":2,"_155":-5,"_156":-5},"loaderData",{"_3":4,"_13":14,"_21":22,"_134":135},"root",{"_5":-5,"_6":-7,"_7":8,"_9":-7,"_10":11,"_12":-7},"currentUser","primaryEmail","siteVerification","6LeIxAcTAAAAAJcZVRqyHh71UMIEGNQ_MXjiZKhI","toast","enableDev",false,"incidentStatus","routes/_layout",{"_15":-5,"_16":17,"_18":17,"_19":11,"_20":11},"username","isAskGordonEnabled",true,"isUsingNewTemplate","showMinimalLanding","showHoneypotTrap","routes/_layout.r.$namespace.$reponame",{"_23":24,"_25":-5,"_26":11,"_27":11,"_28":29,"_30":31,"_32":-5,"_33":11,"_34":35,"_84":-5,"_85":86,"_125":-5,"_126":11,"_127":17,"_128":11,"_129":-5,"_130":11,"_131":-5,"_132":133},"canonicalUrl","https://hub.docker.com/r/belaban/jgroups-docker/tags","mcpServer","canSeeDockerfile","canSeeAutobuilds","namespace","belaban","reponame","jgroups-docker","cloudBuildSource","isAutobuildsAvailable","repo",{"_36":37,"_38":39,"_41":42,"_43":44,"_45":11,"_46":47,"_48":49,"_50":51,"_53":31,"_28":29,"_54":55,"_56":40,"_57":58,"_59":60,"_61":62,"_63":-5,"_64":58,"_65":66,"_67":11,"_68":29,"_69":70,"_75":17,"_76":77,"_81":29,"_82":83},"categories",[],"content_types",[40],"image","date_registered","2016-10-26T11:50:04.420419Z","description","JGroups demo","is_private","last_updated","2018-12-03T13:35:40.684928Z","last_modified","2024-10-16T13:48:34.145251Z","media_types",[52],"application/vnd.docker.container.image.v1+json","name","pull_count",469,"repository_type","star_count",0,"status",1,"status_description","active","source","collaborator_count","full_description","\n\n= JGroups and Docker\n:author: Bela Ban belaban@yahoo.com\n#:backend: deckjs\n#:deckjs_transition: fade\n:navigation:\n:deckjs_theme: web-2.0\n:deckjs_transition: fade\n:goto:\n:menu:\n:toc:\n:status:\n\n\n== Overview\nThis document describes how to use JGroups in Docker containers to form clusters locally,\non Amazon Web Services (AWS) and in the Google cloud (Google Compute Platform, GCP).\n\nThe advantage of running Docker images in the cloud, rather than cloud-specific images is that the Docker\nimages are the same across different clouds, whereas cloud images are always specific to a given cloud.\n\nThe predefined docker image we'll use is https://hub.docker.com/r/belaban/jgroups. It contains a number\nof interactive <>, ie. demos which require a TTY.\n\nThe difference between running locally, or running in a cloud lies in the JGroups configuration and the Docker\nstartup options. Clouds generally do not support IP multicasting, so JGroups applications have to resort to\nTCP rather than UDP as transport. Plus, PING cannot be used and has to be replaced with different discovery protocols,\ne.g. S3_PING or GOOGLE_PING.\n\n=== Bridged and host network\n\nDocker supports `none`, `bridge` and `host` networks out of the box (https://docs.docker.com/engine/userguide/networking).\nWhich type of network is used is defined by the `--network` option, e.g. `--network=host`.\n\nNetwork `none` has no communication to the outside world and is used purely for Docker containers running on the same\nbox. The bind address used is usually `127.0.0.1` (loopback) here.\n\n\n=== Bridge network\nNetwork `bridge` is the default and creates a virtual interface in the container that's not available on the host. To\nbe able to communicate with other Docker containers on other hosts, the _host's_ IP address has to be used (e.g. using\n`external_addr=`, or by switching to `--network=host` (see below).\n\nFor instance, starting an AWS EC2 instance, `ifconfig` executed on the host shows the following interfaces:\n\n```\n[ec2-user@ip-172-31-14-130 ~]$ ifconfig\ndocker0 Link encap:Ethernet HWaddr 02:42:33:C7:8E:F1\n inet addr:172.17.0.1 Bcast:0.0.0.0 Mask:255.255.0.0\n inet6 addr: fe80::42:33ff:fec7:8ef1/64 Scope:Link\n UP BROADCAST MULTICAST MTU:1500 Metric:1\n RX packets:22 errors:0 dropped:0 overruns:0 frame:0\n TX packets:20 errors:0 dropped:0 overruns:0 carrier:0\n collisions:0 txqueuelen:0\n RX bytes:1342 (1.3 KiB) TX bytes:1492 (1.4 KiB)\n\neth0 Link encap:Ethernet HWaddr 0E:C8:A1:0F:39:E6\n inet addr:172.31.14.130 Bcast:172.31.15.255 Mask:255.255.240.0\n inet6 addr: fe80::cc8:a1ff:fe0f:39e6/64 Scope:Link\n UP BROADCAST RUNNING MULTICAST MTU:9001 Metric:1\n RX packets:105050 errors:0 dropped:0 overruns:0 frame:0\n TX packets:37021 errors:0 dropped:0 overruns:0 carrier:0\n collisions:0 txqueuelen:1000\n RX bytes:117948327 (112.4 MiB) TX bytes:6929186 (6.6 MiB)\n...\n```\n\nThe `docker0` interface is created by Docker to implement the bridged network. This is the interface that will be used\nby the Docker container. Note that `eth0` is the host's interface, with a routable `172.31.14.130` IP address.\n\nWhen starting a container with bridged networking (default):\n\n`docker run -it -p 7800:7800 --rm belaban/jgroups`, `ifconfig` executed in the container shows:\n\n```\nbash-4.3$ ifconfig\neth0 Link encap:Ethernet HWaddr 02:42:AC:11:00:02\n inet addr:172.17.0.2 Bcast:0.0.0.0 Mask:255.255.0.0\n inet6 addr: fe80::42:acff:fe11:2%32571/64 Scope:Link\n UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1\n RX packets:6 errors:0 dropped:0 overruns:0 frame:0\n TX packets:3 errors:0 dropped:0 overruns:0 carrier:0\n collisions:0 txqueuelen:0\n RX bytes:508 (508.0 B) TX bytes:258 (258.0 B)\n...\n```\n\nThe `172.17.0.2` address is assigned by Docker from the `docker0` interface.\n\nThe issue with these Docker-private addresses is that they cannot be used to talk between AWS instances, as they are not\nrouted. For instances to talk to each other, the host's `eth0` has to be used (from the `172.31.0.0` subnet).\n\nTo do this, JGroups has an attribute `external_addr` in the transport. In a configuration, the following transport\nsnippet would enable JGroups applications in network-bridged Docker containers to communicate:\n\n[source,xml]\n----\n\n----\n\nThis means that JGroups will bind to `eth0` (`172.17.0.2`), but advertize its address as `172.31.14.130`, so\nother instances can talk to the instance.\n\nHow to find out the hosts address is implementation-dependent;\nin AWS `curl http://169.254.169.254/latest/meta-data/local-ipv4` returns the IP address of the EC2 instance.\n\nAn alternative is to grab the IP address before starting the Docker container and pass it to the container as an\nenvironment variable (e.g. `-e EXT-ADDR=1.2.3.4`). The container's entrypoint could then start JGroups by passing\nsystem property `-Dext-addr=1.2.3.4` which will set `external_addr` in TCP.\n\n==== Host network\nThe `host` network is started as follows:\n\n`docker run --network=host -it -p 7800:7800 --rm belaban/jgroups`.\n\nThis means that the started container has access to the same interfaces as present on the host. This can be confirmed\nby executing `ifconfig` inside the container:\n\n```\nbash-4.3$ ifconfig\ndocker0 Link encap:Ethernet HWaddr 02:42:33:C7:8E:F1\n inet addr:172.17.0.1 Bcast:0.0.0.0 Mask:255.255.0.0\n inet6 addr: fe80::42:33ff:fec7:8ef1%32692/64 Scope:Link\n UP BROADCAST MULTICAST MTU:1500 Metric:1\n RX packets:30 errors:0 dropped:0 overruns:0 frame:0\n TX packets:20 errors:0 dropped:0 overruns:0 carrier:0\n collisions:0 txqueuelen:0\n RX bytes:1878 (1.8 KiB) TX bytes:1492 (1.4 KiB)\n\neth0 Link encap:Ethernet HWaddr 0E:C8:A1:0F:39:E6\n inet addr:172.31.14.130 Bcast:172.31.15.255 Mask:255.255.240.0\n inet6 addr: fe80::cc8:a1ff:fe0f:39e6%32692/64 Scope:Link\n UP BROADCAST RUNNING MULTICAST MTU:9001 Metric:1\n RX packets:192724 errors:0 dropped:0 overruns:0 frame:0\n TX packets:128453 errors:0 dropped:0 overruns:0 carrier:0\n collisions:0 txqueuelen:1000\n RX bytes:138976219 (132.5 MiB) TX bytes:27369702 (26.1 MiB)\n...\n```\n\nAs can be seen, the interfaces are the same as the host's interfaces. This means that the JGroups configuration doesn't\nrequire an `external_addr` attribute and can simply define `bind_addr`:\n[source,xml]\n----\n\n----\n\nThis will bind the transport's sockets to `172.31.14.130`.\n\n\n==== Bridged versus host networking\nIt is simpler to use host networks as they don't require NATing between addresses (no `external_addr`). However, in\nsome cases, this may not be available, when automatically launching containers via AWS Beanstalk.\n\n\n== Running containers locally\nThe JGroups demos can be run as multiple containers forming a cluster on the same local box (in bridged or host network\nmode), or across boxes in the local network (in host network).\n\nTo run containers locally, the configuration used by JGroups uses IP multicasting,\nas shown in `./conf/udp.xml` (abridged):\n\n[source,xml]\n----\n\n \n\n \n \n \n \n \n \n \n \n \n \n \n\n----\n\nThis configuration uses IP multicasting (`UDP` as transport) and multicast discovery (`PING` as discovery protocol).\nIt binds to `eth0` if found, if not tries to bind to `en0` (Macs), then tries to find a site local IP address, and\nfalls back to lookback (`127.0.0.1`) if all preceding addresses didn't match.\n\nRun multiple container as follows:\n\n docker run -it --rm --network=host belaban/jgroups\n\nIn the container, there's a readme which describes how to run the demos, e.g. Chat. Also see <> below for details\non the demos. To run the Chat demo, run\n\n # udp.xml is the default so -props can be omitted\n chat.sh -props udp.xml -name A\n\nThis should create a cluster of Chat nodes, even across hosts due to `--network=host`.\n\nIf IP multicasting is not supported, one can always fall back to TCP, but this means copying `tcp.xml` (for example)\nfrom the JGroups distribution into the Docker container and modifying it (e.g. change the discovery protocol). The\nJGroups manual at http://www.jgroups.org/manual4/index.html shows how to do this.\n\n\n== Amazon Web Services (AWS)\n\nThis section shows how to run Docker containers with the JGroups demo on AWS. Contrary to running locally, we have\nto use a security policy to define which traffic (TCP/UDP/ICMP) to send/receive on which ports.\n\nNOTE: Alternative ways of running JGroups in AWS include (1) creating/customizing an EC2 image and then running a host\nwith the image directly (without docker), or (2) using https://aws.amazon.com/ecs[EC2 Container Service (ECS)],\nwhich runs docker images on a number of EC2 instances. +\nThe reason (1) is not discussed here is lazyness :-) I did not want to go through the rather long turnaround times\nof iteratively creating and customizing an AMI. Instead, creating and customizing a docker image and running/testing it\nlocally made for much faster turnaround times! +\nRunning on ECS (option 2) is similar to what's described here, except that there's no need to spin up EC2 instances\nmanually, as this is done by ECS when defining a cluster.\n\nSince IP multicasting is not supported, we also have to switch to TCP as transport and also change the discovery\nprotocol (see <> below).\n\nFinally, if we use S3 for discovery, this requires an IAM role assigned to the container that permits creation,\ndeletion, reading and writing of S3 buckets. These topics are discussed below.\n\nThe Amazon image used for running the demo contains a bare bones Linux plus the Docker software: `ami-92659c84`.\nSearch for `amazon-ecs-optimized` to find it. Of course, any other AMI that contains Docker can be used.\n\nFirst, an EC2 instance is created with this AMI, then we need to ssh into it and start the Docker container.\n\n\n=== Security policy\nThe security policy used for the demo permits all traffic from any protocol on any port and from/to any address. This\nis fine for a demo, but of course not recommended for production.\n\nAlternatively, using _no_ security group is the same as above.\n\nThe selected security policy needs to be associated with the EC2 instance when it is started.\n\n\n=== IAM security role to access S3\nIf S3 (e.g. `S3_PING` or `NATIVE_S3_PING`) is used for discovery in the JGroups configuration, then the EC2 instance\nneeds to be started with a role that permits access to S3 buckets, specifically creation of buckets, reading objects\nfrom buckets and writing objects to buckets (deletion is currently not used).\n\nThe role that I used for the demo was `AmazonS3FullAccess` which (as its name suggests) has all permissions regarding\nS3 buckets.\n\n\n[[AWS_Discovery]]\n=== Discovery\n\nThe task of discovery is for a new cluster node to find the coordinator of the cluster to join, and send it a join\nrequest. Whereas `PING` sends a multicast and everyone responds with the coordinator's address and information about\nthemselves, this cannot be done in a cloud where IP multicasting usually isn't supported.\n\nTherefore, we have to resort to other ways of running discovery. They're discussed in the following sections.\n\n[[NATIVE_S3_PING]]\n==== NATIVE_S3_PING\n\nNATIVE_S3_PING is a separate protocol developed at https://github.com/jgroups-extras/native-s3-ping. It uses the\nAmazon S3 Java SDK to access buckets in S3 which store information about cluster members.\n\nThe advantage over link:http://www.jgroups.org/manual4/index.html#_s3_ping[S3_PING] is that no credentials\n(`AWS_ACCESS_KEY`, `AWS_SECRET_ACCESS_KEY`) needs to be passed to the EC2 instance on startup, but rather the\ncredentials of the user which started the EC2 instance are used.\n\nThere's a configuration `./conf/aws.xml` which includes this protocol:\n\n[source,xml]\n----\n\n \n \n \n \n \n \n \n \n \n \n \n \n \n\n----\n\nAttributes `bind_addr` and `external_addr` were discussed above. Note that the latter is not required if the Docker\ncontainer is started with `--network=host`.\n\nThe attributes used by `NATIVE_S3_PING` are `region_name` and `bucket_name`. The latter defines the bucket that will\nbe used to store information about the members of this cluster. All objects created in this bucket are prefixed by\nthe cluster name (\"draw\" in the example), e.g. `mybucket/draw-126532-A.list`. The former defines the region in which\nthe bucket is located.\n\nNOTE: If a bucket doesn't exist, a new one will be created. Since bucket names have a global name space, a bucket that\nalready exists for a different user will throw an exception. It is therefore recommended to create a bucket up-front\nand use it as `bucket_name`.\n\nBoth region and bucket can be overridden by passing system properties `S3_REGION` and `S3_BUCKET_NAME` to the JGroups\ndemo. Similar to passing `ext-addr` (see above), the docker container could be started with two environment variables\nfor region and bucket name and they could then be read from the environment by a script that passes them as env vars\nto the demo.\n\n\n==== S3_PING\n`S3_PING` is discussed in the JGroups manual at http://www.jgroups.org/manual4/index.html#_s3_ping.\n\n==== TCPGOSSIP and GossipRouter\nlink:http://www.jgroups.org/manual4/index.html#TCPGOSSIP_Prot[TCPGOSSIP] is a discovery protocol which stores\ninformation about cluster nodes in one or more `GossipRouters`, which are separate processes acting as lookup services.\nThe configuration of `TCPGOSSIP` needs to include the addresses of the GossipRouters, e.g.:\n\n[source,xml]\n----\n\n\n----\n\nThis means that there are GossipRouters running on `GR1` and `GR2` at port `12001`, and `TCPGOSSIP` will register\neach member with both processes.\n\nThe GossipRouter processes can be started inside Docker container, too, e.g. using the image available at\nhttps://hub.docker.com/r/jboss/jgroups-gossip.\n\n\n==== TCPPING\nlink:http://www.jgroups.org/manual4/index.html#TCPPING_Prot[TCPPING] lists all cluster nodes in a static list, e.g.\n\n[source,xml]\n----\n\n\n----\n\nThe problem here is that the IP addresses of `HostA`, `HostB`, etc have to be known before starting any of the EC2\ninstances. This requires either fixed addresses, or addresses mapped to a DNS service, e.g. Amazon Route 53.\n\nAn alternative is to use AWS Elastic IP addresses, where the address of each cluster node is fixed and all of the\npotential members of the cluster are known ahead of starting the cluster.\n\nAnother alternative is to create a Virtual Private Network (VPC), e.g. `172.45.0.0` and assign addresses from\nblock `172.45.0.1` - `172.45.0.100`. This means that `TCPPING.initial_hosts` needs to have all 100 members of this\nblock listed.\n\n==== Elastic File System (EFS) and FILE_PING\n\nAnother way to run discovery on AWS is https://aws.amazon.com/efs/[Elastic File System (EFS)]. EFS is a distributed file\nsystem, accessible by all cluster nodes. Any creation of modification of a file by a cluster member is visible by\nevery other member.\n\nhttp://www.jgroups.org/manual4/index.html#FILE_PING[FILE_PING] can therefore be used for discovery; the `location`\nattribute needs to point to a directory mounted by EFS. Reads and writes are performed by EFS.\n\n\n==== JDBC_PING / RDS\n\nhttp://www.jgroups.org/manual4/index.html#_jdbc_ping[JDBC_PING] uses a table in a database for discovery. In\nconjunction with https://aws.amazon.com/rds[RDS], `JDBC_PING` can be setup to store information in an RDS table.\n\n\n\n\n\n=== Running the Docker containers on EC2\nAfter spinning up an EC2 instance, we're now ready to run the Docker container with image `belaban/jgroups`.\n\nThe JGroups configuration in the Docker image is `./conf/aws.xml`, listed in <>. It requires\nports 7800 (used by TCP) and 9000 (used by FD_SOCK) to be published; therefore the command to start the container is:\n\n docker run -it --rm --network=host -p 7800:7800 -p 9000:9000 belaban/jgroups\n\n* `-it`: starts an interactive shell (TTY) so we can interact with (e.g.) the Chat demo\n* `--rm`: removes the container when done\n* `--network=host`: picks a `host` network. If omitted, a `bridge` network would be picked by default\n* `-p 7800:7800 -p 9000:9000`: publishes ports `7800` to `7800` and `9000` to `9000`.\n* `belaban/jgroups`: the Docker images hosted on dockerhub.com\n\nNOTE: When using a `host` network, publishing the ports is not necessary, therefore the `-p 7800:7800 -p 9000:9000`\noption can be omitted.\n\nWhen the Docker container has been started, the entrypoint (`/bin/bash`) shows a readme which explains how to start the\ndemos. To for example run Chat, the following command has to be executed:\n\n chat.sh -props aws.xml -name A -b bucket-name\n\n* `-props aws.xml`: this instructs Chat to use `aws.xml` (described above) as configuration\n* `-name A`: gives each cluster node a unique name. If omitted, a random name will be picked\n* `-b bucket-name`: the name of the S3 bucket. Will be created if it doesn't exist. Note that an exception will be\n thrown if that name is already in use by a different project.\n\n\n\n\n== Google Compute Platform (GCP)\n\nThere is a separate project https://github.com/jgroups-extras/jgroups-google[jgroups-google] which uses Google\nCloud Storage for discovery, and provides `GOOGLE_PING2` as discovery protocol.\n\nIt is meant to be used with Google Compute Engine nodes that are started manually. To\nrun JGroups in Google Container Engine (GKE), which uses Kubernetes under the covers, we recommend to use\n`KUBE_PING` instead.\n\nRefer to http://belaban.blogspot.ch/2017/05/running-infinispan-cluster-with.html for step-by-step instructions on\nhow to run a JGroups cluster on GKE.\n\n\n[[demos]]\n== Demos\n\nTo run the image directly, execute\n\n docker run -it --rm --network=host belaban/jgroups\n\nor\n\n docker run -p 7800:7800 -p 9000:9000 -it --rm belaban/jgroups\n\n\nTo build the image, run\n\n docker build .\n\n\nThe demos are described below. The idea is to run the demo apps in a\ncontainer each *on the same host* and they will form a cluster.\n\n\n=== Chat\nTo run it:\n\n chat [-props config] [-name name] [-b bucketname], e.g. chat -props ./udp.xml -name A\n\nRun the Chat application in multiple containers on the same host and they will form a cluster.\nTyping a message into one Chat will send it to all other chats\n\n\n=== Distributed locks\n\nDistributed locks are implementations of `java.util.concurrent.locks.Lock` and provide locks that can be\naccessed from all nodes in a cluster. \n\nA typical use case is to lock a resource so that only 1 thread in a given node in the cluster can access it.\nShould a node crash while holding a lock, the lock is released immediately.\n\nFor more details, see the section on distributed locks at http://www.jgroups.org/manual/index.html#LockService.\n\nTo run the lock demo, type:\n\n lock [-name name]\n\nTyping `help` into the shell shows a few commands:\n\n [jgroups@b21d0fa6c79d ~]$ lock -name A\n\n -------------------------------------------------------------------\n GMS: address=A, cluster=lock-cluster, physical address=172.17.0.178:52519\n -------------------------------------------------------------------\n : help\n\n LockServiceDemo [-props properties] [-name name]\n Valid commands:\n lock ()+\n unlock ( | \"ALL\")+\n trylock ()+ []\n\n Example:\n lock lock lock2 lock3\n unlock all\n trylock bela michelle 300\n :\n\nIf you start instances A and B, you can try out the following:\n\n1. A: `lock printer`\n2. B: `lock printer` // will block\n3. A: `unlock printer` // now B will get the lock\n\nOr a lock holder can be killed:\n\n1. A: `lock printer`\n2. B: `lock printer`\n3. Kill A. B will now get the lock on \"printer\"\n\n \n\n\n\n=== Distributed counters\n\nDistributed counters are counters will can be atomically incremented,\ndecremented, compare-and-set etc *across a cluster*.\n\nTo run the demo:\n\n count [-name name]\n\nRun multiple instances in different containers. The demo uses a\ncounter named \"mycounter\" and there's a command prompt which shows the\ncommands to be executed.\n\n\nQuestions can be asked on the users or dev mailing lists:\nhttps://sourceforge.net/p/javagroups/mailman.\n\nEnjoy !\n\nBela Ban\n\n\n","has_starred","hub_user","immutable_tags_settings",{"_71":11,"_72":73},"enabled","rules",[74],".*","is_automated","permissions",{"_78":17,"_79":11,"_80":11},"read","write","admin","user","storage_size",2182500434,"orgData","recentTags",[87],{"_88":40,"_89":90,"_91":92,"_93":94,"_95":96,"_46":114,"_115":90,"_116":29,"_117":52,"_53":118,"_119":120,"_121":105,"_122":114,"_123":62,"_124":17},"content_type","creator",57154,"full_size",139150923,"id",8020324,"images",[97],{"_98":99,"_100":101,"_102":103,"_104":105,"_106":107,"_108":109,"_110":103,"_111":-5,"_112":92,"_59":62,"_113":-5},"architecture","amd64","digest","sha256:bfeed0d9c0c7c30c85cbd219fe287f4afc49ead375ef141400fc45a85281dfce","features","","last_pulled","2026-09-24T08:01:09.086993032Z","last_pushed","2018-12-03T13:35:41Z","os","linux","os_features","os_version","size","variant","2018-12-03T13:35:40.136799Z","last_updater","last_updater_username","media_type","latest","repository",1005747,"tag_last_pulled","tag_last_pushed","tag_status","v2","sbxKitMetadata","isPotentialSpam","isHubSbxKitsEnabled","showSbxLogoOverride","sbxTrademarkText","displaySecurityMetadata","tagAttestations","tagsHaveAttestations",[],"routes/_layout.r.$namespace.$reponame.tags",{"_34":136,"_143":144,"_132":153,"_154":11},{"_36":137,"_38":138,"_41":42,"_43":44,"_45":11,"_46":47,"_48":49,"_50":139,"_53":31,"_28":29,"_54":55,"_56":40,"_57":58,"_59":60,"_61":62,"_63":-5,"_64":58,"_65":66,"_67":11,"_68":29,"_69":140,"_75":17,"_76":142,"_81":29,"_82":83},[],[40],[52],{"_71":11,"_72":141},[74],{"_78":17,"_79":11,"_80":11},"tags",{"_145":60,"_146":-5,"_147":-5,"_148":149},"count","next","previous","results",[150],{"_88":40,"_89":90,"_91":92,"_93":94,"_95":151,"_46":114,"_115":90,"_116":29,"_117":52,"_53":118,"_119":120,"_121":105,"_122":114,"_123":62,"_124":17},[152],{"_98":99,"_100":101,"_102":103,"_104":105,"_106":107,"_108":109,"_110":103,"_111":-5,"_112":92,"_59":62,"_113":-5},[],"canDeleteTags","actionData","errors"]

belaban/jgroups-docker

Tags for belaban/jgroups-docker