tumblr / colossus Goto Github PK

I believe right now only the http request parser has it.

Basically for http connections using http 1.0, only one request per connection is allowed so we should always automatically close the connection after the first request is complete. This used to be handled by the onWrite field of Completion, but that's gone now.

I see three possible options right now:

1. Implement the OnWriteAction as a trait on the Response type. So HttpResponse could extend the trait, and then use it to disconnect.
2. Implement a Typeclass for post-write actions
3. Create a HttpService that extends ServiceServer which is used by the DSL, which overrides processRequest to simply do the check before it hands the request off to the user.

3. is probably the best solution, since it's something tied to the codec and isn't particularly designed to be overridden by users. We actually used to do this, so bringing it back would be pretty simple.

This is a new layer that sits in-between the core and service layer, and will generalize some functionality that is currently in the service layer. It will handle the semantics of decoding raw data into input messages, and vise versa for outgoing messages.

This will open the door for being able to write other higher-abstraction layers that don't have the same request/response semantics as typical services, such as multiplexed protocols (spdy, http 2.0) and streaming protocols (websocket).

Right now, if a Client cannot connect, it will try forever. We should introduce an optional upper limit which will disallow this behavior.

Just need to switch List -> Vector

We need to figure out how to transparently parse http chunks and only extract the actual chunk data, so that can be used by downstream parsers.

Ideally the StreamingHttpClass' exposed Source[DataBuffer] will output equivalent byte streams for an HttpResponse regardless if it is chunked or not.

Looks like we have an issue with streaming out responses....the issue being that we are not correctly removing the "currentStream" option when we are done streaming out the response. This is causing every subsequent request to fail to respond, as it will never begin to write the response.

We need to up our logging game. Just to have useful messages at various levels. This is purposefully vague, and we will flesh this out as we go.

Travis seems to be failing on these tests and they've never worked very well anyway. Ties in with #4

https://travis-ci.org/tumblr/colossus/builds/41615318

Most likely more timing issue stuff. I think we need to make a pass though all the tests and try to eliminate any place we're doing a thread.sleep or expecting something to happen within a short timeframe.

As part of the Server registration process, each Worker will create a Delegator. The Delegator, and its creation is the "first" instance of Colossus invoking custom code. Delegators are also where things like database connections, etc are created, and thus there is potential for hangups or blocks to happen.

In order to alleviate a potentially dead state, where Delegator creation hangs the system, a configurable timeout period should be introduced. That way, this state can be captured.

If two metric systems are created (can happen in the tests), they have actor name collisions, regardless if the two systems use different namespaces.

Let's start adding some basic bells and whistles:

• some kind of fluency around building http requests
• some kind of fold/foldwith functionality on StreamedHttpResponses
• ability to pull types other than Strings from headers
• maybe a few others will add comments and such as they get fleshed out

I'm pretty sure almost every page of the docs site will need updates, plus we need to add new stuff for streaming.

We should open a new docs branch to start working on changes

Add a counter to the ServiceServer to keep track of how many in-flight requests are being processed.

Currently, we do not support chunk encoding for streaming out responses.

Would be nice to have a Callback Scalatest matcher, to make testing Callback's a bit easier. I have begun working on an initial version with the following specs:

class CallbackEvaluateTo[T](f : T => Any) extends Matcher[Callback[T]]

Failure cases are if the callback never gets executed, or if the 'f' function, or the callback itself throw

passing cases are if the callback successfullly executes, and no exceptions are recorded. Any exceptions are caught, and the messages bubbled up via the MatchResult.

It never enters the "complete" state, and therefore, if you have a pipe of length 0, it will always return a Success(Done), but it's internal InfiniteBytePipe is never closed, since that only happens when the FiniteBytePipe's counter is incremented.

A quick solution is to special case 0, i.e: in the constructor of FiniteBytePipe, if length is 0, automatically complete the internal pipe.

Another solution is to always check the internal's pipe completion phase when returning the Success(Done)

Another solution is to introduce a NilBytePipe..meh

Additionally, FiniteBytePipe shouldn't allow negative numbers.

I don't think these are exceptional cases, and I would consider them part of the normal workflow, especially as it is expected that the pipe will be controlled/closed from outside of the controller.

We should just have additional PushResult states for this, instead of exceptions.

Easy to update, but we probably just want to think this through a bit before doing it.

Implementing a shutdown scheme in which current connections are not all suddenly killed. Details need to be fleshed a bit, but just to get the ball rolling..implementing a state with the following characteristics:

• accept no new connections
• allow drainage of all existing shorter lived connections
• for any longer lived connections, sending a proper disconnect

Details to follow as we get closer to implementing this.

Right now the built-in service metrics for request/latency etc cannot be configured. For example you can't change which percentiles are reported for latency.

Right now total counts on rates are not being reported in metrics.

