using redis

[Christoph Sturm]

Hello webbit team,

I'm new to webbit, and I want it to build a http server that uses a redis cache.

I think https://github.com/spullara/redis-protocol is what I need, but I have no idea how to use netty protocols with webbit.

is there some demo code somewhere? 

thanks

 chris

[Aslak Hellesøy]

On Monday, 7 January 2013 at 18:39, Christoph Sturm wrote:

Hello webbit team,

I'm new to webbit, and I want it to build a http server that uses a redis cache.

I think https://github.com/spullara/redis-protocol is what I need, but I have no idea how to use netty protocols with webbit.

I haven't looked, but I assume the lib you linked to has an API that abstracts away the protocol (like all database drivers). You shouldn't have to use the Netty API with neither webbit nor redis-protocol.

To use it in Webbit, create a handler implementation that switches to a different thread/executor to talk to redis (to prevent blocking webbit's thread) then switch back to the webbit thread when you're done talking to reddit and render the result.

Aslak

[Christoph Sturm]

Well it's a redis protocol for netty so it should not need a new thread. Hitting all the back ends async Is the main reason why I want to use webbit (or netty)

-chris

[aslak hellesoy]

On Mon, Jan 7, 2013 at 9:55 PM, Christoph Sturm <m...@christophsturm.com> wrote:

Well it's a redis protocol for netty so it should not need a new thread.

The fact that the redis driver is built on Netty doesn't mean you can serve HTTP requests and talk to Redis in the same thread. If you perform any blocking operations from the webbit handler thread you're freezing up the entire web server so no other requests can be served until you're done.

If you are using the redis driver's asynchronous API you may fire off a redis request from the web thread, but how are you going to wait for the result from Redis without doing this on a separate thread?

Maybe you could be a little more specific what kind of demo code you're looking for?

Aslak

[Sam Pullara]

I'm the author of the netty based redis protocol referenced above. I'd love to help you get this working. The current netty codec found there doesn't have a full asynchronous client except when combined with Finagle but you could construct a netty pipeline and use it directly. Basically you would want to do something like:

https://github.com/spullara/redis-protocol/blob/master/netty/src/test/java/redis/netty/RedisClient.java

But use the asynchronous handlers. If you think it would be valuable, I could put together a client with a nice API if there was demand for it.

Sam

[Christoph Sturm]

Hello Sam,

If you could put together a client, that would be really helpful to me. I'm pretty new to netty, but if i can help build the client I'd love to.

-chris

[Sam Pullara]

There is a netty 3.5.2.Final based client in github.com/spullara/redis-protocol now. You'll need to do

mvn clean install -pl netty-client -am

To build it. It gives you asynchronous completion events and from there you can chain together work between Redis and Webbit. There is an example WebbitServer in the repository as well.

BTW, the client currently doesn't implement:

                    "MULTI", "EXEC", "DISCARD", // Transactions

                    "PSUBSCRIBE", "SUBSCRIBE", "UNSUBSCRIBE", "PUNSUBSCRIBE", // subscriptions

                    "AUTH" // authentication

As they are modal and I didn't get around to it.

Sam

[peter hausel]

On Saturday, January 12, 2013 9:45:30 PM UTC-5, Sam Pullara wrote:

There is a netty 3.5.2.Final based client in github.com/spullara/redis-protocol now. You'll need to do

mvn clean install -pl netty-client -am

To build it. It gives you asynchronous completion events and from there you can chain together work between Redis and Webbit. There is an example WebbitServer in the repository as well.

Hi Sam, I just checked out your webbit-redis example, it looks really cool! 

BTW, the client currently doesn't implement:

                    "MULTI", "EXEC", "DISCARD", // Transactions

                    "PSUBSCRIBE", "SUBSCRIBE", "UNSUBSCRIBE", "PUNSUBSCRIBE", // subscriptions

Would it be possible to share resources(like the underlying thread pools) between redis.netty.client.RedisClient and redis.client.RedisClient? What I mean is adding a constructor to both RedisClients that'd take an executor - that way one could use both clients for different purposes in a single webbit project while using a single thread pool. 

Thanks,

Peter

[Sam Pullara]

On Sunday, January 13, 2013 12:35:04 PM UTC-8, peter hausel wrote:

Hi Sam, I just checked out your webbit-redis example, it looks really cool! 

Thanks.

 

Would it be possible to share resources(like the underlying thread pools) between redis.netty.client.RedisClient and redis.client.RedisClient? What I mean is adding a constructor to both RedisClients that'd take an executor - that way one could use both clients for different purposes in a single webbit project while using a single thread pool. 

The executor in the blocking client is used specifically for ensuring correct ordering when using the Pipeline. It must be a single thread executor which will limit your scalability if you are going to share them with another system — it really isn't for pooling. In fact, I should probably set it up so that it isn't even created if you don't use asynchronous features in the blocking client. Another option would be to move to using my own queue and consuming a thread from a provided executor more in the style of netty though then I would need to implement the ListeningFutures as well.

BTW, why would you use both of them in the same application?

Sam

[peter hausel]

On Sunday, January 13, 2013 3:53:31 PM UTC-5, Sam Pullara wrote:

On Sunday, January 13, 2013 12:35:04 PM UTC-8, peter hausel wrote:

Hi Sam, I just checked out your webbit-redis example, it looks really cool! 

Thanks.

 

Would it be possible to share resources(like the underlying thread pools) between redis.netty.client.RedisClient and redis.client.RedisClient? What I mean is adding a constructor to both RedisClients that'd take an executor - that way one could use both clients for different purposes in a single webbit project while using a single thread pool. 

The executor in the blocking client is used specifically for ensuring correct ordering when using the Pipeline. It must be a single thread executor which will limit your scalability if you are going to share them with another system — it really isn't for pooling. In fact, I should probably set it up so that it isn't even created if you don't use asynchronous features in the blocking client.

I see - that makes sense. 

Another option would be to move to using my own queue and consuming a thread from a provided executor more in the style of netty though then I would need to implement the ListeningFutures as well.

I think that's a great idea.

 

BTW, why would you use both of them in the same application?

the main reason is being able to leverage redis.client.RedisClient's Pub/Sub support (right now I am using jedis for that)

Thanks,

Peter

[Sam Pullara]

>> BTW, why would you use both of them in the same application?
>
> the main reason is being able to leverage redis.client.RedisClient's Pub/Sub
> support (right now I am using jedis for that)

Ah, well maybe working on that directly would be more fruitful.
Especially since Netty would use far fewer threads to implement it.

Sam

> Thanks,
> Peter

[Sam Pullara]

Ok, pub/sub support is now in master. I have lightly tested it :) It is basically identical to the support in the blocking client so porting to try it out should be straight-forward. Would love your feedback.

