I have listenner method which handle messages implemented by Spring cloud stream like this:
#StreamListener(value = MyInterface.INPUT)
public void handleMsg(#Payload Foo foo) {
// if (concurrentHashMap.containsKey(foo.getId())) concurrentHashMap.remove(foo.getId());
}
here is my second method, which should be blocked by previous:
public Foo getFoo(long fooId) {
// here I need block method with some mechanism until handleMsg remove received object from map and return this foo from there
return fooFromStream;
}
My goal is call getFoo method from service class like this:
// some logic
Foo foo = service.getFoo(fooId);
// some logic which required received foo;
I had idea wrap Foo in getFoo method into AsyncResult and next call method get on Future result of that which cause block, but I have no idea how to pass foo from stream into method getFoo
Use case should be this:
I call method getFoo which send foo into message broker and register foo in map, and do some logic, and next when command is done I receive message in StreamListenner, remove foo from map, and next I need return that foo from method getFoo.
Can you tell me how to do that or what is the best practice to solve it? Thank you in advice.
It's not entirely clear what you are trying to do but a Map<Long, BlockingQueue<Foo> will allow you to block on take (or, poll with a timeout is probably better) until the listener offers the Foo; then remove the map entry.
Bear in mind that once the Foo is put in the queue, the record will be ack'd and, if the server crashes, it will be lost.
You could use a concurrent Map of Long and Blocking queues blocking queue for that:
ConcurrentMap<Long, BlockingQueue<Foo>> fooMap = new ConcurrentHashMap<>();
...
private BlockingQueue<Foo> getFooQueue(long fooId) {
return fooMap.computeIfAbsent(fooId, l -> new ArrayBlockingQueue<>(1));
}
...
#StreamListener(value = MyInterface.INPUT)
public void handleMsg(#Payload Foo foo) {
BlockingQueue<Foo> fq = getFooQueue(foo.getId());
synchronized(fq) {
fq.clear();
fq.add(foo);
}
}
...
public Foo getFoo(long fooId) throws InterruptedException {
BlockingQueue<Foo> fq = getFooQueue(fooId);
synchronized(fq) {
return fq.take();
}
}
These 2 synchronized blocks are only needed if it may be possible that your handleMsg can be called multiple times when a currently available foo should be overridden with the new foo.
Related
To perform lock-free and wait-free lazy initialization I do the following:
private AtomicReference<Foo> instance = new AtomicReference<>(null);
public Foo getInstance() {
Foo foo = instance.get();
if (foo == null) {
foo = new Foo(); // create and initialize actual instance
if (instance.compareAndSet(null, foo)) // CAS succeeded
return foo;
else // CAS failed: other thread set an object
return instance.get();
} else {
return foo;
}
}
and it works pretty well except for one thing: if two threads see instance null, they both create a new object, and only one is lucky to set it by CAS operation, which leads to waste of resources.
Does anyone suggest another lock-free lazy initialization pattern, which decrease probability of creating two expensive objects by two concurrent threads?
If you want true lock-freedom you will have to do some spinning. You can have one thread 'win' creation rights but the others must spin until it's ready.
private AtomicBoolean canWrite = new AtomicBoolean(false);
private volatile Foo foo;
public Foo getInstance() {
while (foo == null) {
if(canWrite.compareAndSet(false, true)){
foo = new Foo();
}
}
return foo;
}
This obviously has its problems of busy spinning (you can put a sleep or yield in there), but I would probably still recommend Initialization on demand.
I think you need to have some synchronization for the object creation itself. I would do:
// The atomic reference itself must be final!
private final AtomicReference<Foo> instance = new AtomicReference<>(null);
public Foo getInstance() {
Foo foo = instance.get();
if (foo == null) {
synchronized(instance) {
// You need to double check here
// in case another thread initialized foo
Foo foo = instance.get();
if (foo == null) {
foo = new Foo(); // actual initialization
instance.set(foo);
}
}
}
return foo;
}
This is a very common pattern especially for lazy singletons. Double checked locking minimizes the number of times the synchronized block is actually executed.
I would probably go with the lazy init Singleton pattern:
private Foo() {/* Do your heavy stuff */}
private static class CONTAINER {
private static final Foo INSTANCE = new Foo();
}
public static Foo getInstance() {
return CONTAINER.INSTANCE;
}
I do not actually see any reason on using an AtomicReference member field for itself.
What about using another volatile variable to lock?
You can do the double lock with new variable?
I am not sure if end result should be performance centric or not , if yes below is not solution . can you please check twice for instance and after first check call thread.sleep method for random mili seconds less than 100 mili seconds.
private AtomicBoolean canWrite = new AtomicBoolean(false);
private volatile Foo foo;
public Foo getInstance() {
if(foo==null){
Thread.Sleep(getRandomLong(50)) // you need to write method for it
if(foo==null){
foo = new Foo();
}
}
return foo;
}
I am struggling with the following:
The class is constructed through Spring
It implements the interface that consist of two methods (process, shutdown)
It also implements Callable
The problem:
process() returns a Type and it is called inside the call(), the problem is that process has input parameters which call() signature doesn’t allow. So I referred to this question: Is there a way to take an argument in a callable method?, unfortunately that wouldn't work for me as my object constructed through Spring, process() gets called from the JSP and the input parameters are variable, depending on the user action.
Will include some code for clarification, bellow:
public class MyClass implements MyClassInterface, Callable<Results> {
private String fileLocation;
private final SMTPMailer smtpMalier;
public MyClass(String fileLocation, SMTPMailer smtpMalier) {
this.fileLocation = fileLocation;
this.smtpMalier = smtpMalier;
}
public Results call() {
// to return process(arg1, arg2) here, need to cater for input parameters
}
public Results process(String arg1, String arg2) {
// does some proceeding, returns Results
}
public void shutdown() {
// shut down implementation
}
}
How can I go around this?
Short answer is, you can't.
The contract of Callable is that it can perform an action without any input.
If it needs parameters, it isn't Callable.
You need to consider how the code is called. I assume you have code like this:
AsyncTaskExecutor executor = ...;
MyClass theService = ...;
String foo = "apple", bar = "banana";
Future<Results> result = executor.submit(theService); // Needs foo and bar :(
The simple solution is, don't implement Callable in MyClass. It isn't callable, it needs some input parameters! Implement Callable where it makes sense instead, such as where you have all parameters:
AsyncTaskExecutor executor = ...;
MyClass theService = ...;
String foo = "apple", bar = "banana";
Future<Results> result = executor.submit(new Callable<Results>(){
#Override public Results call(){
return theService.process(foo, bar);
}
});
// Or if you're on Java 8:
Future<Results> result = executor.submit(() -> theService.process(foo, bar);
If this is something that happens a lot and you really really want the class to provide you with Callables, you could give it a factory method:
public class MyClass implements MyClassInterface {
public Results process(String arg1, String arg2) {
// does some proceeding, returns Results
}
public Callable<Results> bind(String arg1, String arg2) {
return () -> process(arg1, arg2);
}
// Other methods omitted
}
I have the following auto-generated code:
EDIT: It's auto-generated so I'm not allowed to modify it. (If only it were that easy...)
abstract class Foo {
}
class Fuwa extends Foo {
String chocolate() {...}
String muffin() {...}
}
class Fuko extends Foo {
String chocolate() {...}
String cookie() {...}
}
The chocolate() method in both the child classes are literally (aside from variable names) line-for-line identical and essentially interchanable.
Based on client input, I want test the specified children of Foo and validate the response. Currently I have:
class FooFactory {
Foo createFoo(name) {
if (name.equals("fuwa")) {
...
// returns a Fuwa object
} else if (name.equals("fuko")) {
...
// returns Fuko object
}
}
}
class MuffinTester extends FooTester {
boolean test(Foo inputFoo) {
Result x = ((Fuwa) inputFoo).muffin();
return validate(x);
}
private validate(x) {...}
}
class CookieTester extends FooTester {
boolean test(Foo inputFoo) {
Result x = ((Fuko) inputFoo).cookie();
return validate(x);
}
private validate(x) {...}
}
class TesterFactory {
FooTester createTest(name) {
if (name.equals("muffin")) {
...
// returns MuffinTester object
} else if (name.equals("cookie")) {
...
// returns CookieTester object
} else if (name.equals("chocolate")) {
...
// returns ChocolateTester object
}
}
}
The client specifies the Foo and method to be tested and the FooFactory and TestFactory (respectively) instantiate the required objects (there is logic to make sure the request is valid and the Foo contains the method, eg. no testing cookie() on Fuwa).
The problem arises when I try to code ChocolateTester:
class ChocolateTester extends FooTester {
boolean test(Foo inputFoo) {
Result x = ((???) inputFoo).chocolate();
return validate(x);
}
private validate(x) {...}
}
I can't leave inputFoo as just Foo since the compiler doesn't like that it doesn't have a chocolate() method. And I can't cast inputFoo to Fuwa or Fuko since whichever one I don't cast it to gets annoyed that they're being confused with their sibling (even though they're identical when exposed to chocolate for all intents and purposes). It would be great if I could modify Foo, but since it's auto-generated I can't touch it.
The best I could come up with is a bunch of if/else statements:
class ChocolateTester extends FooTester {
boolean test(Foo inputFoo) {
Result x;
if (inputFoo instanceof Fuwa) {
x = ((Fuwa) inputFoo).chocolate();
} else if (inputFoo instanceof Fuko) {
x = ((Fuko) inputFoo).chocolate();
}
return validate(x);
}
private validate(x) {...}
}
But feels really hacky when there are some 15 or so Foo and I have to duplicate the giant if/else block in for other methods the children Foo have in common, say a cake() method. Moreover, this sounds like a maintenance nightmare when a new Foo named Futaro joins in and I have to update the if/else blocks in not only FooFactory but also in ChocolateTester and CakeTester and in any other common methods.
So...
I'm sorry for being so long winded, but basically I want to ask is there a better way to do this (that is not too hacky/unmaintainable)? Is there a simple annotation to force method call to a method which doesn't exist, or a way to cast an object to its actual type, or a use of reflection which can solve this?
Update: I ultimately decided to use reflection with method invocation, see below.
Yes there is!
You can create abstract methods inside of Foo like this:
abstract class Foo {
abstract String Chocolate();
}
OR you turn Foo into an Interface, forcing any implementing classes to have a chocolate() method:
interface Foo {
String chocolate();
}
class Fuwa implements Foo {
String chocolate() {...}
String muffin() {...}
}
class Fuko implements Foo {
String chocolate() {...}
String cookie() {...}
}
After automatically generating the code, you could post-process it to add a suitable interface to the child classes. The exact method you'd use to do this would depend on what build automation you're using already. For example, if you're using ant to run the axis2 code generator, then it'd be straightforward to add some additional steps to the code-generation target that changed each of the generated files.
I posed this question to my boss and what he suggested was that I use reflection to invoke the method.
So in this case:
class ChocolateTester extends FooTester {
boolean test(Foo inputFoo) {
Method chocolateMethod = inputFoo.getClass().getMethod("chocolate");
Result x = chocolateMethod.invoke(inputFoo);
return validate(x);
}
private validate(x) {...}
}
I would need to add some code validate that inputFoo indeed had a chocolate() method and to catch all the exceptions, but this seems like the best solution given the constraint that I cannot modify the auto-generated code.
I was asking this question about controlling a thread that was reading from a blocking queue. Although it wasn't the solution I chose to go with, several people suggested that a special "poison pill" or "sentinel" value be added to the queue to shut it down like so:
public class MyThread extends Thread{
private static final Foo STOP = new Foo();
private BlockingQueue<Foo> blockingQueue = new LinkedBlockingQueue<Foo>();
public void run(){
try{
Foo f = blockingQueue.take();
while(f != STOP){
doSomethingWith(f);
f = blockingQueue.take();
}
}
catch(InterruptedException e){
}
}
public void addToQueue(Foo f) throws InterruptedException{
blockingQueue.put(f);
}
public void stop() throws InterruptedException{
blockingQueue.put(STOP);
}
}
While I like this approach, I decided not to use it because I wasn't sure what value to use for the STOP field. In some situations it's obvious - for instance, if you know you're inserting positive integers, negative numbers could be used as control values - but Foo is a fairly complex class. It's immutable and hence has a constructor that takes several arguments. To add a no-argument constructor would mean leaving several fields uninitialised or null, which would cause methods to break if they were used elsewhere - Foo is not just used with MyThread. Similarly, putting dummy values into the main constructor would just pass this problem on as several of the fields and constructor parameters are themselves significant objects.
Am I simply programming over-defensively? Should I worry about adding no-argument constructors to a class, even if there are no setters to make the object usable (just assume other programmers will be sensible enough to not use that constructor)? Is the design of Foo broken if it can't have a no-argument constructor or at least a non-value - would it be better to put if(someField == null){throw new RuntimeException();} checks in all methods?
I don't really see what the advantage of this design is versus a simple boolean variable to indicate the loop should stop.
But if you really want to go with this design, I would suggest making a private no-arg constructor, and making a static STOP Foo. Like this.
public class Foo {
public static final Foo STOP = new Foo();
... fields
private Foo(){}
public Foo(...){
...
}
...
}
public class MyThread extends Thread{
private static final Foo STOP = new Foo();
private BlockingQueue<Foo> blockingQueue = new LinkedBlockingQueue<Foo>();
public void run(){
try{
Foo f = blockingQueue.take();
while(f != STOP){
doSomethingWith(f);
f = blockingQueue.take();
}
}
catch(InterruptedException e){
}
}
public void addToQueue(Foo f) throws InterruptedException{
blockingQueue.put(f);
}
public void stop() throws InterruptedException{
blockingQueue.put(Foo.STOP);
}
}
This has the advantage that you're still not exposing an invalid constructor.
The disadvantage is that the Foo class knows that in some cases it's used as a 'poison pill', which might not be what it's for. Another disadvantage is that The STOP object might be inconsistent. You could make an anonymous subclass from it do disable the methods with UnsupportedOperationException or something.
I think you're right about not using empty constructors. If Foo is such an complex class, it doesn't seem logical to use a complete object for that.
If adding a null is possible. That seems a nice way to go.
Another way could also be to implement an interface. IBlockableQueueObject? This could be implemented by the foo object and by the STOP sign. Only thing is that you have to cast the interface back to the Foo if it is not a STOP.
another option would be to wrap Foo in a generic wrapper such as this:
public class Wrapped<T> {
private final T value;
public Wrapped(T value) {
this.value = value;
}
public T get() { return value; }
}
which you can then use to pass a null value as a poison pill to a BlockingQueue<Wrapped<Foo>>.
You should worry about having no-argument constructors that don't result in usable instances.
The design of Foo sounds fine - I would generally assume that I'm not allowed to pass in null into a constructor unless the documentation specifically allows me to. Especially with an immutable class.
I have a class Manager that is going to be accessed by multiple threads at the same time, I want to know if I did it the right way ?
also I think I need RemoveFoo to be atomic, but I'm not sure
public class Manager
{
private ConcurrentHashMap<String, Foo> foos;
//init in constructor
public RemoveFoo(String name)
{
Foo foo = foos.Get(name);
foo.RemoveAll();
foos.Remove(name);
}
public AddFoo(Foo foo)
{...}
}
public class Foo
{
private Map<String,Bar> bars;
//intialize it in constructor
//same for RemoveBar
public void AddBar(Bar bar)
{
synchronized(this)
{
bars.put(bar.id, bar);
}
}
public void RemoveAll()
{
synchronized(this)
{
//some before removall logic for each one
bars.remove(bar.id, bar);
}
}
}
public class Bar
{}
You do not need synchronised methods as you are using a ConcurrentHashMap, however be aware that Foo foo = foos.Get(name) could return null as another thread could already have removed the entry from the map.
Members can be declared as Map<String, Foo> foos, but must be initialsed as foos = new ConcurrentHashMap<String, Foo>;
RemoveFoo could be problematic. I suggest to use:
Foo foo = foos.remove (name);
if (foo != null) foo.removeAll();
instead. This makes sure that the map doesn't change between get() and remove().
In Foo, it's enough to synchronize on bars instead of the whole instance. But that's just a minor optimization.
Declare RemoveFoo(String) as synchronized:
public synchronized void RemoveFoo(String name) {
…
}
Also, be advised of the following:
method names should be lower case, e.g. removeFoo instead of RemoveFoo. This is not C#. :)
Every method needs a return type: public removeFoo() is not a valid method declaration, it needs to be public void removeFoo().
If you use a concurrentHashMap in Foo like
private Map<String,Bar> bars = new ConcurrentHashMap<String, Bar>();
maybe you can do away with the synchronization in Foo as well.
I am not sure what you are going to do on Foo and Bar, but it looks like a pattern of deallocation.
If they are not referenced by others, just call foos.Remove(name); and let GC engine handle the deallocation.