0

I want to build simple app that sets some key in a firebase database to some value. Because it is async, I create CountDownLatch and wait for it to complete, but it never completes.

Here is my code:

package me.ibrohim.adler;

import com.google.firebase.FirebaseApp;
import com.google.firebase.FirebaseOptions;
import com.google.firebase.auth.FirebaseCredentials;
import com.google.firebase.database.FirebaseDatabase;
import com.google.firebase.tasks.OnCompleteListener;
import com.google.firebase.tasks.Task;

import java.io.File;
import java.io.FileInputStream;
import java.io.IOException;
import java.util.Set;
import java.util.concurrent.CountDownLatch;
import java.util.function.Consumer;

public class Main {

    public static void main(String [] args) throws InterruptedException {

        FileInputStream serviceAccount = null;

        try {

            serviceAccount = new FileInputStream("/home/ibrohim/.adler/adminsdk.json");

            FirebaseOptions options = new FirebaseOptions.Builder()
                    .setCredential(FirebaseCredentials.fromCertificate(serviceAccount))
                    .setDatabaseUrl("https://[my app].firebaseio.com/")
                    .build();

            FirebaseApp.initializeApp(options);

        } catch (IOException e) {

            e.printStackTrace();

        } finally {

            if (serviceAccount != null) try {

                serviceAccount.close();

            } catch (IOException e) {

                e.printStackTrace();

            }

        }


        CountDownLatch done = new CountDownLatch(1);

//        new Thread(() -> {
//            try {
//                Thread.sleep(1000);
//                done.countDown();
//            }
//            catch (Exception e){
//                System.err.println(e);
//            }
//        }).start();

        FirebaseDatabase
                .getInstance()
                .getReference("[some path]")
                .setValue("[some value]")
                .addOnCompleteListener(task -> done.countDown());

        done.await();

    }

}
ibrohimislam
  • 717
  • 7
  • 21

1 Answers1

0

I just ran this code in IntelliJ:

CountDownLatch done = new CountDownLatch(1);
database.getReference("45253891").setValue("[some value]")
        .addOnCompleteListener(task -> done.countDown());
done.await();

And it ran without any problem. (see the result here)

I'm not sure what's going on in your system. Are you sure you reach the setValue() call?

Update: in the comments Doug Stevenson shows how you can ensure the JVM exits when you're done:

I typically add System.exit(0) after the await to force things to stop when I know they're done.

So this uses a CountDownLatch or similar synchronization primitive like above, but then adds a System.exit(0) after it.

Frank van Puffelen
  • 565,676
  • 79
  • 828
  • 807
  • Yes, it reach setValue, and my value on database changed. but the program never stop. here is my stack trace: https://pastebin.com/SVy1GNsD – ibrohimislam Jul 22 '17 at 23:58
  • I'm not certain what is happening. If you put a `System.out.println()` after the `done.await()`, does it get executed? – Frank van Puffelen Jul 23 '17 at 00:34
  • the `System.out.println()` executed. – ibrohimislam Jul 23 '17 at 00:45
  • Hmmm.... now that you mention it, the process in IntelliJ also seems to not exit until *much* later. I'll see what I can dig up. – Frank van Puffelen Jul 23 '17 at 03:42
  • I've try with firebase-admin 4.1.0, but it seems the same. – ibrohimislam Jul 23 '17 at 03:45
  • 2
    I typically add `System.exit(0)` after the `await` to force things to stop when I know they're done. – Doug Stevenson Jul 23 '17 at 03:49
  • Hmmm.... Version 2.x of the JVM SDK immediately excited after the last statement in the main thread, which is why the trick with the latch was needed (or the more common timer). I never realized the behavior might have changed with the Admin SDKs. I'm checking what the intended behavior of the Admin SDKs is. – Frank van Puffelen Jul 23 '17 at 04:04
  • @FrankvanPuffelen Even I am facing the same problem. It would be better if you can help. – eshb Aug 07 '17 at 10:50
  • @baymaxx "the same problem" is rather vague. I have given my approach to keeping the JVM alive long enough, Doug has shown how he ensures it exits when he's done. If those two don't help for you, show the [minimal code that reproduces where you are stuck](http://stackoverflow.com/help/mcve). – Frank van Puffelen Aug 07 '17 at 14:42