Conan locks packages while they are written to (e.g. install) or read (e.g. ???). Which operations cause a reading lock to be created?
The actual issue I have is the recurring problem lots of people seem to have, that locks are left behind by, I assume, interrupted conan processes. I would like to better understand what in conan creates locks.
Most Conan operations that read or write to the cache have a lock (implemented with fasteners library using system file locks). They should only be left behind if Conan crashes or is killed badly. If that is the case, there are several alternatives:
conan remove --locks should clean the files that implement the locks
removing the cache folder (like .conan in the user home) completely. After all it should be treated as a cache, and packages will be re-installed or re-built
The Conan cache is generally not designed for concurrency. These locks are very basic and will only help somehow for some specific concurrent operations (but will not support parallel jobs doing completely unrelated tasks, for that purpose it is necessary to use separate caches). There is the possibility with the cache_no_locks = True configuration, the locks system is completely disabled (and all operations should be strictly mutually exclusive and not concurrent)
Related
I want to make a little customization of the Share tier.
For this purpose I have prepared the relevant AMP file in which override some current properties. I know how to do it in another way, but I interested in that way.
Should I make any backups before deploying AMP?
Backups of what?
Your WAR file will be backed up, unless you specify a -nobackup command.
http://docs.alfresco.com/5.0/tasks/dev-extensions-tutorials-simple-module-install-amp.html
Although the question has already been answered, I would like to give my opinion, based on AMP development and deploying experience.
You have to do data/document backup on a regular basis, but you must do backup before installing AMP.
Some nodes properties can be added/removed/modified more than once especially during early AMP development stage. This can likely lead to Alfresco not starting up or some node being gone or unusable forever. I remember a plugin tutorial from Jeff Pott, mentioning a conservative (start with few properties, add later if needed rather than removing) approach when developing AMP, because a simple removed property could cause huge problems.
So...a backup before installing AMP is strongly recommended.
I'm having an issue with a web application I am responsible for maintaining.
The system experiences regular bugs, and our support vendors are always asking us to see if we can "replicate the error in UAT". This is obviously a reasonable request. A lot of the time, for various reasons (some of which are clear, some of which are not), these errors are not present in UAT. This lack of bug reproducability in a testing environment is adding huge amounts of friction to the bug resolution process.
There are 3 key pieces of our system architecture where these bugs are flaring (the CMS, the API layer, and the database). I am proposing we set up a system job that perpetually clones these 3 parts of the system in to a sandboxed test environment. This cloning would happen periodically (eg, once every 24 hours), and automatically.
Is there a technical term for this sort of environment? Is this an established method of helping diagnose system issues? Is there somewhere I can read up on the industry best practices for establishing something like this? Thanks.
The technical term for this kind of process is replication it is often done for some systems like databases, but normally not for testing purpose, but in order to increase available, so the replication is used as a failover spare.
An exact copy of a production system, with all the data is not you'll find often, due to the high demand on resources. Also at some points to two systems have to differ. Most systems (I know of) have tons of interfaces you just can't copy a complete system systems.
Also: you only need the copy of the production system when you actually debugging an issue. And if you are in the middle of that you probably don't want everything to go away and get replaced by a new copy.
So instead I would recommend to setup scripts that allows to obtain a copy of the relevant parts on demand.
Also you might want to consider how you might be able to modify your system to make it easier to setup a copy.
For example, when you have all the setup automated (with chef/docker or similar) you should be able to setup the same system again anywhere you want, so you now you just have to get the production data over.
Which is an interesting point. Production data often contains secret information (because it is vital to the business, or because it is personal data). You don't want this kind of stuff hang around in a test system everybody can access.
Factors designating a piece of code as critical section
As of I understand, process synchronization is employed using kernel data structures such as semaphores, to prevent concurrent access to the critical section of the code. In general I see definitions to be, "critical section is the piece of code that may access shared data (or) shared resources". So the questions are:
Shared data is a user space entity. Hence it is the responsibility of the user process to ensure consistency of its access.
I presume that concurrent access to resources by multiple processes is something that the kernel should take care. What sort of user level synchronisations are required there?
What are the factors by which a piece of code in user space program is decided to be a critical section.
You are mixing "kernel space/user space" with "critical section".
Kernel/User space only defines what kind of privilege does a process possess. If a thread is executing in user space it cannot access the physical memory directly. It has to go through kernel's virtual memory management.
On the other hand, critical section is part of the code that if executed by two processes in parallel could result in data corruption. This would be happening because of the fact that the code is accessing some shared resource.
Those two concept are independent. Critical section can be either in user space or kernel space. Some kind of synchronization is needed inorder for avoiding the corruption of a shared resource. Even in the case where two process/thread are running in kernel mode and want to access a shared resource, they need to apply some sort of synchronization mechanism(spinlocks or mutex).
I hope this explains helps.
Inter-process synchronization can be implemented by named synchronization objects. The Windws Synchronization Functions offer for example named mutexes and named semaphores.
See this answer for Linux.
Shared resources of a number of processes may for example be shared memory.
Using the term critical section the way done in the question is a bit misleading since
there are Critical Section Objects (Windows) dealing with thread synchronization.
I suspect you mean this more general since you explicitly note processes too.
However, any shared resource, be it shared memory or any other object shall be protected against concurrent access while being worked on.
I'm currently experimenting with Bazaar, trying to find a configuration that works well for the project I am currently working on with a team of developers. Our model is currently centralised but I am open to persuasion about changing this if I can see significant benefits. Despite advocating it, I will not be able to change the version control system... some people don't know what's good for them.
At present, the project is divided into tiers. It's a web project and consists of a data access layer, a business/domain logic layer and a web layer (and a bunch of other application level projects such as services that that sit on the domain).
At present I find a bazaar repository with a number of working trees in there, one for each of the tiers I have mentioned.
Question part 1
Is there a better alternative to using working trees inside a respository for each tier?
What I have considered:
Putting everything into one fat branch/working tree (I am told this was purposely avoided, because of the necessity to check out everything). Developers are creating their own local setups by checking out subsets of the multiple repositories. For example if I am working on one of the services, I checkout the service, the business layer and the data access layer to a local directory. In the current setup though, I can checkout a top tier application which doesn't affect anything else, make a change to it and commit it back, without checking out the entire repository, which is nearly 1GB in size.
What I would like to remedy:
The problem is really that my web tier is reliant on a version of the
business layer, which in turn is reliant on the data access layer.
With a project organised like this, I have no idea which version of
the business and data access layers were current for a given commit
on the web layer. This feels very bad to me. I want to be able to
checkout versions of our application relative to some commit to one
of the working trees. At the moment we are attempting to keep track of
this across all of the working trees with tagging, but it feels
pretty wrong to me.
Question part 2
If I branch one of these tiers for a release branch, and find that a change in the root of the branch needs to be in that release, how do I push only those required changes into the branch?
So assuming that the structure of one working tree (or possibly a real branch) exists for each of these projects, we would like to have a branch for each of these, which contain a version for the a particular release. So the website tree has a website_rls1 branch, which encapsulates the state of development for that particular release. General development for a later release is going to happen concurrently. So if one file out of many happens to be relevant to this release, I would like to merge that single file into my release branch. What is the preferred method of doing this. As I understand it, Bazaar does not support merging/pulling individual files.
What I have considered:
Just putting the files I want into my local checkout of the release branch and committing
What I would like to remedy:
Following this consideration is going to kill off version information for this file. I want to keep the version information in tact, but only merge in a subset of changes. I essentially want to push individual files up to the child branch, or something to the effect of.
Any thoughts appreciated.
#1 There are two plugins for managing multiple dependent bzr repositories:
https://launchpad.net/bzr-externals
https://launchpad.net/bzr-scmproj
They have different approaches and are suited to different situations.
You may also want to consider solving this problem at the build level. Use a continuous integration system like Jenkins and a dependency resolution system like Ivy or Maven. QA should be done using automated builds from this system so that bugs that are filed can refer to a particular build number which should include in its logs the versions of the various dependencies used to produce that build.
#2 There isn't really a way to do that merge. Bazaar doesn't track cherry-pick merges (yet). A better approach would be to make the original fix in the release branch and then merge it back into its parent.
Our company is using ClearCase for version control and as a medium to exchange code with sibling companies.
Some of these sites are planning to switch from CC to sub version.
Our site management is unenthusiastic about replacing our version control system.
A possible compromise is using the CM bridge by Clearvision, but I found next to zero customers reviews about this product.
I as especially interested the risks involved with using it.
Can anyone point out any such risks or possible difficulties associated with this product ?
All migration we did are from ClearCase to Subversion, without bridge or synchronization after the migration: it is simply not worth it.
The major risk for those migrations is to blindly import all the history, all the branches (including the ones locked and/or obsolete??? The documentation -- administration guide -- never mentions those kind of objects), all the labels (including the ones set only on 3 files, as opposed to full baselines set on all the files of an UCM component)
The differences are too important between the file-atomic operations of ClearCase and the repository-wide commits from Subversion to hope getting a complete mirror.
That also leads to the second major risk: adapting and evolving the set of practices around the VCS: having two in parallel means more work and a more error-prone environment to deal with two VCS.