There are potentially 3 places in the web.config to modify to extend session timeout:
<!-- AUTHENTICATION CLIENT SESSION TIMEOUT
Specifies the number of minutes before Sitecore considers user authentication session tickets as expired.
This setting is only relevant for users logging in to Sitecore Client and when the Sitecore license has a ...
This is because the user is not flushed to MongoDB before SessionEnd. There are various reasons for this1, one being that you want to minimize the writes to MongoDB.
If you need to do something immediately you can manually flush the user session, but keep in mind that it can have side effects, so consider if it's absolutely required.
You can abandon the ...
What the error message means is that an object of type SearchResultItem could not be serialized as part of a session that is saved to a session store. There are two types of sessions used by Sitecore: private session (a.k.a. ASP.NET session) and shared session.
SearchResultItem is a class that is used to retrieve results when querying indexes ...
Automation worker running interval
The automation worker is the agent that processes automation state changes with a certain interval.
The first thing you should check is whether the automation worker is executed frequently enough. The default is to run it every 10 seconds, which is a good value for your needs. The setting is located in the configuration ...
You actually need to use a completely different pipeline: httpRequestProcessed. This pipeline executes after the session has been initialized.
The example below is taken from this blog by Brian Pedersen:
public class MyClass : HttpRequestProcessor
public override void Process(HttpRequestArgs args)
I think your sessions are being flagged as "robot". The most common cause for this, is forgetting to include VisitorIdentification on your main layout or main View file.
Additional info: https://stackoverflow....
Nick Hills started a project to enable Redis session state. You can find the details here:
It comes with a warning though: it is not supported by Sitecore!
Context from links above:
Out the box Sitecore offers 3 options for how to ...
We managed to solve this issue with the help of Sitecore and Microsoft:
Increase the min worker thread pool to xxx (where xxx should be greater than busy value on log)
Increase PollingTime to 30.
If above doesn't help upgrade the redis.stackexcahange to latest
And increase sync timeout 5k, connection time 10k and retry timeout 6k (should be ...
You've seen the "Optimize SQL Server Performance" section (Not Applicable to Azure SQL) at https://doc.sitecore.net/sitecore_experience_platform/setting_up__maintaining/xdb/session_state/walkthrough_configure_a_shared_session_state_database_using_the_sql_server_provider as it relates to Session state? While no silver bullet, that approach can improve ...
I have solved this issue. It was due to following the recommended enable/disable configuration guide (https://doc.sitecore.net/sitecore_experience_platform/setting_up__maintaining/xdb/configuring_servers/configure_a_content_management_server), which tells me to disable the following config files for a CM instance (this was occurring on a test environment ...
This is because xDB data is not committed until after the user's session ends.
This link contains a little more information on why that is: https://doc.sitecore.net/sitecore_experience_platform/setting_up__maintaining/xdb/session_state/session_state
Session state is a way of identifying contacts on your website by assigning them a unique session ID and by ...
Have you read the documentation of robots detection on the Sitecore doc-Portal?
Please check the SC_ANALYTICS_GLOBAL_COOKIE cookie. If your users have the IsClassificationGuessed key set to true, they would be ...
We are using MongoDB extensively at present, rather than SQL, for Azure deployments. The number of MongoDB collections required for Sitecore's xDB means we run our own MongoDB server cluster as it's much more cost-effective than PaaS solutions at the moment, and cheaper than equivalent SQL performance too. Azure PaaS DocumentDB is billed per-collection and ...
DISCLAIMER: This is possible, yet untested and is a very non-standard way of using xDB. It may potentially lead to strange errors and you'll have no idea where they are coming from or how to fix them. Use at your own risk.
End the session
First, you'll need to end the current session:
This will make ASP.NET start from scratch by ...
As you pointed out on your comment, this can be resolved by adding the missing types Sitecore.Analytics.SessionSerialization.config. You can see Sitecore comes with a bunch of these by default. Maybe they missed couple of them?
You should be able to patch this list, but you need to add a unique attribute to each node so they don't replace each other. e.g. (...
The problem is not the SessionIDManager. It enforces a maximum ID length of 80 characters and you shouldn't attempt to overcome this limitation, since some session state providers may rely on it.
The actual problem is Sitecore's current implementation of SessionDictionaryData. In Sitecore 8.0, this class used to store a dictionary object ...
Session locking only affects requests from a single source. It's more evident in load testing than it is in real world situations, since most of the traffic is coming from a single source, or relatively small number of sources. We have seen performance improvements in code using the ReadOnly attributes for controllers in a load test scenario, but these don'...
We have a similar requirement (1/2 million named users) and went the method of sitecore virtual users, and then assigning a specific sitecore role when they are authenticated. You can then authorise which sitecore items (pages) the role has access to.
I'd also suggest you look into implementing your own membership provider, however it does add complexity.
It is a permissions issue. You've not shared your actual connection string sharedsession but the end result will be the same, the account you're using to connect to SQL does not have sufficient permissions. My first course of action would be to attempt a connection string based on the sa account and see if the problem goes away.
Default SQL session state is ...
Hmm. You don't mention if you're using InProc or mongo session states. But it might not be relevant.
Sitecore overrides the default ASP.NET SessionIdManager manager - not entirely sure why. What is clear however, that it is in this puppy it is controlled, whether a new Session ID should be issued on timeout. So 2 things to try:
Add this attribute to your &...
In previous incarnations, when the Experience Platform was the DMS it was all very chatty to the SQL server; for busy sites it really hammered it and we saw a few customers just turn it off.
It's matured now and data is flushed through to the xDB in one hit after the users session times ends. Which might be 20 mins, or could be longer if you have a very ...
For a 6.5 update 1 using DMS you are unfortunately out of luck.
In 6.5, you cannot load balance the CM servers (you dont need it but just stated for completeness)
In 6.5 versions before update 4 you cannot use a shared session for DMS.
You cannot do much else than recheck the loadbalancer configuration for stickyness.
I don't believe robot detection is related to your problem. As you correctly suggested in the comments, changing session state provider should not affect robot functionality and the way it overrides session timeout.
This may be the root of your problem:
Note that we share the same session collection/db between test and uat environments.
From the sitecore site:
You must configure both private and shared session states. You can choose to use the same session provider for both but to ensure that the system can distinguish between them you must configure the correct attribute in the web.config and the Sitecore.Analytics.Tracking.config files.
After spending some time with the question asker, we determined the root issue.
The root problem statement was that Personalization wasn't occuring unless the user in the above example refreshed their browser.
The reason behind this is that the IdentifyAs() method was being called in a component that isn't executed until Sitecore has already determined ...
Closing the browser will not end/expire the session. That is done after user is idle for 30 mins time by default.
But you can adjust that from adjusting "timeout" parameter of the following tag in the web.config file
<forms name=".ASPXAUTH" cookieless="UseCookies" timeout="2" />
I have blog about ...
This is happening due to the fact that the session is being identified as a robot.
You need to solve the issue why the user is being identified as a robot. As an workaround, you may try the follow:
Increase the Session timeout from the Sitecore.Analytics.Tracking.config file. It is found in the App_Config/Include folder.
Search for the Analytics....
I had the exact same issue, and Sitecore Support confirmed a connection leaking bug in the SessionStateStoreProvider that causes unnecessary load on SQL server making it unresponsive.
It is fixed in Sitecore 8.2 update-2. Prior versions will require a ticket to request the patch.
Sitecore Support registered the issue as bug #98800 and my support ticket ...
You should definitely not be using InProc session, as @RichardSeal mentioned. Further, you need to clarify whether the site has 500k named users, or just takes 500k visitors per month.
Assuming the former (500k named users), you may want to look at virtual users because ASP.NET's authorisation and profile subsystems may not gracefully handle a volume this ...