Release candidate for 0.6.3

268 views
Skip to first unread message

Nick Martin

unread,
May 11, 2013, 1:24:22 AM5/11/13
to meteo...@googlegroups.com, meteo...@googlegroups.com
Hey all,

We're getting ready to release 0.6.3. I've built a release candidate for testing. Please give your apps a whirl with `meteor --release 0.6.3-rc1` and report back.

Thanks!
-- Nick

Changelog:

* Add new `check` package for ensuring that a value matches a required
  type and structure. This is used to validate untrusted input from the
  client. See http://docs.meteor.com/#match for details.

* Use Websockets by default on supported browsers. This reduces latency
  and eliminates the constant network spinner on iOS devices.

* With `autopublish` on, publish many useful fields on `Meteor.users`.

* Files in the 'client/compatibility/' subdirectory of a Meteor app do
  not get wrapped in a new variable scope. This is useful for
  third-party libraries which expect `var` statements at the outermost
  level to be global.

* When using the `http` package on the server synchronously, errors
  are thrown rather than passed in `result.error`

* The `manager` option to the `Meteor.Collection` constructor is now called
  `connection`. The old name still works for now.  #987

* The `localstorage-polyfill` smart package has been replaced by a
  `localstorage` package, which defines a `Meteor._localStorage` API instead of
  trying to replace the DOM `window.localStorage` facility. (Now, apps can use
  the existence of `window.localStorage` to detect if the full localStorage API
  is supported.)  #979

* Upgrade MongoDB from 2.2.1 to 2.4.3.

* Upgrade CoffeeScript from 1.5.0 to 1.6.2.  #972

* Faster reconnects when regaining connectivity.  #696

* `Email.send` has a new `headers` option to set arbitrary headers.  #963

* Cursor transform functions on the server no longer are required to return
  objects with correct `_id` fields.  #974

* Rework `observe()` callback ordering in minimongo to improve fiber
  safety on the server. This makes subscriptions on server to server DDP
  more usable.

* Use binary search in minimongo when updating ordered queries.  #969

* Fix EJSON base64 decoding bug.  #1001

* Support `appcache` on Chromium.  #958

Patches contributed by GitHub users awwx, jagill, spang, and timhaines.


Stephan Tual

unread,
May 11, 2013, 3:49:12 PM5/11/13
to meteo...@googlegroups.com, meteo...@googlegroups.com
Looks good so far. Will report back if anything explodes.

Tarang Patel

unread,
May 12, 2013, 9:36:00 AM5/12/13
to meteo...@googlegroups.com, meteo...@googlegroups.com
After a bit of thorough testing with websockets I've noticed a couple of issues with node-http-proxy. I use a proxytable to route between a normal meteor and an admin mode meteor.

