Hi Azeez,
On Mon, Apr 23, 2012 at 12:16 PM, Afkham Azeez <[email protected]> wrote:
> This status flag is important because that is used for sending the cluster
> message which notifies other nodes to get an update.
>
Yes. But if the autoCommit is set to false, then status flag must be set to
false. If there are local changes in a autoCommit=false-node, I think
that's in fact not correct, so those may be reverted? In the current
implementation, autoCommit doesn't have any effect practically.
The periodically running sync() method, indeed has that check. What I'm
suggesting isn't about removing the status flag, but having a check like
the following (status is by default set to false).
if (autoCommit) { *status = depsync.commit(tenantId);* }
> If there are local changes in the node, and those changes were committed,
> that particular node has to inform other nodes to get updates. To reduce
> the unnecessary overhead on SVN servers, we don't blindly do svn updates
> anymore. svn updates are done only if some other node in the cluster
> actually detects a change in the local file system and commits it. Periodic
> SVN commits are no expensive because the client always checks whether there
> are local changes before committing. So calling svn commit even 1000s of
> times will not affect the server if there are no changes. However, svn
> update is different. It does a call to the SVN server & can cause the SVN
> server to crash.
>
Got the point. I think the issue here isn't about performance, but about
whether a node should commit even if autoCommit is set to false!
>
> In this particular scenario, the files in the slave should not change in
> the first place, if you need a master slave setup. That has to be handled
> at a different level outside the depsync.
>
> On Mon, Apr 23, 2012 at 10:31 AM, Hiranya Jayathilaka <[email protected]>wrote:
>
>> It looks like this task impl does not take the autoCommit flag into
>> account. This task is generally used in SLive where all the nodes are in
>> autoCommit mode. So not a problem in that environment. Azeez should be able
>> to explain more.
>>
>> Thanks,
>> Hiranya
>>
>> On Sun, Apr 22, 2012 at 10:39 PM, Kasun Gajasinghe <[email protected]>wrote:
>>
>>> Hi folks,
>>>
>>> $subject. I've set AutoCommit to false in slave nodes, and AutoCheckout
>>> true in master node. While I was debugging the code, it turned out that
>>> even the slave node executes commit command. Yes, the sync task respects
>>> the AutoCommit tag, but I'm seeing following code segment
>>> in CarbonDeploymentSchedulerTask in org.wso2.carbon.core package, which
>>> does a *commit **to determine whether the repo is changed or not.*
>>> I'm probably seeing a bug, but I'm not sure why this hasn't been
>>> detected all these months. But I'm seeing some issues because of this with
>>> the new metadata files. Svnclient can determine the status can without
>>> doing a commit.
>>>
>>> Is there a reason for this?
>>>
>>> private boolean doDeploymentSynchronization() {
>>> if (log.isDebugEnabled()) {
>>> log.debug("Running deployment synchronizer...");
>>> }
>>> boolean status = false;
>>> BundleContext bundleContext =
>>> CarbonCoreDataHolder.getInstance().getBundleContext();
>>> ServiceReference reference =
>>> bundleContext.getServiceReference(DeploymentSynchronizer.class.getName());
>>> if (reference != null) {
>>> ServiceTracker serviceTracker = new
>>> ServiceTracker(bundleContext,
>>>
>>> DeploymentSynchronizer.class.getName(),
>>> null);
>>> try {
>>> serviceTracker.open();
>>> for (Object obj : serviceTracker.getServices()) {
>>> DeploymentSynchronizer depsync =
>>> (DeploymentSynchronizer) obj;
>>> if(!isInitialUpdateDone || isRepoUpdateFailed){
>>> depsync.update(tenantId);
>>> isInitialUpdateDone = true;
>>> isRepoUpdateFailed = false;
>>> }
>>> * status = depsync.commit(tenantId);*
>>> }
>>> } catch (Exception e) {
>>> log.error("Deployment synchronization for tenant " +
>>> tenantId + " failed", e);
>>> } finally {
>>> serviceTracker.close();
>>> }
>>> }
>>> return status;
>>> }
>>>
>>>
>>> Thanks,
>>> --KasunG
>>>
>>> --
>>> *Kasun Gajasinghe*
>>> Software Engineer; WSO2 Inc.; http://wso2.com
>>>
>>> ,
>>> *email: **kasung AT spamfree wso2.com** cell: **+94 (77) 678-0813*
>>> *linked-in: *http://lk.linkedin.com/in/gajasinghe*
>>> *
>>> *blog: **http://blog.kasunbg.org* <http://blog.kasunbg.org>
>>>
>>> *
>>> twitter: **http://twitter.com/kasunbg* <http://twitter.com/kasunbg>
>>>
>>>
>>> _______________________________________________
>>> Dev mailing list
>>> [email protected]
>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>
>>>
>>
>>
>> --
>> Hiranya Jayathilaka
>> Associate Technical Lead;
>> WSO2 Inc.; http://wso2.org
>> E-mail: [email protected]; Mobile: +94 77 633 3491
>> Blog: http://techfeast-hiranya.blogspot.com
>>
>> _______________________________________________
>> Dev mailing list
>> [email protected]
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>>
>
>
> --
> *Afkham Azeez*
> Director of Architecture; WSO2, Inc.; http://wso2.com
> Member; Apache Software Foundation; http://www.apache.org/
> * <http://www.apache.org/>**
> email: **[email protected]* <[email protected]>* cell: +94 77 3320919
> blog: **http://blog.afkham.org* <http://blog.afkham.org>*
> twitter: **http://twitter.com/afkham_azeez*<http://twitter.com/afkham_azeez>
> *
> linked-in: **http://lk.linkedin.com/in/afkhamazeez*
> *
> *
> *Lean . Enterprise . Middleware*
>
>
--
*Kasun Gajasinghe*
Software Engineer; WSO2 Inc.; http://wso2.com
,
*email: **kasung AT spamfree wso2.com** cell: **+94 (77) 678-0813*
*linked-in: *http://lk.linkedin.com/in/gajasinghe*
*
*blog: **http://blog.kasunbg.org* <http://blog.kasunbg.org>
*
twitter: **http://twitter.com/kasunbg* <http://twitter.com/kasunbg>
*
*
_______________________________________________
Dev mailing list
[email protected]
http://wso2.org/cgi-bin/mailman/listinfo/dev
