[
https://issues.apache.org/jira/browse/AXIS2-5049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13036575#comment-13036575
]
Deepal Jayasinghe commented on AXIS2-5049:
------------------------------------------
Well, if I understood it correctly, your approach will also have problems,
where this will incur a performance overhead on the actual service invocations,
where as, what I suggested just happens at deployment time
>>> It does not really matter whether it is deployment time or runtime, because
>>> hot-update happens at the runtime, so there might be so many other
>>> invocations going on in the system when you do the hot-update. There is
>>> only one Java process.
Because, lets say 1000 unique sessions / 1000 users, will be sending requests,
for each request from each of the user, the handler will check if the
SessionContext has valid service group context's and service contexts inside
that group, so there's some logic that needs to be executed to check whether
those contexts are valid and up to date against the ServiceGroups and Services.
>>. I agree, but we have so many these kind of logic processing in Axis2, so I
>>do not see a big issue there.But, it would be much better if we can come up
>>with a good approach.
So compared to that, what I suggested will only happen when a change to a
service group / service has occurred and then notified to the SessionContexts,
so 1 time 1000 notifications at once. But in what you suggested, there will
always be 1000 sessions (provided they are sending requests often), sending
1000 requests always to check up on a state that most probably have not changed
for a while.
>> Yes I agree, but there is a problem, when you do so many updates once whole
>> system might become the bottleneck, but if you do the handler approach it
>> will not process all of them once, hence, processing time is distributed. In
>> addition, the intended behavior of Observers is to perform light wight tasks
>> such as creating a RSS/Atom feed when a service get updated.
Anyway this is just my thoughts. If you think this is really needed (I do not
see a big reason to implement this feature) and your approach works fine we can
commit the code. In the real system hot-updates does not happen so frequently,
and in fact Axis2 does not recommend doing hot-update in production settings.
Deepal
> Axis2 Services / ServiceGroups Not Updating Properly When doing Hot-Update
> with Transport Session
> -------------------------------------------------------------------------------------------------
>
> Key: AXIS2-5049
> URL: https://issues.apache.org/jira/browse/AXIS2-5049
> Project: Axis2
> Issue Type: Bug
> Components: kernel
> Affects Versions: 1.5.4
> Reporter: Anjana Fernando
> Fix For: nightly
>
> Attachments: AXIS2-5049-Patch.txt
>
>
> The scenario is explained in the following points,
> * AxisService in Transport Session Scope.
> * Incoming request.
> * Create ServiceContext, ServiceGroupContext from AxisService and
> AxisServiceGroup and store it in SessionContext.
> * SessionContext contains fixed ServiceContext and ServiceGroupContext
> throughout Transport Session lifetime.
> * Changes to AxisConfiguratio wont be known by SessionContext, removing of
> services to service group, removing service group.
> * Removing Service Group, removing Service from service group must be
> communicated to SessionContext, so it can remove the necessory items from
> itself, and refresh the services / service groups in the next request.
> Because of the above problem, when doing hotupdate, a service which is in
> transport session will not be updated to the newly deployed service. Also,
> same for service groups, if a service group was removed and added again, the
> service group that is in the ServiceGroupContext will be the old service
> group.
> Cheers,
> Anjana.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
