I want to know what are the important files in (DB2, TDS, WAS, TDI, TIM) which we need to be aware of and there uses.
Though all the files are important and serves its purpose, i have listed few based on initial go to. In case of ITIM the important files would be enrole property files found inside itim installed directory \ data directory. This is where the connection properties, logging properties are all defined.
In case of TDS, the schema file ibmslapd.conf and those files found under etc folder are most important.
In case of TDI only the config file is important and for all these components
the log files are important to debug. TIM - trace /msg log. TDS ibmslapd.log and TDI - ibmdi.log and WAS - Systemout.log
Related
I tried to play around with Projected File System to implement a user mode ram drive (previously I had used Dokan). I have two questions:
Is this a read-only projection? I could not find anything any notification sent to me when opening the file from say Notepad and writing to it.
Is the file actually created on the disk once I use PrjWriteFileData()? From what I have understood, yes.
In that case what would be any useful thing that one could do with this library if there is no writing to the projected files? It seems to me that the only useful thing is to initially create a directory tree from somewhere else (say, a remote repo), but nothing beyond that. Dokan still seems the way to go.
The short answer:
It's not read-only but you can't write your files directly to a "source" filesystem via a projected one.
WriteFileData method is used for populating placeholder files on the "scratch" (projected) file system, so, it doesn't affect a "source" file system.
The long answer:
As stated in the comment by #zett42 ProjFS was mainly designed as a remote git file system. So, the main goal of any file versioning system is to handle multiple versions of files. From this a question arise - do we need to override the file inside a remote repository on ProjFS file write? It would be disastrous. When working with git you always write files locally and they are not synced until you push the changes to a remote repository.
When you enumerate files nothing being written to a local file system. From the ProjFS documentation:
When a provider first creates a virtualization root it is empty on the
local system. That is, none of the items in the backing data store
have yet been cached to disk.
Only after the file is opened ProjFS creates a "placeholder" for it in a local file system - I assume that it's a file with a special structure (not a real one).
As files and directories under the virtualization root are opened, the
provider creates placeholders on disk, and as files are read the
placeholders are hydrated with contents.
What "hydrated" is mean? Most likely, it represents a special data structure partially filled with real data. I would imaginge a placeholder as a sponge partially filled with data.
As items are opened, ProjFS requests information from the provider to allow placeholders for those items to be created in the local file system. As item contents are accessed, ProjFS requests those contents from the provider. The result is that from the user's perspective, virtualized files and directories appear similar to normal files and directories that already reside on the local file system.
Only after a file is updated (modified). It's not a placeholder anymore - it becomes "Full file/directory":
For files: The file's content (primary data stream) has been modified.
The file is no longer a cache of its state in the provider's store.
Files that have been created on the local file system (i.e. that do
not exist in the provider's store at all) are also considered to be
full files.
For directories: Directories that have been created on the local file
system (i.e. that do not exist in the provider's store at all) are
considered to be full directories. A directory that was created on
disk as a placeholder never becomes a full directory.
It means that on the first write the placeholder is replaced by the real file in the local FS. But how to keep a "remote" file in sync with a modified one? (1)
When the provider calls PrjWritePlaceholderInfo to write the
placeholder information, it supplies the ContentID in the VersionInfo
member of the placeholderInfo argument. The provider should then
record that a placeholder for that file or directory was created in
this view.
Notice "The provider should then record that a placeholder for that file". It means that in order to sync the file later with a correct view representation we have to remember with which version a modified file is associated. Imagine we are in a git repository and we change the branch. In this case, we may update one file multiple times in different branches. Now, why and when the provider calls PrjWritePlaceholderInfo?
... These placeholders represent the state of the backing store at the
time they were created. These cached items, combined with the items
projected by the provider in enumerations, constitute the client's
"view" of the backing store. From time to time the provider may wish
to update the client's view, whether because of changes in the backing
store, or because of explicit action taken by the user to change their
view.
Once again, imagine switching branches in a git repository; you have to update a file if it's different in another branch. Continuing answering the question (1). Imaging you want to make a "push" from a particular branch. First of all, you have to know which files are modified. If you are not recorded the placeholder info while modifying your file you won't be able to do it correctly (at least for the git repository example).
Remember, that a placeholder is replaced by a real file on modification? A ProjFS has OnNotifyFileHandleClosedFileModifiedOrDeleted event. Here is the signature of the callback:
public void NotifyFileHandleClosedFileModifiedOrDeletedCallback(
string relativePath,
bool isDirectory,
bool isFileModified,
bool isFileDeleted,
uint triggeringProcessId,
string triggeringProcessImageFileName)
For our understanding, the most important parameter for us here is relativePath. It will contain a name of a modified file inside the "scratch" file system (projected). Here you also know that the file is a real file (not a placeholder) and it's written to the disk (that's it you won't be able to intercept the call before the file is written). Now you may copy it to the desired location (or do it later) - it depends on your goals.
Answering the question #2, it seems like PrjWriteFileData is used only for populating "scratch" file system and you cannot use it for updating the "source" file system.
Applications:
As for applications, you still can implement a remote file system (instead of using Dokan) but all writes will be cached locally instead of directly written to a remote location. A couple use case ideas:
Distributed File Systems
Online Drive Client
A File System "Dispatcher" (for example, you may write your files in different folders depending on particular conditions)
A File Versioning System (for example, you may preserve different versions of the same file after a modification)
Mirroring data from your app to a file system (for example, you can "project" a text file with indentations to folders, sub-folders and files)
P.S.: I'm not aware of any undocumented APIs, but from my point of view (accordingly with the documentation) we cannot use ProjFS for purposes like a ramdisk or write files directly to the "source" file system without writing them to the "local" file system first.
How to make Websphere to automatically clean up temp folders during wach start or restart ?
I found out how to manually delete them. But can't ask the customer to do it. Is there some parameter or something that can be set in order to delete the cache/temp files automatically ?
You weren't specific about what cache or temporary files you wanted to delete, but in general, there is no WAS setting to do so. The logging system can be configured to roll log files over, but those aren't temporary files and typically you would want to keep them for some period of time for audit purposes. You also typically don't want to delete caches like the OSGi class cache, unless specifically told to do so by IBM support, so I would't suggest doing it on a server start/restart. The configuration repository uses temporary files that could be deleted on server start/restart. see this IBM KnowledgeCenter topic for details on the location of the files. Having said all that, if you're sure you know what files to delete, I'd suggest wrapping calls to the startServer or stopServer files with your own script(s). These are either batch files on windows platforms, or shell files on other platforms and shouldn't be modified by users. In your wrapper, simply delete the files and then call startServer.
Normally, after we create profiles both DMGR and Node, we have folder applications under path $DMGRPROFILE_HOME/config/cells/$cellName and installedApps under path $NODEPROFILE_HOME/.
All the applications to be deployed will be put into folder installedApps. And we can also see the same contents under the folder applications above. So my question is what's the difference between them? why does the websphere application server put such apps into folder applications besides installedApps?
what's more, for example, if i need to update one file named web.xml of my deployed application war file, do i have to update file under both path above?
Thanks in advance
The applications path under the Dmgr profile contains the files that have been deployed in the admin console.
The installedApps path under the Node profile contains those files after they've been synchronized out to each node. In most cases, this will be immediately after the deployment as well.
Deploying a single file
The safest practice would be to deploy a single file using the admin console, rather than editing it in-place on the filesystem:
The downside is that you have to enter the entire path to the server-deployed file name. e.g. webapp.war/WEB-INF/classes/com/yourcompany/project/package1/YourClass.class.
If you have a typo, it will deploy, but not where you wanted, and you might not notice it until your expected changes didn't take effect.
Direct edit on the filesystem
That said, it is faster to edit on the filesystem, so we do that at times especially for like JSPs. To do that, you need to edit the copy under the Node's installedApps directory. (The location is controlled by WebSphere variable APP_INSTALL_ROOT, which defaults to ${USER_INSTALL_ROOT}/installedApps.)
web.xml
web.xml, however, is different. If you edit that in installedApps, the changes won't take effect. Instead, you'll need to edit the one in a path something like:
$NODEPROFILE_HOME/config/cells/cellName/applications/earName.ear/deployments/applicationName/warName.war/WEB-INF
Or do it in the $DMGRPROFILE_HOME and then synchronize the node (either through syncNode.sh or through the admin console).
Either way, you'll then need to restart the enterprise application.
The file names seesm to point to our WAS data sources. However, we're not sure what is creating them and why there are so many. The servers didn't seem to crash. Why is WAS 6.1.0.23 creating these andy why aren't they being cleaned?
There are many files like these, with some going up to xxx.43.lck
DWSqlLog0.0.lck
DWSqlLog0.0
TritonSqlLog0.0.lck
TritonSqlLog0.0
JTSqlLog0.0
JTSqlLog0.1
JTSqlLog0.3
JTSqlLog0.2
JTSqlLog0.4.lck
JTSqlLog0.4
JTSqlLog0.3.lck
JTSqlLog0.2.lck
JTSqlLog0.1.lck
JTSqlLog0.0.lck
WAS uses JDK Logging and JDK logger creates such files with extension .0,.1 etc along with the .lck file so that the WAS runtime has a lock to these files that it writes to.
Cheers
Manglu
When I run my Eclipse RCP application, it creates a whole lot of directories in my $HOME/.eclipse directory. What is this?
I don't want the files there, how can I hinder them from getting there? The rational for this: the application must run very clean and only leave files at one specific location (not $HOME/.eclipse).
I'd figured it was controlled by osgi.instance.area so tried to set this to different values (a directory, #none, #noDfault etc...) but can't stop the application from creating directories in $HOME/.eclipse. -data and other arguments works as expected.
On my system the only thing that is stored in .eclipse is the Equinox Secure Storage. Here is the blurb on the doc page for that:
By default, secure storage is located in your home directory. On Windows that typically resolves to "C:\Documents and Settings\.eclipse\org.eclipse.equinox.security". This location is selected to allow multiple Eclipse-based applications to share the same secure storage.
If you would like to modify the location of the default secure storage, you can use the "-eclipse.keyring " runtime option. The is a path to the file which is used to persist the secure storage data.
Here is the online reference.