Re: [The Java Posse] Re: Coordinating jobs
I recently worked on a Grails app that ran as four nodes; one node performed job scheduling and announced itself as the 'master' via a UDP broadcast. If I remember correctly it would send a UDP periodically; when other nodes stopped receiving, another would assign itself as master, start broadcasting and run the jobs instead. I can't remember if we rolled our own Java plugin, or used something off the shelf, I'll see if I can remember but I do know it worked very well. On Sunday, 28 October 2012 15:58:01 UTC, rakesh mailgroups wrote: thanks guys for the recommendation to use Quartz Jdbc thingy. Unfortunately, I am not using a relational db!! I'm using MongoDB. Rakesh On 27 October 2012 16:59, Wesley Hartford wes...@cutterslade.cajavascript: wrote: I've been using quartz for years and love it. The JDBC job store can be a little tricky to get working, but it gives you just what you're looking for, and once it is set up, it is rock solid. Reply if you are having trouble setting it up and I'll post the settings I've used. Wesley On Wednesday, October 24, 2012 1:37:14 AM UTC-7, rakesh mailgroups wrote: Hi, I have some batch jobs running and am using Quartz Schedular. They run based on a specific time schedule (eg 55 and 25 minutes each hour over 24 hours). Thing is, I have (at a minimum) 2 nodes running the same software for disaster recovery reasons. So I need a way to only run a job by one of the nodes. Turns out its quite tricky to get right and I keep finding bugs which are hard to reproduce! The current implementation requires each node to write to the db first to say its going to run the job, then read back the record to see if it succeeded in the write (there's a unique key on the job name) and if so, run the job. However, there seem to be issues with overlapping jobs (I think, hard to diagnose after the fact and they are intermittent). I was wondering if there was an easier solution out there I could easily use? Thanks Rakesh -- You received this message because you are subscribed to the Google Groups Java Posse group. To view this discussion on the web visit https://groups.google.com/d/msg/javaposse/-/ZjGaaSih0SAJ. To post to this group, send email to java...@googlegroups.comjavascript: . To unsubscribe from this group, send email to javaposse+...@googlegroups.com javascript:. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en. -- You received this message because you are subscribed to the Google Groups Java Posse group. To view this discussion on the web visit https://groups.google.com/d/msg/javaposse/-/IMcGnkXuL70J. To post to this group, send email to javaposse@googlegroups.com. To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
Re: [The Java Posse] Re: Coordinating jobs
Jgroups - http://www.jgroups.org/ ?? No affiliation. I have used it before for grouping and notifications (member leaves, member joins, etc). No significant issues. On 29 October 2012 18:53, Phil Haigh surfsoftconsult...@gmail.com wrote: I recently worked on a Grails app that ran as four nodes; one node performed job scheduling and announced itself as the 'master' via a UDP broadcast. If I remember correctly it would send a UDP periodically; when other nodes stopped receiving, another would assign itself as master, start broadcasting and run the jobs instead. I can't remember if we rolled our own Java plugin, or used something off the shelf, I'll see if I can remember but I do know it worked very well. On Sunday, 28 October 2012 15:58:01 UTC, rakesh mailgroups wrote: thanks guys for the recommendation to use Quartz Jdbc thingy. Unfortunately, I am not using a relational db!! I'm using MongoDB. Rakesh On 27 October 2012 16:59, Wesley Hartford wes...@cutterslade.ca wrote: I've been using quartz for years and love it. The JDBC job store can be a little tricky to get working, but it gives you just what you're looking for, and once it is set up, it is rock solid. Reply if you are having trouble setting it up and I'll post the settings I've used. Wesley On Wednesday, October 24, 2012 1:37:14 AM UTC-7, rakesh mailgroups wrote: Hi, I have some batch jobs running and am using Quartz Schedular. They run based on a specific time schedule (eg 55 and 25 minutes each hour over 24 hours). Thing is, I have (at a minimum) 2 nodes running the same software for disaster recovery reasons. So I need a way to only run a job by one of the nodes. Turns out its quite tricky to get right and I keep finding bugs which are hard to reproduce! The current implementation requires each node to write to the db first to say its going to run the job, then read back the record to see if it succeeded in the write (there's a unique key on the job name) and if so, run the job. However, there seem to be issues with overlapping jobs (I think, hard to diagnose after the fact and they are intermittent). I was wondering if there was an easier solution out there I could easily use? Thanks Rakesh -- You received this message because you are subscribed to the Google Groups Java Posse group. To view this discussion on the web visit https://groups.google.com/d/** msg/javaposse/-/ZjGaaSih0SAJhttps://groups.google.com/d/msg/javaposse/-/ZjGaaSih0SAJ . To post to this group, send email to java...@googlegroups.com. To unsubscribe from this group, send email to javaposse+...@** googlegroups.com. For more options, visit this group at http://groups.google.com/** group/javaposse?hl=en http://groups.google.com/group/javaposse?hl=en. -- You received this message because you are subscribed to the Google Groups Java Posse group. To view this discussion on the web visit https://groups.google.com/d/msg/javaposse/-/IMcGnkXuL70J. To post to this group, send email to javaposse@googlegroups.com. To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en. -- You received this message because you are subscribed to the Google Groups Java Posse group. To post to this group, send email to javaposse@googlegroups.com. To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
[The Java Posse] Re: java.util.OptionalT (Java 8)
Personally, I think Java's approach is superior to extension methods, because it ensures that dynamic dispatch looks like dynamic dispatch. Allowing both static dispatch (via extension methods) and dynamic dispatch (via standard method call) for the same syntactical representation is confusing for readers and adds complexity to the already too complex topic of method resolution (boxing, erasure, etc.).¹ In my opinion, foo.bar(baz) should always invoke a method on type Foo, not the compiler figures out whether Foo has such a method and if not rewrites it to some static invocation of an extension method in scope FooExtension.bar(foo, baz). Additionally, reflection just works with default methods whereas supporting extension methods in reflection (I'm not sure whether C# for instance doesn't support it at all.) would require capturing the whole environment of the method call to figure out if an eligible extension method is in scope. The only thing which I don't understand is why they decided to call it extension methods. It is misleading because Java's extension methods lack two properties more or less universally accepted: static dispatch, allowing extension of foreign code. Imho, both default methods and defender methods are better names, but I guess Oracle's marketing objected ... In the end, I can understand Oracle's decision for implementing default methods this way. They are both technically superior to extension methods and uphold their (and Sun's) rule of users of our language are not allowed to modify or extend library classes in any way. If there is still a community that cares, they should speak up. Some prominent members are not even grasping the concept behind it yet, so this sounds hard considering the limited amount of time remaining. ¹ I have only read the specification of the new method resolution/invocation rules, not tested it yet. Defender methods add another lookup step to the end, but I'm not sure whether it creates any new corner cases for the users. The usual stuff will work as expected of course, but it will be interesting to see how the JVM will behave when methods will be added or removed, made private, will get/lose default implementations, etc. This has already been a complicated topic, were the JVM changed behavior randomly and backward-incompatibly (it actually got worse in Java 7). If I can trust what people who know more than me on that topic say, it seems that both Java 6 and Java 7 are violating the VM spec concerning method resolution. Let's hope the situation improves for Java 8. Bye, Simon -- You received this message because you are subscribed to the Google Groups Java Posse group. To view this discussion on the web visit https://groups.google.com/d/msg/javaposse/-/9Zezv6mmMFIJ. To post to this group, send email to javaposse@googlegroups.com. To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
Re: [The Java Posse] Re: java.util.OptionalT (Java 8)
C# Extension methods are mere syntactic sugar to convert this: foo(o, args); into this: o.foo(args); So what? I'm only interested in language/api features that have a basis in serious logical reason and purpose. Every Scala feature I listed earlier can be supported by reason and logic, not merely subjective taste and opinion. On Sunday, October 28, 2012 10:13:04 PM UTC-5, Ricky Clarkson wrote: Sure, they don't let me add methods to types I don't control, i.e., they're not extension methods a la C#. I think they solve what they're intended to solve reasonably well though. On Sun, Oct 28, 2012 at 10:47 PM, clay clayt...@gmail.com javascript: wrote: Is there a legitimate complaint about the Java 8 virtual defender methods? That seems like a great enhancement. I haven't heard any objections. I understand that people will complain about everything. But with the Option/flatMap/iteration issue, there is a very specific, technical, articulate, well reasoned and widespread objection. That makes it quite different. Sure, there is choice in languages, but that is a lame response. If there is still a community that cares, they should speak up. I will probably migrate from Java towards Scala whether they fix small ticket items like this or not. I would still like to see the flagship JVM language move in the right direction. On Sunday, October 28, 2012 8:39:21 AM UTC-5, Simon Ochsenreither wrote: We can only assume that they already considered it, looked at code-examples and maybe decided that this is not the way they want people to write code (similar to Guava). This wouldn't be too bad in many languages, but even Java's planned extension methods are designed in a way which prevents people who disagree from fixing it. In the end, different languages have different attitudes towards their users, which can range from “They are stupid and need constant shepherding” to “They know what they are doing, get out of their way”. Thankfully, there are plenty of languages to choose from. -- You received this message because you are subscribed to the Google Groups Java Posse group. To view this discussion on the web visit https://groups.google.com/d/msg/javaposse/-/ZNq_cgjE_UgJ. To post to this group, send email to java...@googlegroups.comjavascript:. To unsubscribe from this group, send email to javaposse+...@googlegroups.com javascript:. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en. -- You received this message because you are subscribed to the Google Groups Java Posse group. To view this discussion on the web visit https://groups.google.com/d/msg/javaposse/-/Q84leqqf0tQJ. To post to this group, send email to javaposse@googlegroups.com. To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
Re: [The Java Posse] Re: java.util.OptionalT (Java 8)
On Mon, Oct 29, 2012 at 7:35 AM, Simon Ochsenreither simon.ochsenreit...@gmail.com wrote: In my opinion, foo.bar(baz) should always invoke a method on type Foo, not the compiler figures out whether Foo has such a method and if not rewrites it to some static invocation of an extension method in scope FooExtension.bar(foo, baz). That's a fair concern. I haven't made up my mind yet, but I remember that when the industry started shifting toward OO, there was concern that when you read C code that says foo(a, b), you knew exactly what method was being invoked but that when you saw C++' a.foo(b), you had no idea what method was going to be called. Defender methods might follow the same path in the end and just become something that we are used to parse. -- Cédric -- You received this message because you are subscribed to the Google Groups Java Posse group. To post to this group, send email to javaposse@googlegroups.com. To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
Re: [The Java Posse] Re: java.util.OptionalT (Java 8)
Given that most programmers begin by doing theObject. and waiting for their IDE to suggest methods, the C# approach is quite useful. The Java 8 approach has some advantages, but it does lose the ability to add methods to a third party/core type without being that third party or Oracle, and in a static and scoped way so it doesn't have the problems Ruby's monkeypatching does. C#, much more than Java, is designed with autocompletion in mind, even down to the order of the clauses in LINQ. E.g., SQL-style select foo from people p where p.age..., the IDE wouldn't have enough context to complete foo, so instead you write: from p in people select p.foo where p.age ... It also caters to a school of [non?]-thought whereby it's OO or otherwise natural if it goes x.y(z) instead of y(x, z). Scala's implicit conversions are almost always used to achieve the same effect. On Mon, Oct 29, 2012 at 12:35 PM, clay claytonw...@gmail.com wrote: C# Extension methods are mere syntactic sugar to convert this: foo(o, args); into this: o.foo(args); So what? I'm only interested in language/api features that have a basis in serious logical reason and purpose. Every Scala feature I listed earlier can be supported by reason and logic, not merely subjective taste and opinion. On Sunday, October 28, 2012 10:13:04 PM UTC-5, Ricky Clarkson wrote: Sure, they don't let me add methods to types I don't control, i.e., they're not extension methods a la C#. I think they solve what they're intended to solve reasonably well though. On Sun, Oct 28, 2012 at 10:47 PM, clay clayt...@gmail.com wrote: Is there a legitimate complaint about the Java 8 virtual defender methods? That seems like a great enhancement. I haven't heard any objections. I understand that people will complain about everything. But with the Option/flatMap/iteration issue, there is a very specific, technical, articulate, well reasoned and widespread objection. That makes it quite different. Sure, there is choice in languages, but that is a lame response. If there is still a community that cares, they should speak up. I will probably migrate from Java towards Scala whether they fix small ticket items like this or not. I would still like to see the flagship JVM language move in the right direction. On Sunday, October 28, 2012 8:39:21 AM UTC-5, Simon Ochsenreither wrote: We can only assume that they already considered it, looked at code-examples and maybe decided that this is not the way they want people to write code (similar to Guava). This wouldn't be too bad in many languages, but even Java's planned extension methods are designed in a way which prevents people who disagree from fixing it. In the end, different languages have different attitudes towards their users, which can range from “They are stupid and need constant shepherding” to “They know what they are doing, get out of their way”. Thankfully, there are plenty of languages to choose from. -- You received this message because you are subscribed to the Google Groups Java Posse group. To view this discussion on the web visit https://groups.google.com/d/msg/javaposse/-/ZNq_cgjE_UgJ. To post to this group, send email to java...@googlegroups.com. To unsubscribe from this group, send email to javaposse+...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en. -- You received this message because you are subscribed to the Google Groups Java Posse group. To view this discussion on the web visit https://groups.google.com/d/msg/javaposse/-/Q84leqqf0tQJ. To post to this group, send email to javaposse@googlegroups.com. To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en. -- You received this message because you are subscribed to the Google Groups Java Posse group. To post to this group, send email to javaposse@googlegroups.com. To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
Re: [The Java Posse] Re: java.util.OptionalT (Java 8)
Java has always supported static dispatch looking like dynamic dispatch.. instance.staticMethod(args), it's just deemed poor form. I don't think erasure has any bearing on method resolution. Are you a fan of Scala's implicit conversions? Those make it so that foo.bar(baz) can really be someConversionMethod(foo).bar(baz), actually harder to predict than extension methods. Similarly, Scala's approach doesn't show up in reflection as far as I know (at least in Java reflection; I haven't looked at the Scala reflection library yet). It's probably best that extension methods a la C# don't appear in reflection, because they're a static construct and you could genuinely have two separate implementations of the same method used in separate parts of code. You wouldn't want any potential for runtime conflicts caused by a static convenience. On Mon, Oct 29, 2012 at 11:35 AM, Simon Ochsenreither simon.ochsenreit...@gmail.com wrote: Personally, I think Java's approach is superior to extension methods, because it ensures that dynamic dispatch looks like dynamic dispatch. Allowing both static dispatch (via extension methods) and dynamic dispatch (via standard method call) for the same syntactical representation is confusing for readers and adds complexity to the already too complex topic of method resolution (boxing, erasure, etc.).¹ In my opinion, foo.bar(baz) should always invoke a method on type Foo, not the compiler figures out whether Foo has such a method and if not rewrites it to some static invocation of an extension method in scope FooExtension.bar(foo, baz). Additionally, reflection just works with default methods whereas supporting extension methods in reflection (I'm not sure whether C# for instance doesn't support it at all.) would require capturing the whole environment of the method call to figure out if an eligible extension method is in scope. The only thing which I don't understand is why they decided to call it extension methods. It is misleading because Java's extension methods lack two properties more or less universally accepted: static dispatch, allowing extension of foreign code. Imho, both default methods and defender methods are better names, but I guess Oracle's marketing objected ... In the end, I can understand Oracle's decision for implementing default methods this way. They are both technically superior to extension methods and uphold their (and Sun's) rule of users of our language are not allowed to modify or extend library classes in any way. If there is still a community that cares, they should speak up. Some prominent members are not even grasping the concept behind it yet, so this sounds hard considering the limited amount of time remaining. ¹ I have only read the specification of the new method resolution/invocation rules, not tested it yet. Defender methods add another lookup step to the end, but I'm not sure whether it creates any new corner cases for the users. The usual stuff will work as expected of course, but it will be interesting to see how the JVM will behave when methods will be added or removed, made private, will get/lose default implementations, etc. This has already been a complicated topic, were the JVM changed behavior randomly and backward-incompatibly (it actually got worse in Java 7). If I can trust what people who know more than me on that topic say, it seems that both Java 6 and Java 7 are violating the VM spec concerning method resolution. Let's hope the situation improves for Java 8. Bye, Simon -- You received this message because you are subscribed to the Google Groups Java Posse group. To view this discussion on the web visit https://groups.google.com/d/msg/javaposse/-/9Zezv6mmMFIJ. To post to this group, send email to javaposse@googlegroups.com. To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en. -- You received this message because you are subscribed to the Google Groups Java Posse group. To post to this group, send email to javaposse@googlegroups.com. To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
Re: [The Java Posse] Re: java.util.OptionalT (Java 8)
Hi Ricky, Java has always supported static dispatch looking like dynamic dispatch.. instance.staticMethod(args), it's just deemed poor form. Of course. I just try to forget that as much as possible. :-) I don't think there is any recent IDE which doesn't yell at you if you try to use this syntax. So I think it is safe to say that generally, a developer can expect that stuff which looks like dynamic dispatch is dynamic dispatch these days in Java. I don't think erasure has any bearing on method resolution. http://docs.oracle.com/javase/specs/jls/se7/html/jls-15.html#jls-15.12 http://docs.oracle.com/javase/specs/jvms/se7/html/jvms-5.html#jvms-5.4.3 These two things are by far the most complicated parts of the whole specs. It is almost completely impossible to figure out what is actually allowed and what not without writing positive/negative test-cases for every single line of the spec. I guess that's the reason why even the official implementation from Oracle/openJDK violates the spec. (See the IKVM blog.) Are you a fan of Scala's implicit conversions? Those make it so that foo.bar(baz) can really be someConversionMethod(foo).bar(baz), actually harder to predict than extension methods. A fan would be a bit too much. Until now, they are the just the least bad approach I have seen. The dispatch on bar is still dynamic btw (but that's only nitpicking, because the conversion is computed by the static type of foo). I share your concern here. One thing which makes the issue less pronounced than in other languages is that the combination of - a deprecation policy which actually removes things - traits - more classes are final tends to eliminate a lot of those situations where one would want to use extension methods. Imo implicits have a better cost/benefit ratio than extension methods, because it is a more general concept which fits into the general notion of OOP instead of some ad-hoc mechanism. The notion of we add methods, not because it's fun, but to implement interfaces is probably a good example. Additionally, they allow library implementations of many things which would otherwise be hard-coded in the language/compiler, like implicit conversions. Considering the huge amount of implicit conversion in Java, I'm pretty happy that many of those necessary for compatibility are implemented as simple methods in Scala, allowing developers to use their IDE to find them. If for instance Java would drop their pretty insane implicit widening conversions, the appropriate implicit methods could just be removed from the standard library in Scala. (implicit widening conversions are actually a pretty bad example, because they have a lot of subtle impact on method resolution, subtyping, etc. which is pretty faithfully supported in Scala, so it would be a bit more work in this case.) As a conclusion, a lot of those things normally addressed by extension methods are solved using more standard means in Scala and implicits are a more general mechanism covering issues extension methods can't solve (and which are normally addressed with a lot of more ugly and complicated means). Similarly, Scala's approach doesn't show up in reflection as far as I know (at least in Java reflection; I haven't looked at the Scala reflection library yet). I think there is some method for runtime reflection (or did I confuse something?). If you use compile-time reflection, you get them via the Context argument, as far as I remember. It's probably best that extension methods a la C# don't appear in reflection, because they're a static construct and you could genuinely have two separate implementations of the same method used in separate parts of code. You wouldn't want any potential for runtime conflicts caused by a static convenience. Yes! That's exactly what I meant with it would require capturing the whole environment of the method call to figure out if an eligible extension method is in scope. Bye, Simon -- You received this message because you are subscribed to the Google Groups Java Posse group. To view this discussion on the web visit https://groups.google.com/d/msg/javaposse/-/LItriyeZT88J. To post to this group, send email to javaposse@googlegroups.com. To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
Re: [The Java Posse] java.util.OptionalT (Java 8)
On Mon, 29 Oct 2012 23:13:20 +0100, Mark Derricutt m...@talios.com wrote: My main complaint about them is that well… they're USELESS unless you're the API designer - and they're anti-modular. Following the discussion with interest - a suggestion, can you also give some short code examples attached to your considerations (not only referring to Mark's post, of course). -- Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. We make Java work. Everywhere. http://tidalwave.it/fabrizio/blog - fabrizio.giud...@tidalwave.it -- You received this message because you are subscribed to the Google Groups Java Posse group. To post to this group, send email to javaposse@googlegroups.com. To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
Re: [The Java Posse] java.util.OptionalT (Java 8)
On 29 October 2012 22:13, Mark Derricutt m...@talios.com wrote: My main complaint about them is that well… they're USELESS unless you're the API designer - and they're anti-modular. The problem being solved is Interface Evolution. Do you think just interface evolution is the wrong goal, or that the implementation of that is bad? To me, for what the stated problem is, default methods seem reasonable. w.r.t. 'anti-modular', I'd like to hear more on what you mean by this. Do you mean that there's no way to organise default methods except as being in the same file as the interface declaration? Kind regards, Graham -- You received this message because you are subscribed to the Google Groups Java Posse group. To post to this group, send email to javaposse@googlegroups.com. To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
