IBM BS029ML Self Help Guide - Page 171

Configuration Service, Deployment Service

Page 171 highlights

Caches may also be shared among all users or maintained on an individual user basis. As this can effect the legitimacy of the caches, we do not recommend modifying the sharing scope of any of the default cache instances. Clustered Portal environments can on occasion experience cache synchronization issues if the Dynamic Cache Replication Service (DRS) is not implemented. This typically manifests itself when modifications are made by the Portal Administrator, such as a resource ACL change, with the changes not immediately appearing to be propagated to all the servers participating in the Portal cluster. Under such circumstances, caches are stale and invalid, until they explicitly expire (dependant on each cache's lifetime setting). Restarting the entire cluster or individual cluster members in turn can temporarily overcome this difficulty. However, this should not be considered the fix for the root cause of the problem. Note: You must enable the DRS in your clustered environment in order to correctly validate the Portal caches. If DRS is not enabled, situations may arise where users have different views or different access control rights (ACLs), depending on which cluster member handles the user's request. It is, however, usual that session affinity is maintained to a specific cluster member for the life of the user's session. The only exception to this is failover. The issue is also dependant on the level of Portal Personalization offered to a user. As all caches eventually expire, you may accept that a stale cache is an anticipated occurrence and choose to live with the situation. Consult the Information Center for additional parameters that can be modified. Configuration Service Several attributes that influence Portal performance are defined under the Configuration Service. Among the most important settings are the persistent session options that offer an authenticated portal user the ability to return to their last visited page from the time of their last session. However, there is a significant impact in enabling this functionality, as the state must be persisted to the Portal database. In most cases, disabling this feature is acceptable, as Portal navigation is more than intuitive for a user. The Configuration Service also holds the configuration properties for Web Services for Remote Portlets (WSRP) services. shows the default and recommended values for the Configuration Service. Table 5-18 Configuration Service Parameter Default value persistent.session.level 0 persistent.session.option 0 timeout.resume.session false Recommended value May need to be changed. See InfoCenter. May need to be changed. See InfoCenter. May need to be changed. See InfoCenter. Consult the Information Center for additional parameters that can be modified. Deployment Service Although not strictly related to Portal performance, the Deployment Service contains several important properties. If Portal is deployed in a cluster, then the was.notification.timeout (in seconds) can be increased to extend the period of time the underlying WebSphere Application Server will wait before timing out from performing the deployment task of any new portlets (worst case scenario). This value may have to be increased for large scale Portal Chapter 5. WebSphere Portal runtime and services 157

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  • 32
  • 33
  • 34
  • 35
  • 36
  • 37
  • 38
  • 39
  • 40
  • 41
  • 42
  • 43
  • 44
  • 45
  • 46
  • 47
  • 48
  • 49
  • 50
  • 51
  • 52
  • 53
  • 54
  • 55
  • 56
  • 57
  • 58
  • 59
  • 60
  • 61
  • 62
  • 63
  • 64
  • 65
  • 66
  • 67
  • 68
  • 69
  • 70
  • 71
  • 72
  • 73
  • 74
  • 75
  • 76
  • 77
  • 78
  • 79
  • 80
  • 81
  • 82
  • 83
  • 84
  • 85
  • 86
  • 87
  • 88
  • 89
  • 90
  • 91
  • 92
  • 93
  • 94
  • 95
  • 96
  • 97
  • 98
  • 99
  • 100
  • 101
  • 102
  • 103
  • 104
  • 105
  • 106
  • 107
  • 108
  • 109
  • 110
  • 111
  • 112
  • 113
  • 114
  • 115
  • 116
  • 117
  • 118
  • 119
  • 120
  • 121
  • 122
  • 123
  • 124
  • 125
  • 126
  • 127
  • 128
  • 129
  • 130
  • 131
  • 132
  • 133
  • 134
  • 135
  • 136
  • 137
  • 138
  • 139
  • 140
  • 141
  • 142
  • 143
  • 144
  • 145
  • 146
  • 147
  • 148
  • 149
  • 150
  • 151
  • 152
  • 153
  • 154
  • 155
  • 156
  • 157
  • 158
  • 159
  • 160
  • 161
  • 162
  • 163
  • 164
  • 165
  • 166
  • 167
  • 168
  • 169
  • 170
  • 171
  • 172
  • 173
  • 174
  • 175
  • 176
  • 177
  • 178
  • 179
  • 180
  • 181
  • 182
  • 183
  • 184
  • 185
  • 186
  • 187
  • 188
  • 189
  • 190
  • 191
  • 192
  • 193
  • 194
  • 195
  • 196
  • 197
  • 198
  • 199
  • 200
  • 201
  • 202
  • 203
  • 204
  • 205
  • 206
  • 207
  • 208
  • 209
  • 210
  • 211
  • 212
  • 213
  • 214
  • 215
  • 216
  • 217
  • 218
  • 219
  • 220
  • 221
  • 222
  • 223
  • 224
  • 225
  • 226
  • 227
  • 228
  • 229
  • 230
  • 231
  • 232
  • 233
  • 234
  • 235
  • 236
  • 237
  • 238
  • 239
  • 240
  • 241
  • 242

Chapter 5. WebSphere Portal runtime and services
157
Caches may also be shared among all users or maintained on an individual user basis. As
this can effect the legitimacy of the caches, we do not recommend modifying the sharing
scope of any of the default cache instances.
Clustered Portal environments can on occasion experience cache synchronization issues if
the Dynamic Cache Replication Service (DRS) is not implemented.
This typically manifests itself when modifications are made by the Portal Administrator, such
as a resource ACL change, with the changes not immediately appearing to be propagated to
all the servers participating in the Portal cluster. Under such circumstances, caches are stale
and invalid, until they explicitly expire (dependant on each cache’s lifetime setting). Restarting
the entire cluster or individual cluster members in turn can temporarily overcome this difficulty.
However, this should not be considered the fix for the root cause of the problem.
As all caches eventually expire, you may accept that a stale cache is an anticipated
occurrence and choose to live with the situation. Consult the Information Center for additional
parameters that can be modified.
Configuration Service
Several attributes that influence Portal performance are defined under the Configuration
Service. Among the most important settings are the persistent session options that offer an
authenticated portal user the ability to return to their last visited page from the time of their
last session. However, there is a significant impact in enabling this functionality, as the state
must be persisted to the Portal database. In most cases, disabling this feature is acceptable,
as Portal navigation is more than intuitive for a user. The Configuration Service also holds the
configuration properties for Web Services for Remote Portlets (WSRP) services. shows the
default and recommended values for the Configuration Service.
Table 5-18
Configuration Service
Consult the Information Center for additional parameters that can be modified.
Deployment Service
Although not strictly related to Portal performance, the Deployment Service contains several
important properties. If Portal is deployed in a cluster, then the was.notification.timeout (in
seconds) can be increased to extend the period of time the underlying WebSphere
Application Server will wait before timing out from performing the deployment task of any new
portlets (worst case scenario). This value may have to be increased for large scale Portal
Note:
You must enable the DRS in your clustered environment in order to correctly validate
the Portal caches. If DRS is not enabled, situations may arise where users have different
views or different access control rights (ACLs), depending on which cluster member
handles the user's request. It is, however, usual that session affinity is maintained to a
specific cluster member for the life of the user’s session. The only exception to this is
failover. The issue is also dependant on the level of Portal Personalization offered to a user.
Parameter
Default value
Recommended value
persistent.session.level
0
May need to be changed. See
InfoCenter.
persistent.session.option
0
May need to be changed. See
InfoCenter.
timeout.resume.session
false
May need to be changed. See
InfoCenter.