Over time with websockets (which won't work via the proxy) a memory leak will build:

(node) warning: possible EventEmitter memory leak detected. 11 listeners added. Use emitter.setMaxListeners() to increase limit.
Trace
    at Socket.EventEmitter.addListener (events.js:160:15)
    at Socket.Readable.on (_stream_readable.js:663:33)
    at Socket.EventEmitter.once (events.js:179:8)
    at TCP.onread (net.js:527:26)

Which is probably related to why websockets aren't relayed through. I've opened an issue on the node-http-proxy on github.

Nick Martin

unread,
May 12, 2013, 5:07:25 PM5/12/13
to meteo...@googlegroups.com, meteo...@googlegroups.com
Hey Tarang,

What version of node-http-proxy? Older versions have known leaks on websockets. https://github.com/nodejitsu/node-http-proxy/blob/master/CHANGELOG.md

node-http-proxy should work OK with websockets. You may have to explicitly proxy them, though, depending on how your proxy script is set up. See https://github.com/meteor/meteor/blob/master/tools/run.js#L143

Cheers,
-- Nick


--
You received this message because you are subscribed to the Google Groups "meteor-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to meteor-talk...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

Stephan Tual

unread,
May 12, 2013, 5:44:42 PM5/12/13
to meteo...@googlegroups.com, meteo...@googlegroups.com
Right, found an issue. In the client console I see
WebSocket connection to 'ws://localhost/sockjs/308/nd2ean81/websocket' failed: Unexpected response code: 400 

... but when running the current version, right after starting meteor. Unfortunately, I don't know enough about meteor to understand where this comes from.

Stephan Tual

unread,
May 12, 2013, 5:45:29 PM5/12/13
to meteo...@googlegroups.com, meteo...@googlegroups.com
Meant of course, 'but not when running the current version'

Tarang Patel

unread,
May 12, 2013, 5:46:24 PM5/12/13
to meteo...@googlegroups.com, meteo...@googlegroups.com
I'm not too sure why this is happening my code is fairly simple. Its with the latest version (0.10.2). My proxy is simply:

var options = {
router: {
'adminmode' : '127.0.0.1:3000',
'.*\.adminmode' : '127.0.0.1:3000',
'admintest' : '127.0.0.1:3000',
'.*\.localhost-test\.co\.uk': '127.0.0.1:2000'
}
};

var server = httpProxy.createServer(options);

server.listen(80);

server.on('upgrade',function() {
server.proxy.proxyWebSocketRequest(req, socket, head, { host: '127.0.0.1', port: 3000 });
});

I also tried putting a console.log in the event in server.on('upgrade') but it doesn't even fire. 

Tim Haines

unread,
May 12, 2013, 7:18:42 PM5/12/13
to meteo...@googlegroups.com
Hey Nick,

Our app works fine on it.

Tim.
> --
> You received this message because you are subscribed to the Google Groups
> "meteor-core" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to meteor-core...@googlegroups.com.
> To post to this group, send email to meteo...@googlegroups.com.
> Visit this group at http://groups.google.com/group/meteor-core?hl=en.

David Glasser

unread,
May 13, 2013, 2:07:14 PM5/13/13
to meteo...@googlegroups.com, meteo...@googlegroups.com
Tarang, what version of Node are you using to run your proxy?
My observation has been that node-http-proxy is broken for proxying
websockets under Node 0.10. And a partial fix that was applied
recently to try to address this (incompletely) may have also broken it
under 0.8.
> "meteor-core" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to meteor-core...@googlegroups.com.
> To post to this group, send email to meteo...@googlegroups.com.
> Visit this group at http://groups.google.com/group/meteor-core?hl=en.

Nick Martin

unread,
May 13, 2013, 3:16:00 PM5/13/13
to meteo...@googlegroups.com, meteo...@googlegroups.com
Hi Stephan,

Hrm, thats a little odd. Does the app still work after this error message (that is, does it correctly fall back to long polling)? What browser are you seeing this on? And what platform are you running Meteor on?

I'd expect to get this message if an app was deployed behind a proxy that doesn't support websockets. In that case it should be harmless, and sockjs should just fall back to XHRs. However, the url is localhost, so I guess its not a deployed app. Are you running some sort of proxy or something as part of your setup?

-- Nick


Stephan Tual

unread,
May 13, 2013, 5:08:56 PM5/13/13
to meteo...@googlegroups.com, meteo...@googlegroups.com
Hi Nick, I'm running Nginx on top of osx latest. So yes, it's proxying. That said, on meteor 0621 I do not get the message. 

s

Sam Hatoum

unread,
May 13, 2013, 5:11:35 PM5/13/13
to meteo...@googlegroups.com, meteo...@googlegroups.com
Is the proxy limited to HTTP? I recall having to get websockets working on an Amazon ELB and I had to use TCP and not HTTP. 

Nick Martin

unread,
May 13, 2013, 5:55:11 PM5/13/13
to meteo...@googlegroups.com, meteo...@googlegroups.com
Ok, cool. Sounds like your proxy just doesn't support websockets, or is configured to enable them. This error should be harmless, and the app will continue to work with long polling. The error message is new because this release turns on websockets by default for apps.

Tarang Patel

unread,
May 13, 2013, 8:06:52 PM5/13/13
to meteo...@googlegroups.com, meteo...@googlegroups.com
Hi David,

I tried with node 0.8 and 0.10. I suppose with node 0.8 the partial fix caused the issue and with node 0.10 there is also the same memory build up. 

I saw your comments on the pull request and on the issue I created. I guess I'll have to dive in a little bit deeper to try and get this sorted as its quite an important issue. 

I'd rather it solved than trying to work around to moving back to XHR as with websockets i'm seeing a massive performance boost with the initial loading & overall latency is much much lower. So its definitely the way to go sooner rather than later. I'm not seeing the chrome crashes/glitches that occurred the last time meteor temporarily used websockets, which was quite a while back I think.

Tim Heckel

unread,
May 13, 2013, 9:52:33 PM5/13/13
to meteo...@googlegroups.com, meteo...@googlegroups.com
Any chance you could expose the branch on github? I cannot run meteor --release 0.6.3-rc1 while using mrt, and last time I was able to point my mrt smart.json to the release-0.6.2 branch...

THanks!

Tim Haines

unread,
May 13, 2013, 10:08:13 PM5/13/13
to meteo...@googlegroups.com, meteo...@googlegroups.com
There may be a way to run off the tag, but I think simply running
against the devel branch will get you everything that's in 0.6.3-rc1

Tim.

Nick Martin

unread,
May 13, 2013, 10:20:27 PM5/13/13
to meteo...@googlegroups.com, meteo...@googlegroups.com
Done. `release-0.6.3` branch. Needed to happen anyway according to our release process as we bump version numbers and such, I guess I had just skipped a step earlier =)

