This project is read-only.

Multitenancy vs multiple sites: mobile client odd behavior

Topics: Installing Orchard
Sep 8, 2013 at 10:11 PM
It may or may not be related to multitenancy, but still it remains the most important factor in my scenario.
I'm using 1.7.1 on Azure Web Sites & SQL Databases and I am testing two scenarios to reach the same objective. On one scenario I have 3 separate Orchard sites, each with a singletenant Orchard installation. The other scenario has 1 Orchard multitenant site, with the main tenant and 2 additional tenants. I am using the default settings as I did not heavily configured Orchard.

If I access any site, any of the 3 singletenant or any of the 3 multitenant site, from IE or Chrome on PC everything works perfectly.
If I access any site of the 3 singletenant site, from my W8 device everything works perfectly.
If I access the main/default site of the 3 multitenant site, from my W8 device everything works perfectly.
If I access any site of the 2 additional multitenant sites, from my W8 device I always receive a 500 internal server error.

At first I reset the theme of the multitenant sites, from the Terra theme to the default one, but it does not seem to be a problem with the theme.
I tested the scenario from scratch a couple of times with fresh db but with no difference: it seems the mobile browser has some issues with Orchard sites in multitenancy but I did so little after the tenant setup that is really difficult to analyze the situation.

Any advice is really appreciated: I am trying to understand the issue in order to get over it but as it a personal project I might consider to stick with the 3 singletenant sites if multitenancy is too difficult to handle as an Orchard newbie.
As I would like to host the sites on Azure that could become very expensive.
Sep 8, 2013 at 10:30 PM
What is the exception? 500 gives no information beyond "something went wrong on the server". You need to give more information than that, in the form of at least a stack trace (as can be found in app_data\logs).
Sep 8, 2013 at 11:17 PM
Agreed, the logs seems to report transient exception that, at least initially, do match the test time interval. But, as they are transient, I am not able to understand if they are relevant to my case or not.
2013-09-08 20:20:00,860 [13] NHibernate.AdoNet.AbstractBatcher - Could not execute command: SELECT * FROM dday_Settings_ShellDescriptorRecord
System.Data.SqlClient.SqlException (0x80131904): Invalid object name 'dday_Settings_ShellDescriptorRecord'.
   at System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection, Action`1 wrapCloseInAction)
   at System.Data.SqlClient.SqlInternalConnection.OnError(SqlException exception, Boolean breakConnection, Action`1 wrapCloseInAction)
   at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj, Boolean callerHasConnectionLock, Boolean asyncClose)
   at System.Data.SqlClient.TdsParser.TryRun(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj, Boolean& dataReady)
   at System.Data.SqlClient.SqlCommand.RunExecuteNonQueryTds(String methodName, Boolean async, Int32 timeout)
   at System.Data.SqlClient.SqlCommand.InternalExecuteNonQuery(TaskCompletionSource`1 completion, String methodName, Boolean sendToPipe, Int32 timeout, Boolean asyncWrite)
   at System.Data.SqlClient.SqlCommand.ExecuteNonQuery()
   at Microsoft.Practices.EnterpriseLibrary.WindowsAzure.TransientFaultHandling.SqlAzure.ReliableSqlConnection.<>c__DisplayClassc`1.<ExecuteCommand>b__a() in :line 0
   at Microsoft.Practices.TransientFaultHandling.RetryPolicy.ExecuteAction[TResult](Func`1 func) in :line 0
   at Microsoft.Practices.EnterpriseLibrary.WindowsAzure.TransientFaultHandling.SqlAzure.ReliableSqlConnection.<>c__DisplayClassc`1.<ExecuteCommand>b__9() in :line 0
   at Microsoft.Practices.TransientFaultHandling.RetryPolicy.<>c__DisplayClass1.<ExecuteAction>b__0() in :line 0
   at Microsoft.Practices.TransientFaultHandling.RetryPolicy.ExecuteAction[TResult](Func`1 func) in :line 0
   at Microsoft.Practices.TransientFaultHandling.RetryPolicy.ExecuteAction(Action action) in :line 0
   at Microsoft.Practices.EnterpriseLibrary.WindowsAzure.TransientFaultHandling.SqlAzure.ReliableSqlConnection.ExecuteCommand[T](IDbCommand command, RetryPolicy retryPolicy, CommandBehavior behavior) in :line 0
   at NHibernate.SqlAzure.ReliableSqlCommand.ExecuteNonQuery() in c:\TeamCity\buildAgent\work\99f31db0d548c7b7\NHibernate.SqlAzure\ReliableSqlCommand.cs:line 80
   at NHibernate.AdoNet.AbstractBatcher.ExecuteNonQuery(IDbCommand cmd)
2013-09-08 20:20:00,875 [13] NHibernate.Util.ADOExceptionReporter - Invalid object name 'dday_Settings_ShellDescriptorRecord'.
dday is the prefix in the db of one of the tenants. The table do exist and I would exclude a SQL Database issue as I am not getting any exception from the browsers on PC.
In addition I renamed the existing log file to isolate the behavior and restarted the Azure web site: I constantly get 503 errors only from my WP8 device but nothing new gets persisted to the recreated log file.
Where I can find any other relevant information?
Sep 8, 2013 at 11:50 PM
Looks like the tenant doesn't even start. So you're saying that from a desktop browser, with an empty cache, it works, but not from a phone?
Sep 9, 2013 at 6:32 AM
This morning I cleaned the PC cache and restarted the site. I now experience a consistent behaviour (good) from the devices as I am not able to access any tenant (bad).
A new log file has been created in the App_Data/Logs folder but it is empty. The diagnostics I collect from the Azure Web Site report the 500 error in response to my requests.
What works is an attempt to access the dashboard for the tenants, while the tenant site always returns 500 error or similar.
Sep 9, 2013 at 6:44 AM
Does it say anything about the 500 other than the error code? What about the front-end for the default tenant?
Sep 9, 2013 at 8:45 AM
What is consistent is that any request to the base site (or main tenant) works from any client.

I am able to access the admin dashboard of the tenant (/something) by direct url. I have to submit the credentials of the base/main tenant admin, the ones I submitted during tenant setup do not seems to work. I access the tenant specific dashobard and after that I am able to access the tenant site I was getting 500 error just few seconds before.
I checked and the tenants are using different prefixes for the objects in the database.

The behaviour is really odd.
Sep 10, 2013 at 2:36 AM
Does Azure say anything about the 500 other than the error code?
Sep 11, 2013 at 9:32 AM
Not at all, and it is strange nothing is reported in the empty log files.
Is there a way that the Web Site diagnostic/logging configuration on the Azure Web Site could influence/override the way Orchard writes the stack trace in the app_data\logs folder?
Sep 11, 2013 at 7:29 PM
Can you set custom errors to off, to see if you can at least get a proper error message?