Hello,
1) Resty-session is configured with an external store for session data. In this case, if session data is stored in redis or memecached, you will not have access to the cosocket API to read or write session data.
2) In it's default state, resty-session uses cookie based sessioning. Since you are calling save() on the session, you are attempting to generate a set-cookie header during an nginx phase that does not support any sort of response output (including headers).
Further, (in my humble opinion) it is ill advised to create a timer (light thread) per request in this way. It is unclear to me what you are trying to accomplish with this. It seems that you are persisting some sort of session state, which makes this operation best suited for a content_by_lua block.
If you provide more details on your goal, I or someone else on the list may be able to provide some alternatives that will be more performant and work around the issue you've described.
If your intention is to persist some data asynchronously, you'd want to use ngx.shared.DICT to create an in memory queue to push 'profileJSON' onto to be processed by a timer thread that reschedules itself in an init_by_lua block. Better still would be using an async queue. I highly recommend
https://github.com/pintsized/lua-resty-qless for a redis backed priority queue for async work. It is quite scalable as all nginx instances (across servers) would chip away at the work queue. I've used this library in high volume situations and it's yet to fail me.
Lastly, I'm not sure what 'profileJSON' is but the name leads me to believe it's a JSON serialized string. Your example seems to be reading this JSON out of headers. I sincerely advise against storing this type of data in HTTP headers. Simply put, it's not what headers are meant for. It is accident prone and may lead to truncated data. Further, a major problem with HTTP as a whole is the highly variable nature of headers. This is why HTTP2 (SPDY) has focused so much on an efficient header compression standard.
-Brandon