JGroups 2.8.0.GA released

Discussions

News: JGroups 2.8.0.GA released

  1. JGroups 2.8.0.GA released (32 messages)

    JGroups 2.8.0.GA has been released. It is a reliable cluster transport, used by many open source and commercial products as communication bus. It features an extensible protocol stack, including protocols for fragmentation, retransmission, ordering, compression, flow control, encryption, authentication, message batching, membership and JOIN/LEAVE notifications. Besides bug fixes and performance enhancements, 2.8.0.GA features logical addresses and names, a new merge algorithm, improved IPv6 support, new discovery protocols (FILE_PING and S3_PING) to better support running on EC2, a major GossipRouter overhaul, a revised and improved UNICAST protocol and more extensible logging support. Details can be found at http://belaban.blogspot.com/2009/12/jgroups-280ga-released.html Message was edited by: staff

    Threaded Messages (32)

  2. Re: JGroups 2.8.0.GA released[ Go to top ]

    Congratulations Bela and the team!
  3. Re: JGroups 2.8.0.GA released[ Go to top ]

    Every time I looked at JGropus (3 times) I was very disappointed, so much that I always end with filling I will never look at it again (but still did it again twice :( ). Last time I checked I saw same old antique API full with not obvious and not needed stuff and bugs (distributed lock manager is not usable at all, fails any real test). So, I will definitely never waste my time and look at JGroups. If you want free Java cluster software, look at Hazelcast. It is not free Coherence, but probably the best you can get for free.
  4. Re: JGroups 2.8.0.GA released[ Go to top ]

    Every time I looked at JGropus (3 times) I was very disappointed, so much that I always end with filling I will never look at it again (but still did it again twice :( ).

    Last time I checked I saw same old antique API full with not obvious and not needed stuff and bugs (distributed lock manager is not usable at all, fails any real test).

    So, I will definitely never waste my time and look at JGroups.

    If you want free Java cluster software, look at Hazelcast. It is not free Coherence, but probably the best you can get for free.
    Last time I checked (I could be wrong), Hazel is based on synchronous implementation (no-scalable, asynch protocol), so I think you are just to impressed with its nice looking API. The interpretation of why JGroups is kept at such low level is that if you are developer who needs to use it, you are already skilled enough to not care about not-so-nice API.
  5. Re: JGroups 2.8.0.GA released[ Go to top ]

    Also, as it has been already said somewhere on this site, JGroups is group membership library, not caching solution, hence not comparable with Coherence. Look at Infinispan if you want open source caching solution.
  6. Re: JGroups 2.8.0.GA released[ Go to top ]

    Here is the link: http://www.jboss.org/infinispan
  7. Re: JGroups 2.8.0.GA released[ Go to top ]

    Also, as it has been already said somewhere on this site, JGroups is group membership library, not caching solution, hence not comparable with Coherence. Look at Infinispan if you want open source caching solution.
    2+ MB of Java compiled code for group membership library? You must be kidding?
  8. Re: JGroups 2.8.0.GA released[ Go to top ]

    2+ MB of Java compiled code for group membership library?You must be kidding?
    Well no. Because, it is library, and library provides multiple algorithms all with different guarantees and properties, since, guess what, there is no single membership protocol that satisfies all requirements. Just like Java SE provides multiple implementations for Map API, so does JGroups for membership domain.
  9. Re: JGroups 2.8.0.GA released[ Go to top ]

    1.3MB with the unit tests and demos removed. JGroups is not just membership (if you've read my post), it provides: - retransmission (needed e.g. over UDP) - fragmentation - ordering - flow control - encryption, authentication - compression - message batching - Cluster RPC and so on If you just include the classes you need in a normal application, you'd probably be able to strip the JAR down to 300K.
  10. JGroups compared to Coherence[ Go to top ]

    Also, as it has been already said somewhere on this site, JGroups is group membership library, not caching solution, hence not comparable with Coherence. Look at Infinispan if you want open source caching solution.
    Coherence has an asynch group communication protocol under it called TCMP. It supports group membership with very high throughput (e.g. up to 25 gigabits per server per second in some Infiniband tests we were doing recently) and low latency (e.g. typically sub-millisecond round-trip times for small messages). Bela's architecture with JGroups is definitely much more flexible for experimenting with protocols and options. If you look at the available protocol combinations, it's pretty rich. Also, there's plenty of use of JGroups in the industry. I'm pretty sure that having several good options (i.e. more even than what is covered here) available has made Java the leading platform for building large-scale distributed systems. Peace, Cameron Purdy | Oracle Coherence http://coherence.oracle.com/
  11. Re: JGroups 2.8.0.GA released[ Go to top ]

    The interpretation of why JGroups is kept at such low level is that if you are developer who needs to use it, you are already skilled enough to not care about not-so-nice API.
    Not so nice API is the smell of bad design. Not so nice API today is somewhat like being rude, wasting the time of the users. Its year 2010, not 2000.
  12. Re: JGroups 2.8.0.GA released[ Go to top ]

    Not so nice API is the smell of bad design. Not so nice API today is somewhat like being rude, wasting the time of the users. Its year 2010, not 2000.
    Well we gotta differentiate between: -average Joe business application developer (API must be as simple as possible, such as JPA, JDBC) -technically savvy engineers (preffers working tools over shiny non-working) Average Joe developer will never have need to look at low level libraries such as JGroups, nor he should, so thats why you buy product/support from vendor that prepackages such tools. Speaking openly, if you are engineer, noone is going to do work for you. If you have need to look at JGroups, it is assumed you are skilled enough to not be bothered with API, which in my opinion, is not bad at all (simple messaging model).
  13. Re: JGroups 2.8.0.GA released[ Go to top ]

    Not so nice API is the smell of bad design. Not so nice API today is somewhat like being rude, wasting the time of the users. Its year 2010, not 2000.


    Well we gotta differentiate between:
    -average Joe business application developer (API must be as simple as possible, such as JPA, JDBC)
    -technically savvy engineers (preffers working tools over shiny non-working)

    Average Joe developer will never have need to look at low level libraries such as JGroups, nor he should, so thats why you buy product/support from vendor that prepackages such tools. Speaking openly, if you are engineer, noone is going to do work for you.

    If you have need to look at JGroups, it is assumed you are skilled enough to not be bothered with API, which in my opinion, is not bad at all (simple messaging model).
    As one of the developers who started to look at jgroups and turned to hazelcast, I can say: if you really want to impress anyone, then create an API that is for the average Joe too. I've checked both the internals of JGroups and Hazelcast, and neither one is nice or clean code, however the public API of Hazelcast just works for the average developer -> therefore it will win, no matter how good your low-level API is. Making it an either-or choice will be a dead end...
  14. Re: JGroups 2.8.0.GA released[ Go to top ]

    As one of the developers who started to look at jgroups and turned to hazelcast
    You're comparing apples and oranges ! This sounds like "I started to look into TCP/IP, but then turned to Emacs" :-)
    If you really want to impress anyone, then create an API that is for the average Joe too
    What's bad about the JGroups API ? Create, connect, send, receive, disconnect, close. That's it. Simple and clean, and similar to the sockets API. I claim the JChannel API *is* actually very much for the average Joe programmer !
  15. Re: JGroups 2.8.0.GA released[ Go to top ]

    Hi Bela, I appreciate your personal involvement in the thread, and please read my comments as a 'feature request' :)
    As one of the developers who started to look at jgroups and turned to hazelcast


    You're comparing apples and oranges ! This sounds like "I started to look into TCP/IP, but then turned to Emacs" :-)
    My use of Hazelcast is really around the group membership / notification / group messaging + the lock API. I tried the distributed collections, but I do not need them at the moment. So what I need: a simple, easy-to-use group messaging, with the ability to join to a cluster in a few commands, register async event listener, then do my domain use. And in that regard, Hazelcast was _much_ easier, straightforward and user-friendly. And yes, I've noticed the serialized nature of Hazelcast, but on the other hand, it really simplifies a lot in the group administratorship - so as long it is not a bottleneck, it is just fine, and to be honest, I think that around 10-20 members with only cluster membership events, it is not a hard limitation.




    If you really want to impress anyone, then create an API that is for the average Joe too

    What's bad about the JGroups API ? Create, connect, send, receive, disconnect, close. That's it. Simple and clean, and similar to the sockets API.

    I claim the JChannel API *is* actually very much for the average Joe programmer !
    I understand that because you are familiar with the codes, your concept of the channel and the low-level API, it seems to be easy, however it is not easy for everyone, and speaking for myself, I do not need that much internal details. I need the logical notation of groups, the logical notation of communication, without the need to specify the details. JGroups big advantage could be such an API with the ability to go to low-level - if required. Regards, Istvan
  16. Re: JGroups 2.8.0.GA released[ Go to top ]

    Hi Istvan, I appreciate feature requests, but please be specific: what is not good about the API ? The following is used to join a cluster, send a message and receive messages and membership changes (edited for brevity): class MyReceiver extends ReceiverAdapter { public void receive(Message msg) { System.out.println("received " + msg.getObject() + " from " + msg.getSrc()); } public void viewAccepted(View view) { System.out.println("view=" + view); } } JChannel ch=new JChannel("udp.xml"); ch.setReceiver(new MyReceiver()); ch.connect("myCluster"); ch.send(null, null, "merry christmas everyone"); ... // more work, etc, later: ch.close(); I fail to see what's complicated about this. Actually, if you compare this to JMS and subscribing to a topic, and posting to it, this is probably 30% of the code needed to do the same with JMS ! Please show how Hazelcast's API is simpler to use. I actually looked at Hazelcast's API, and I'd venture to day that it is similar to the above code. BTW: I know Talip (who wrote Hazelcast), he's a nice guy and I wish him all the success with Hazelcast. But Hazelcast and JGroups are really quite different beasts, you cannot compare them !
  17. Re: JGroups 2.8.0.GA released[ Go to top ]

    Bela, Thanks for the example, I think I shall re-evaluate JGroups again. Regards, Istvan
  18. Re: JGroups 2.8.0.GA released[ Go to top ]

    Cool, let us know if you have any questions; we're pretty responsive on the mailing lists ! Cheers,
  19. The API is fine![ Go to top ]

    Just thought i'd post my 2 cents worth. I first tried programming with JGroups about 2 or 3 weeks ago, have now built what i set out to build, and have found the API very easy to use. On the other hand i found the configuration file a bit tricky to get right, mostly because i'm deploying into EC2 which doesnt allow multicast, so i'm very pleased to see a new protocol designed specifically to overcome that problem. Looks great, thanks guys!
  20. Re: The API is fine![ Go to top ]

    Thanks Brad ! Yes, the config files are the trickiest part; and I always suggest people use the predefined XML files and make changes based off of them. I'm trying to reduce the plethora of config options with ergonomics [1], similar to what the JVM does, which essentially sets and adjusts the config properties at runtime, based (e.g.) on load, loss rate, number of cluster nodes and so on. The goal here is to only list the protocols, and JGroups will set the values for you. This is a longer term goal and we're not yet there... Coincidentally, the other day I was looking for a Webdav server implementation, and ran (among others) into Milton... :-) I'm currently working on a prototype which implements input and output streams (plus File) over a grid with JGroups, later Infinispan, and I want to expose that file system with webdav. Milton looks great so far ! Cheers, [1] https://jira.jboss.org/jira/browse/JGRP-1052
  21. Re: JGroups 2.8.0.GA released[ Go to top ]

    What don't you like about the API ? It is very simple: - create a channel - connect to the cluster - register a callback to receive messages - send messages to all or individual members - disconnect and close the channel Yes, the API is (almost) the same in 2010 it was in 1999, but that shows that we created the right API in 1999 ! :-) Don't compare JGroups to Hazelcast: JGroups is a messaging library, *not* a caching solution ! A caching solution could be built on top of JGroups, e.g. Infinispan. Also, if you're following the mailing lists on JGroups, you'll over and again that I don't support DistributedLockManager: take a look at the code and you'll see this class is annotated with @Unsupported ! The focus in JGroups is really protocols, and *not* the building blocks on top of the channel. If you've been following the lists, I've been urging folks to move away from ReplicatedHashMap (for example), because it was written in half a day and I don't support it anymore, and everyone should move to Infinispan.
  22. Re: JGroups 2.8.0.GA released[ Go to top ]

    Last time I checked (I could be wrong), Hazel is based on synchronous implementation (no-scalable, asynch protocol), so I think you are just to impressed with its nice looking API.
    Its not just API (although its more then nice ;)). Hazelcast works well (passes my distributed lock tests at least, which JGroups never passed) with several nodes. Several (or tens) of nodes is something free solution have to concentrate most, as for use in big clouds either commercial or in-house solutions will be mostly used anyway.
  23. Re: JGroups 2.8.0.GA released[ Go to top ]

    Its not just API (although its more then nice ;)). Hazelcast works well (passes my distributed lock tests at least, which JGroups never passed) with several nodes. Several (or tens) of nodes is something free solution have to concentrate most, as for use in big clouds either commercial or in-house solutions will be mostly used anyway.
    I can't comment on lock thing nor do I have time to test it myself, but, no offense, it is highely likely error on your part, simply because distributed lock is nothing more that message ordering, and that is one of the core problems JGroups is actually built to do.
  24. Re: JGroups 2.8.0.GA released[ Go to top ]

    Try to use protocol conf file (XML file from JGroups source distribution) which guarantees total order.
  25. JGroups2.8.0 GA can't receive messages for the other server: The use case is as following: I deployed webapp on tomcat on Linux server A and server B. the webapp using jgroups to flush cache . and using oscache to cache userInfo. But when I update userInfo on server A, server A can receive the message and flush cache, but server B can't receive message that it also can't flush cache. And the same case that I update userInfo on serverB, serverB can receive the message and flush cache, but server A can't receive message. Jgroups settings is as follows: <!-- to enable multi-machine synchronization, set the following to true--> true <!-- jgroupsInit is the protocol string to start jgroups. we are multicasting on 235.11.17.19 port 32765. For information about all of the parameters in the following string, go to the jboss wiki for jgroups. --> <![CDATA[ UDP(mcast_addr=239.190.1.95;mcast_port=32986;discard_incompatible_packets=true;enable_diagnostics=false; max_bundle_size=60000;max_bundle_timeout=30;ip_ttl=32;enable_bundling=true; use_concurrent_stack=true;thread_pool.enabled=true;thread_pool.min_threads=1; thread_pool.max_threads=25;thread_pool.keep_alive_time=5000; thread_pool.queue_enabled=false;thread_pool.queue_max_size=100; thread_pool.rejection_policy=Run;oob_thread_pool.enabled=true;oob_thread_pool.min_threads=1; oob_thread_pool.max_threads=8;oob_thread_pool.keep_alive_time=5000;oob_thread_pool.queue_enabled=false; oob_thread_pool.queue_max_size=100;oob_thread_pool.rejection_policy=Run): PING(timeout=2000;num_initial_members=3): MERGE2(max_interval=30000;min_interval=10000): FD_SOCK:FD(timeout=10000;max_tries=5;shun=true): VERIFY_SUSPECT(timeout=1500): pbcast.NAKACK(use_mcast_xmit=false;gc_lag=0;retransmit_timeout=300,600,1200,2400,4800;discard_delivered_msgs=true): UNICAST(timeout=300,600,1200,2400,3600): pbcast.STABLE(stability_delay=1000;desired_avg_gossip=50000;max_bytes=400000): pbcast.GMS(print_local_addr=true;join_timeout=3000;shun=false;view_bundling=true): FC(max_credits=20000000;min_threshold=0.10): FRAG2(frag_size=60000):pbcast.STATE_TRANSFER ]]> gla and one thing confuse me, the same settings on JGroups 2.6.12 can work normally, but it can't work on JGroups2.8.0GA. Anyone can help me? Really appreciated!
  26. I found the root cause: The both server I used had installed VM, and I type ifconfig, it shows [root@xmlapi-remedy1 bin]# ifconfig eth0 Link encap:Ethernet HWaddr 00:15:17:0D:DA:12 inet addr:10.224.118.101 Bcast:10.224.118.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:46873435 errors:0 dropped:0 overruns:0 frame:0 TX packets:19680485 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:33923524573 (31.5 GiB) TX bytes:10429994201 (9.7 GiB) Base address:0x2020 Memory:b8820000-b8840000 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:2584408 errors:0 dropped:0 overruns:0 frame:0 TX packets:2584408 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:295871444 (282.1 MiB) TX bytes:295871444 (282.1 MiB) vmnet1 Link encap:Ethernet HWaddr 00:50:56:C0:00:01 inet addr:172.16.65.1 Bcast:172.16.65.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:126 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) vmnet8 Link encap:Ethernet HWaddr 00:50:56:C0:00:08 inet addr:172.16.185.1 Bcast:172.16.185.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:12802 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) If I didn’t set bind_addr in JGroups settings, JGroups firstly create socket using vmnet8 inet addr: 172.16.185.1 not 10.224.118.101, so the messages can’t be sent. I add bind_addr=10.224.118.101 then it can work normally. And if I didn’t add this property what else can I do enable JGroups work? But I confused why it can work on JGroups2.6.12 but not on JGroups2.8.0? Why it choose vmnet8 IP not eth0 IP?
  27. Re: JGroups 2.8.0.GA released[ Go to top ]

    lol, no one uses JGroups anymore
  28. Re: JGroups 2.8.0.GA released[ Go to top ]

    lol, no one uses JGroups anymore
    Can site admin remove his post or even ban him? I mean, it is ok to bash lowbies like me and others, but to be such a dick in thread where academically successful and accomplished posters are participating is really, mildly speaking, lame.
  29. Re: JGroups 2.8.0.GA released[ Go to top ]

    lol, no one uses JGroups anymore


    Can site admin remove his post or even ban him? I mean, it is ok to bash lowbies like me and others, but to be such a dick in thread where academically successful and accomplished posters are participating is really, mildly speaking, lame.
    I've always been intrigued by your name. Isn't Chief Thrall a World of Warcraft character?
  30. Re: JGroups 2.8.0.GA released[ Go to top ]

    Isn't Chief Thrall a World of Warcraft character?
    Hehe yeah =). Pretty good game.
  31. Re: JGroups 2.8.0.GA released[ Go to top ]

    Isn't Chief Thrall a World of Warcraft character?


    Hehe yeah =). Pretty good game.
    It surely is ;) Also, nice to see Bill Burke in a TSS thread again :P Merry Christmas to everyone, and congrats for this 2.8.0 GA release. JGroups is certainly an impressive piece of software!
  32. Re: JGroups 2.8.0.GA released[ Go to top ]

    Yes, I'm happy to see Angry Bill on this thread, too, I thought he's only doing ESTEasy and WoW these days :-) Merry Christmas to everyone, too, and thx for the kudos !
  33. Re: JGroups 2.8.0.GA released[ Go to top ]

    Yes, I'm happy to see Angry Bill on this thread, too, I thought he's only doing ESTEasy and WoW these days :-)
    OO MYYY GAWD, Bill Burke is playing WoW OMFG =)....Please bill tell me you are playing Horde and not noob Alliance, plox? =)