Skip to content

Important Differences When Running In LightBlue

Colin Scott edited this page Aug 24, 2014 · 4 revisions

Hosting in LightBlue does not have identical behaviour to Azure hosting. The LightBlue hosts use the Standalone mode.

Role Behaviour

LightBlue will not automatically restart processes that terminate. This is primarily applicable to worker roles and the RoleEntryPoint based background process of web roles. These may terminate because the Run method exits (cleanly or otherwise) or because of an unhandled exception on a background thread.

The IIS Express hosted component of web roles is not exited if the background process exits and must be terminated separately.

Blob Storage

Blob Names

The maximum length of a blob name is determined by the maximum length of a Windows file system path (MAX_PATH which is 260 characters). Some of this path is consumed by the LightBlue directory structure. The maximum length permissible is not a fixed quantity and varies based on a number of factors. It can be calculated with:

    permissible length
        = MAX_PATH
            - Length of the AppData Local directory path (varies depending on username and OS)
            - 10 (length of the LightBlue directory)
            - 5 (length of the "blob" directory)
            - Length of the storage account name (between 4 and 25 characters)
            - 6 (length of the ".meta" directory)

(directory lengths specified include the path separator)

This is significantly shorter than the limit imposed by Azure or the Azure emulator (1024 characters).

Blob names may only contain characters that are valid in filenames. No attempt is made to encode invalid characters.

Directories

Although blob storage is strictly speaking flat Azure supports a virtual directory structure. LightBlue support for this is essentially non-existent. Support is planned for the v1 release.

Snapshots

No support is provided for blob snapshots. It is not currently anticipated that support will be added (PRs welcome).

Security

LightBlue does not implement security checks of any kind. Any security related parameters are ignored. Security code must be validated using the Azure emulator or actual Azure.

Concurrency

LightBlue does not perform file locking other than that provided by default by the file operations it uses. It does not attempt retry or graceful failure in the event that there are file concurrency issues. Concurrent modifications to a blob are not guaranteed to operate in the same fashion as such modifications would against the Azure emulator or actual Azure.

Clone this wiki locally