Sam

[aslak hellesoy]

On Sun, Jan 13, 2013 at 2:45 AM, Sam Pullara <spul...@gmail.com> wrote:

There is a netty 3.5.2.Final based client in github.com/spullara/redis-protocol now. You'll need to do

mvn clean install -pl netty-client -am

To build it. It gives you asynchronous completion events and from there you can chain together work between Redis and Webbit. There is an example WebbitServer in the repository as well.

Your example WebbitServer seems to block the Webbit thread while talking to Redis. You should avoid doing this [1].

I have sent a pull request that corrects this [2].

Aslak

[1] https://github.com/webbit/webbit/wiki/Writing-HttpHandlers (Threading and blocking)

[2] https://github.com/spullara/redis-protocol/pull/12

[peter hausel]

On Sunday, January 13, 2013 5:46:16 PM UTC-5, Sam Pullara wrote:

Ok, pub/sub support is now in master. I have lightly tested it :) It is basically identical to the support in the blocking client so porting to try it out should be straight-forward. Would love your feedback.

Wow - that was fast! I will try it out and provide feedback. 

Thanks a lot for your work!

Cheers, 

Peter

[peter hausel]

On Sunday, January 13, 2013 6:40:34 PM UTC-5, Aslak Hellesøy wrote:

On Sun, Jan 13, 2013 at 2:45 AM, Sam Pullara <spul...@gmail.com> wrote:

There is a netty 3.5.2.Final based client in github.com/spullara/redis-protocol now. You'll need to do

mvn clean install -pl netty-client -am

To build it. It gives you asynchronous completion events and from there you can chain together work between Redis and Webbit. There is an example WebbitServer in the repository as well.

Your example WebbitServer seems to block the Webbit thread while talking to Redis. You should avoid doing this [1].

I have sent a pull request that corrects this [2].

Aslak

 

Hi Aslak,

I believe the current example is actually non-blocking already, since RedisClient returns a Promise https://github.com/spullara/redis-protocol/blob/master/netty-client/src/main/java/redis/netty/client/RedisClient.java#L144

so the actual call to Redis is made on another thread and then the callback (onSuccess) is invoked which executes on the Webbit thread.

The only blocking call here is 

  final RedisClient redis = RedisClient.connect("localhost", 6379).get();

 but that's happening outside of the event loop.

Sam, please correct me if I am wrong.

Thanks,

Peter

[aslak hellesoy]

On Mon, Jan 14, 2013 at 12:24 AM, peter hausel <peter....@gmail.com> wrote:

On Sunday, January 13, 2013 6:40:34 PM UTC-5, Aslak Hellesøy wrote:

On Sun, Jan 13, 2013 at 2:45 AM, Sam Pullara <spul...@gmail.com> wrote:

There is a netty 3.5.2.Final based client in github.com/spullara/redis-protocol now. You'll need to do

mvn clean install -pl netty-client -am

To build it. It gives you asynchronous completion events and from there you can chain together work between Redis and Webbit. There is an example WebbitServer in the repository as well.

Your example WebbitServer seems to block the Webbit thread while talking to Redis. You should avoid doing this [1].

I have sent a pull request that corrects this [2].

Aslak

 

Hi Aslak,

I believe the current example is actually non-blocking already, since RedisClient returns a Promise https://github.com/spullara/redis-protocol/blob/master/netty-client/src/main/java/redis/netty/client/RedisClient.java#L144

You're right - I just realised that myself and closed the PR. See my comment about synchronized though.

Aslak

[Sam Pullara]

I've reduced the synchronization down to just what is necessary to ensure proper ordering of responses. I think the chances of real contention are pretty unlikely as it just spans two enqueues, one to my local matching reply queue and the write to the channel in netty. As it is you can get hundreds of thousands requests+responses per second with a single connection.

Peter: you should pull master again. I'll try and do a release if I have time.

Sam

[peter hausel]

On Sunday, January 13, 2013 8:32:12 PM UTC-5, Sam Pullara wrote:

I've reduced the synchronization down to just what is necessary to ensure proper ordering of responses. I think the chances of real contention are pretty unlikely as it just spans two enqueues, one to my local matching reply queue and the write to the channel in netty. As it is you can get hundreds of thousands requests+responses per second with a single connection.

Peter: you should pull master again. I'll try and do a release if I have time.

Hi Sam, I just tested the netty based Pub/Sub feature and it seemed to work fine - thanks a lot!

Cheers,

Peter 

[Sam Pullara]

Great! If you run into any other API changes you would like go ahead and file them as issues.

Thanks,

Sam