For mrt, I think you can just specify a tag name (or other commit-ish) instead of a branch name. All built releases should have a corresponding tag in release/, eg `release/0.6.3-rc1` 

Cheers,
-- Nick


On Mon, May 13, 2013 at 6:52 PM, Tim Heckel <timh...@gmail.com> wrote:

Avital Oliver

unread,
May 14, 2013, 3:59:49 AM5/14/13
to meteo...@googlegroups.com, meteo...@googlegroups.com
I've just released 0.6.3-rc2 (can be used with `meteor --release=0.6.3-rc2`, or on the 'release/0.6.3-rc2' branch). If you've wanted faster click events on mobile, take the new 'tap' event for a spin.

Changes:

* Support a new 'tap' event, which bypasses the click delay on mobile.
* Fix a bug with custom EJSON types that have arrays.

Andrew Wilcox

unread,
May 14, 2013, 6:44:22 AM5/14/13
to meteo...@googlegroups.com, meteo...@googlegroups.com

For mrt, I think you can just specify a tag name (or other commit-ish) instead of a branch name. All built releases should have a corresponding tag in release/, eg `release/0.6.3-rc1` 

 

Tim Heckel

unread,
May 14, 2013, 9:38:00 AM5/14/13
to meteo...@googlegroups.com, meteo...@googlegroups.com
I've run our app through its paces and things look great -- native websocket support on supported browsers through sockjs is fabulous. I have found no problems. Thanks!


On Saturday, May 11, 2013 12:24:22 AM UTC-5, Nick Martin wrote:

Avital Oliver

unread,
May 14, 2013, 3:14:07 PM5/14/13
to meteo...@googlegroups.com, meteo...@googlegroups.com
I just released 0.6.3-rc3 with a small fix on Opera.


David Glasser

unread,
May 14, 2013, 3:38:34 PM5/14/13
to meteo...@googlegroups.com, meteo...@googlegroups.com
.... and 0.6.3-rc4 fixes the Opera issue better :)

Tarang Patel

unread,
May 17, 2013, 5:56:29 AM5/17/13
to meteo...@googlegroups.com, meteo...@googlegroups.com
It looks like that websocket glitch is still there (originates from node-http-proxy) with 0.6.3.1. After about ~2 days of uptime it slowly builds up:

(node) warning: possible EventEmitter memory leak detected. 11 listeners added. Use emitter.setMaxListeners() to increase limit.
Trace
    at Socket.EventEmitter.addListener (events.js:160:15)
    at Socket.Readable.on (_stream_readable.js:663:33)
    at Socket.EventEmitter.once (events.js:179:8)
    at TCP.onread (net.js:527:26)

I'm not too sure what causes it to trigger though, it looks like if android is used it happens. With chrome/safari I can't seem to get it to work. We have an app that runs so one of our clients must have triggered it. 
I don't have a proxy or anything in the middle this time.

Avital Oliver

unread,
May 20, 2013, 2:09:15 PM5/20/13
to meteo...@googlegroups.com, meteo...@googlegroups.com
Tarang, could this be a issue with the way you are using node-http-proxy. We use node-http-proxy on production and are not hitting this issue. The code we use is more or less the same as https://github.com/meteor/meteor/blob/master/tools/run.js#L143

Tarang Patel

unread,
May 20, 2013, 2:45:50 PM5/20/13
to meteo...@googlegroups.com, meteo...@googlegroups.com
Hi Avital,

I've really really investigated this issue in as much depth as I can. The core issue is with node-js core on CentOS machines. There are a couple of issues that end up at the same problem:


Hopefully they patch it up soon :)

Tarang

Tarang Patel

unread,
May 20, 2013, 3:12:53 PM5/20/13
to meteo...@googlegroups.com, meteo...@googlegroups.com
This would also occur with a meteor instance, I meant it originates from the node-http-proxy used in meteor. Its only on CentOS though & only with node 0.10.

I think meteor uses 0.8 right? So it shouldn't be a problem for most users unless theres a bundled version being used.

On Monday, 20 May 2013 20:09:15 UTC+2, Avital Oliver wrote:
Reply all
Reply to author
Forward
0 new messages