If an AsyncServiceClient fails to connect, a race condition can arise where the underlying Worker will send the AsyncServiceClient's proxy actor a "MessageDeliveryFailed", which in turn the Proxy will send back to the Worker.

Just need a function that returns the ClientConfig. Should be straightforward.

Right now the shared interface for the load balancing client has it's own implementation for generating retry permutations. This is no longer required since the load balancer should be able to bind to the worker and then send actor messages to itself.

Looks like a timing issue in the test, since the test is basically doing some thread.sleeps. Need to fix it to make it more deterministic.

Right now when starting a service server or client, there's no way to configure the codec that's created. This is largely because the codec is created by the implicitly provided CodecProvider. This hasn't really been an issue since most codecs have no configuration right now, but that definitely will be changing soon.

We need to have an external configuration system in place. Configuration options right now for the Server are fairly small, but will grow.

running the following code logs error

import colossus._
import service._
import protocols.http._
import UrlParsing._
import HttpMethod._

object Main extends App {

  implicit val io_system = IOSystem()

  Service.become[Http]("http-echo", 9000){
    case request @ Get on Root => request.ok("Hello world!")
    case request @ Get on Root / "echo" / str => request.ok(str)
  }
}

[INFO] [11/29/2014 16:41:57.728] [iosystem-server-dispatcher-6] [akka://iosystem/user/http-echo] name: Bound to port 9000
[ERROR] [11/29/2014 16:42:07.649] [iosystem-server-dispatcher-5] [akka://iosystem/user/iosystem-manager/worker-1] worker received message CheckTimeout for unknown item 1

Right now, when reading a request or producing a response, the entire object must be loaded in memory before it can be used. This isn't really a big deal for small requests, but if we wanted to build, say, an image CDN, the service would need to load the entire image into memory before sending it back.

So we need to add support for streaming responses. This would mostly involve changing how the DataBuffer works, probably by turning it into a trait and having a callback for "more data is ready".

Right now there's really no way to gracefully shutdown a Server. We can close individual connections gracefully, but we should be able to have Servers stop listening for new connections while properly waiting for open connections to either close on their own or timeout.

I am developing a Mongo codec for Colossus. As you might already know most of the requests to MongoDB don't return a response. Is there a way to manage this workflow. Maybe a callback which is called after request is sent?

This is stemming from the fact that if a service client loses its connection and attempts to reconnect, it cannot receive worker messages during that time and gets a new id each time it reconnects. We need to change this so a service client stays bound to the worker the whole time and has only 1 id for its entire lifetime.

Right now we don't support it at all and the only way to avoid it is to use http 1.0.

We don't need streaming for this, just modify the parser to handle the chunks.

Is there any plans to support SSE / Websocket ?

The proxy actor is stashing messages before the client is connected, when it should actually be sending them. This is happening because right now the client doesn't receive the connection id from the worker until it's connected.

In situations where the client is unable to connect and fail-fast is enabled, the proxy actor just indefinitely holds onto the messages when it should be immediately failing the requests

Instead, the proxy should get the id when the client is bound to the worker, so messages can be forwarded before the connection is established.

Right now service clients don't fully handle timing out requests. Part of the issue is that it's not very clear how we should react to sent requests that have timed out. Most likely the only solution will be to kill the connection, but it's not clear if we should treat that the same way we treat unexpected disconnects.

While reading the code, comment has not been updated in Server.ConnectionVolumeState.
"TimeoutConfig.highWatermarkPercentage" should be “ServerSettings.highWatermarkPercentage”.
Line #128 of Server.scala

When using a http client connected to an http server, the server reports a parsing error, although the client still receives a good response. Most likely the issue is improperly encoding the http request.

This is due to how it handles the '-' character.

Currently, if Colossus cannot Bind to a port, it will spin in place. We need to add some options surrounding how to handle this. IE: retry count, fail on bind, etc. Ultimately Colossus should throw if it cannot bind.

I wonder if someone finished a mysql procotol. I did a project based on colossus and I need mysql protocol support. If someone finished it, please give me a hand, if not, I would do it. ^_^

If the LoadBalancingClient is used with the service DSL, both the DSL and the LoadBalancer call connect on the client, leading to two connections being opened and some really bizarre errors.

This should only end the Server.

We should probably make ClientConnections timeoutable. Right now, ClienConnections never time out, so you have a potential connection leak if an application is constantly creating new connections due to streaming or such.

Even though it's allowed in the http spec, apparently some parsers are really picky about this.

Oops. I broke it. I am also fixing it, and will have a PR out soon. The issue is that it is inserting an extra "/r/n" between the HTTP Header and the body. Good times were had by none.

So if a service throws an exception somewhere, such that the service layer catches it and kills the connection, the error metric is ticked but we currently are not actually logging the exception anywhere. The most direct way to solve this for now is to just log.error it, but this probably fits into a bigger issue of how to properly configure and handle logging across the system.