Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Dorus
    @Dorus
    Doh, Observable.from has even an Future overload
    I think we can ignore rxjava-async
    That page should tell you what you need :)
    By default subscribe happens on the current thread.
    But as soon as you hit some scheduled actions, it moves away from the starting thread.
    However, subscribeOn(scheduler) can be used to move even the subscribing call to a new scheduler. And that scheduler might use a different thread.
    purna455
    @purna455
    so here(in flatmap example) all the service calls happens in different thread ,whereas the subscribe call will happen in the current thread from where its invoked?
    Boy Wang
    @boyw165
    The retryWhen operator is awesome. But how could it resubscribe the returned observable? That's a bit confusing because it seems like the returned observable subscribe to a subject, is it?
    Vasilis Charalampakis
    @charbgr
    Hi anyone here using Retrofit 1.9?
    Alexander Garmash
    @AlexanderGarmash
    @charbgr yes
    Vasilis Charalampakis
    @charbgr
    nice
    do you know why Retrofit 1.9 swallows error like SocketTimeoutException and the observable’s onError method is not called?
    basically Network Errors
    Alexander Garmash
    @AlexanderGarmash
    @charbgr Actually, i've never got this error...
    Vasilis Charalampakis
    @charbgr
    any RetrofitError is not passed to onError
    weird
    you can test it if you close all network connections and make a call to your server
    Alexander Garmash
    @AlexanderGarmash

    Do you apply OkClient in your RestAdapter?
    Like this:

    @Provides
        @Singleton
        public RestAdapter provideRestAdapter(@Named("apiOkClient") Client client, DBQErrorHandler errorHandler){
            RestAdapter API = new RestAdapter.Builder()
                    .setEndpoint(NEW_PRODUCTION_API_URL)
                    .setErrorHandler(errorHandler)
                    .setClient(client)        // <<<<
                    .setLogLevel(RestAdapter.LogLevel.FULL)
                    .build();
            return API;
        }

    Where Client client is

    @Singleton
        @Provides
        @Named("apiOkClient")
        public Client provideClient(){
            return new OkClient(createOkHttpClient());
        }
    
    private static OkHttpClient createOkHttpClient(){
            OkHttpClient client = new OkHttpClient();
    client.setConnectTimeout(5, TimeUnit.MINUTES);
        client.setReadTimeout(5, TimeUnit.MINUTES);
            return client;
        }
    Vasilis Charalampakis
    @charbgr
    yes
    but i have smaller timeouts
    20 seconds
    Alexander Garmash
    @AlexanderGarmash
    try to increase it
    but I think it isn't the problem
    Vasilis Charalampakis
    @charbgr
    the problem is not to increase it
    it’s retrofit design
    Alexander Garmash
    @AlexanderGarmash

    Also, try this client:

    private static OkHttpClient getUnsafeOkHttpClient() {
            try {
                // Create a trust manager that does not validate certificate chains
                final TrustManager[] trustAllCerts = new TrustManager[] {
                        new X509TrustManager() {
                            @Override
                            public void checkClientTrusted(java.security.cert.X509Certificate[] chain, String authType) throws CertificateException {
                            }
    
                            @Override
                            public void checkServerTrusted(java.security.cert.X509Certificate[] chain, String authType) throws CertificateException {
                            }
    
                            @Override
                            public java.security.cert.X509Certificate[] getAcceptedIssuers() {
                                return null;
                            }
                        }
                };
    
                // Install the all-trusting trust manager
                final SSLContext sslContext = SSLContext.getInstance("SSL");
                sslContext.init(null, trustAllCerts, new java.security.SecureRandom());
                // Create an ssl socket factory with our all-trusting manager
                final SSLSocketFactory sslSocketFactory = sslContext.getSocketFactory();
    
                OkHttpClient okHttpClient = new OkHttpClient();
                okHttpClient.setSslSocketFactory(sslSocketFactory);
                okHttpClient.setHostnameVerifier(new HostnameVerifier() {
                    @Override
                    public boolean verify(String hostname, SSLSession session) {
                        return true;
                    }
                });
    
                return okHttpClient;
            } catch (Exception e) {
                throw new RuntimeException(e);
            }
        }

    I'm not sure it will help you, but try it please

    Vasilis Charalampakis
    @charbgr
    trust any certification is not safe
    Alexander Garmash
    @AlexanderGarmash
    Yes
    Vasilis Charalampakis
    @charbgr
    increasing the timeout is not solving the problem
    Alexander Garmash
    @AlexanderGarmash
    With this exception I think you have the perfect safiety :smile:
    dwursteisen
    @dwursteisen
    Anyone played with the RxJavaSchedulersHook plugin. With a Executor Service as a scheduler, the "onSchedule" method hook is not called. I don't know if it's expected...
    (my goal is to progragate some MDC key thought my Observable) => http://blog.mabn.pl/2014/11/rxjava-logback-and-mdc-threadlocal.html
    Josh Durbin
    @joshdurbin
    Hey Everyone — I have a very, very specific question.
    I’m using an implementation of a library, david moten’s tree - https://github.com/davidmoten/rtree - in which the tree itself is immutable, thus operations to mutate the tree result in a “view” of that object with the supplied operation result
    I’ve got a basic API that allows insertion and query of the rtree, which supports rx query operations OOTB
    I’ve wrapped the insert commands in a write lock, but i’m at a loss, if you will, how that impacts the read operations (as you’d typically also wrap your ‘read’ logic in read locks)
    Mainly the insertPlace and getPlaces methods.
    Dorus
    @Dorus

    @joshdurbin
    I didn't look at any of that, but i can give you the theory :)

    If the tree is immutable, you do not need locks. Instead, any insert will traverse the tree, and create a new tree. Usually kept efficient by reusing unmodified parts of the old tree. That way, when you modify the tree, you receive a new tree that you then need to communicate to any reader that's consuming the tree. Only once you've communicated the new tree root, they will be able to read your modifications.

    Boy Wang
    @boyw165
    For a most basic observable, there's only one subscriber can subscribe to it at the same time, right?
    Dorus
    @Dorus
    no
    Boy Wang
    @boyw165
    Except PublishSubject, still no?
    Dorus
    @Dorus
    Observables are like function calls, you can call them multiple times but different calls wont affect each other.
    At least for Cold observables
    Hot observables do affect eachother, they share side effects.
    PublishSubject is used to convert a cold observable into a hot one.
    Boy Wang
    @boyw165
    Oh I got it. So how do I build a pub-sub pattern by using observable? I want the observable can do some heavy image process when demand, and emit the result to all subscribers when done.
    Dorus
    @Dorus
    It pretty much already is.
    Mostly you need to make your source hot.