Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

HTTP response code 408 when using deliver (batch) #14

Open
chook opened this issue Jan 17, 2015 · 8 comments
Open

HTTP response code 408 when using deliver (batch) #14

chook opened this issue Jan 17, 2015 · 8 comments
Labels

Comments

@chook
Copy link

chook commented Jan 17, 2015

I'm getting:
java.io.IOException: Server returned HTTP response code: 408 for URL: http://api.mixpanel.com/track?ip=0

@arittr
Copy link

arittr commented Jan 21, 2015

hey @chook - what are you POST-ing over to us here? my thought is that either the batch is too big (over 50 events) or that there's something malformed being sent over. it's also possible the data payload is empty, which could cause the server to timeout waiting for the data to be sent. any of this seem possible? feel free to email me directly at drew [at] mixpanel if you want to send over the actual event data.

@chook
Copy link
Author

chook commented Feb 3, 2015

I've checked this, it appears we are sending data (not empty) and the data payload isn't too large.
Today I got Server returned HTTP response code: 408 for URL: http://api.mixpanel.com/engage

For a delivery of 29 people messages.

Is it possible we are hitting your API too fast and you are throttling us, resulting in 408 responses?

Furthermore, the way we do it is we add mixpanel changes we want to a queue, and have a daemon thread that drains it and send the requests - giving it the async nature we need.

Is it possible the JSONObjects created by the library should be delivered close to the time they are created and the problem lies in the time they spend in the queue?

@joeatwork
Copy link
Contributor

This is great information! (thanks for catching the reference to the new issue!)

@joeatwork joeatwork added the bug label Feb 3, 2015
@joeatwork joeatwork self-assigned this Feb 3, 2015
@joeatwork
Copy link
Contributor

@espiegel, you can follow progress on this issue here (rather than in #15 )

Thanks!

@joeatwork
Copy link
Contributor

My current suspicion is that the time required to encode and write the data in the library is too long. It shouldn't be an issue with the queue- the tracking endpoint should accept events up to five days old. My guess is that the time interval between opening the connection and writing data is too long. I'll try to reproduce it here.

URLConnection conn = endpoint.openConnection();
// My *guess* is that we're doing too much work here for large deliveries
postStream = conn.getOutputStream();
postStream.write(encodedQuery.getBytes());

@JensRantil
Copy link
Contributor

@joeatwork Follow-up; Were you able to reproduce this?

@joeatwork
Copy link
Contributor

@arittr or @yinfeiru - would you comment on this?

@arittr
Copy link

arittr commented Sep 18, 2015

thx @joeatwork - @JensRantil @ryanseams is going to take a look at this

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants