I am using 6.5.6. On same desktop, running 2 nodes. One is patitioned, and one is client_only runing from IDE(eclipse). using 'CONTINUOUS' as deployment mode. Only one cache named 'partitioned'.
my issue is: I have a GridRunnable static class defined in class which start the 'client_only' node, and in the run method, only print 'hello world'. First time it runs fine. Hello string print out in 'partitioned' node. Keep 'partitioned' node running. Then I changed string to 'hello world x'. Save in my IDE, restart 'client_only', I saw 'partitioned' one still print 'hello world'. restart 'client_only' one again. this time it start printing 'hello world x' in my 'client_only' node now.
It looks it probably should deploy the code change in GridRunnable by itself. I am not sure anywhere I did wrong ? Please help !
For the GridRunnable to be redeployed automatically every time you change the code, you should change the deployment mode to SHARED. This means that once all cluster members that initiated the deployment are gone, the closure will be undeployed - in your case it is the CLIENT_ONLY node.
However, the same will apply to the data residing in caches - it will be undeployed, as well and the cache will be cleared. To avoid it, you should include the data you plan to cache in the classpath of each data node. Since classes on the local classpath do not get undeployed, the caches will not be cleared in this case.
Related
When monitoring memory using the :C XXXX option, the memory values do not show when debugging. You can monitor up to 4000 characters by using the :C option when monitoring memory:
I have ran into this problem twice now. I am using IBM Rational Developer for i Version: 9.6.0.0, with the Java JDK/JRE v8u45.
Here are the values when debugging, and my data structure definition:
dcl-ds dsSQL qualified inz;
fullStmt varchar( 9360 ) inz;
end-ds;
Once I click on the element, all I see is ``. There is nothing in the value but that, but you can clearly see that dsSQL.fullStmt is not empty. I use this option daily and 99.99% of the time it works fine. I have to restart a million times, reset RDi to start with -c and recompile the program over and over to get it to work right.
Anyone have any idea how to fix this? I would give you the 'Error Log' but it is constantly filled and nothing in there seems to point to that issue. When adding or looking at that variable during debug, no errors are thrown.
You probably want to update to the latest 9.6.0.6 release. They have fixed at least a few memory problems with the debugger between your release and the latest.
https://www-01.ibm.com/support/docview.wss?uid=swg27038481
i wanted to implement an hot-reload feature in my app.
Basically when i change a file that returns a value i want it to be working on my running application.
This involves some require.cache knowledge that maybe i got wrong,
i've found a small repo that i thought it could help me with no chance.
The repo is clear-module and i prepared a small example on top of it
git clone git#bitbucket.org:giggioz/test-clear-module.git
install the modules with
npm i
and then run it with
node index.js
This code prints every 500ms a value.
This value comes from a delegate.
My Issue
If i change the value returned by get-points.js while the code is running it does not do anything... i would expect a change, right?
Thanks for your help!
Somehow I get a problem, if I call an application twice or several times but only one instance should be running (which is desired).
First some (probably necessary) background information:
working on MAC OS X El Capitan (10.11.6)
I've got an Application made by node.js, electron and build by "npm build -m" (let's call it APP.app)
I installed the application App.app into program-folder by opening the built dmg-file and move it into the program-folder
Then I start the application App.app by click on the App.app-icon in program-folder
The application starts with a visible Window and also has an hidden background process running
If I close the visible Window, the App.app-Icon remains in the dock (which is okay, since the background-process is still running)
Now (and this is the difference to the windows build and running in windows), if I click again on the App.app-Icon in the program-folder, I only get a focus on the already running application INSTEAD of opening the window and close the old application (I can see te focus switch/activation by the switching menu name beside the apple-logo on top of the screen; it becomes "App")
the closing of the previous running instance is defined in electron code in the init-method as follows:
var shouldQuit = app.makeSingleInstance(function (commandLine, workingDirectory) {
console.info('starting new instance');
initInternal(commandLine);
// Someone tried to run a second instance, we should focus our window.
var windows = options.closeWindowsOnRestart ? Browser.getAllWindows() : appWindows.slice();
windows.forEach(function (val, index) {
val.close();
});
readyCallback();
});
So, I did some homework and could figure out following:
my App.app-icon-click should look something like open /Applications/App.app
with this, I get the same problem as descriped above if I call it again (it only focusses the already opened window)
Now comes the funny part. If I open the application by calling directly /Applications/App.app/content/MacOS/App.app the old application-instance is closed and new App.app-application is started
I read through open-manual and could figure out, that if I use the -n-flag, the application starts succesful a new instance, too. (open /Applications/App.app -n)
I was wondering WHY? Do you have any clues? What is the difference between open and directly call of the application?
I suggest that the info.pklist in App.app-package is making the open-call different to the direct call of App.app.
BTW:
Unfortunately I already tried to add try-catch-blocks to debug the problem, but open does not give an output to terminal, it just opens the call whereas the direct call does not throw an error and everything works fine.
Anyway, I believe it's more a MAC OS X problem than an App.app-problem.
Hopefully there's somebody with same problems and a solution for me
Don't hesitate to ask for more details, if needed.
Short Version:
open starts the application with the LaunchService (and possible
added launch-parameters in info.plist)
whereas direct call of the
application just starts the application iself without any other
launch-options
*Long Version *
I read through the open manual (man open; Source: https://developer.apple.com/legacy/library/documentation/Darwin/Reference/ManPages/man1/open.1.html) and could figure out, that "the default application as determined via LaunchServices is used to open the specified files" if you click on an item.
So I read through the LaunchService-documentation and could figure out following:
"Opening Items by File-System Reference [...] default way:
If the designated item is an application: [...]
If the application is already running, it is activated (brought to the front of the screen) and sent an 'rapp' (“reopen
application”) Apple event."
(Source: https://developer.apple.com/library/content/documentation/Carbon/Conceptual/LaunchServicesConcepts/LSCTasks/LSCTasks.html#//apple_ref/doc/uid/TP30000999-CH203-TP9)
This reflects exactly my watching that if I click on the icon the second time, the app is just focussed/activated.
Thus I need the possibility to tell the application to open a new instance (oapp-event) instead of activating the already opened application (rapp-event)
Further reading lead me to following informations:
"Launch Options When opening an application (whether by itself or to
open one or more documents or URLs), you can specify various launch
options to control the manner in which it is launched or activated.
These can include: [...] Whether to launch a new instance of the
application, even if another instance is already running"
(Source: https://developer.apple.com/library/content/documentation/Carbon/Conceptual/LaunchServicesConcepts/LSCConcepts/LSCConcepts.html#//apple_ref/doc/uid/TP30000999-CH202-BABBJHID)
Thus I only need to add the "launch option" to define, that a new instance should be created instead of activating the existing one. But there's not written what the launch-option for it is and how they will be applied to the application (I suggest it belongs into info.plist-file).
So at least this is the answer to my original question, so I posted it here.
open - starts the application with the Launch-Service (and the defined option-parameters in info.plist)
whereas direct call of the application just starts the application iself without any other launch-options
disclaimer: pretty new to chef and I've inherited a bunch of chef cookbooks. The methods below are sub-optimal but it is what I have to work with for now. Be gentle, please. :) Also, please bear with me as I try to describe what I need.
Please note that we are using chef-client 11.16.4. Updating to 12.x, for now, is not an option.
tl;dr
Is there a way to specify a guard from the state of the current running block:
...
only_if { this_block_did_something }
notifies :run, 'bash[deploy-custom-docker-container]', :immediately
OK....
Take this chunk of code in a recipe I inherited and need to refactor a little...
# The identities of the innocent have been changed for their
# protection. Please ignore odd things in this example:
application app[:name] do
path app[:deploy_path]
enable_submodules true
repository app[:repository]
owner OWNER
group GROUP
symlinks({
"file.py" => "path/file.py"
})
revision app[:branch]
deploy_key data_bag_item('deployment_keys', 'keyname')['private_key']
end
link "/path/to/file.py" do
to "/path/to/settings-%s.py" % [file]
end
# This is where I need some direction...I think.
# note that CMD is a valid constant and the custom docker
# container does not follow any industry standard docker
# conventions due to our strange use-case. So I had to resort
# using a bash block to call our custom start/stop/restart script
bash 'deploy-custom-docker-container' do
code <<-EO
#{CMD} restart
EO
# currently a subscribes but I've tried other methods which
# don't achieve what I'm trying to accomplish
subscribes :run, 'application[%s]' % [app[:name]]
end
The application app[:name] deploys source code onto the target node whenever the repo has new code to be synced. The bash block restarts a very custom and non-industry standard docker container which uses the code.
In its current form, which is undesirable, the bash[deploy-custom-docker-container] block always gets executed irrespective of whether application app[:name] has to deploy code to a git repo or not (IE repo is up to date vs not up to date) on the target node. I'm sure I could create some code that determines if the repo was updated, touch a state/lock file, and then guard execution of the bash block by checking if that lockfile exists. To me, that would be a sub-optimal way to achieve my goal. What would be optimal is to use chef's state of the update as the method of setting the guard. Is that possible?? Read on...
In other words, when application app[:name] is hit during chef-client runtime, and a repo has been updated (and thus deployed on the node), chef-client reports the steps of application app[:name] deploying the new code. If the repo didn't need to be updated, chef-client happily skips the block with a "(up to date)" message. If the repo needed to be updated, chef-client shows the steps taken to deploy the code. So chef-client knows the state of the block of code it just ran.
Also, my observations of how chef-client runs in our environment has shown me that it doesn't matter if I put a notifies block in application app[:name] for bash[deploy-custom-docker-container] or use the subscribes method (pasted above); the bash block gets run irrespective of the state of the application app[:name]. I'd prefer that if the application app[:name] doesn't have an update to perform then the bash block doesn't run.
What I fear is that I will have to use a state file to determine the state of the update of the repo from the application app[:name] block. I'd rather just guard off the state of the run-time from chef's perspective of the application app[:name] block.
FIXED CODE
As pointed out by zts, my actions were wrong or missing. The following code is what I was able to come up with that resolved my issue.
application app[:name] do
...
notifies :run, 'link[%s]' % [filetolink], :immediately
end
link filetolink do
to file
notifies :run, 'bash[deploy-custom-docker-container]', :immediately
end
bash 'deploy-custom-docker-container' do
code <<-EO
#{CMD} restart
EO
action :nothing
end
This works for me now.
Notifications only fire if the notifying resource has changed (and the other way around, subscriptions only fire if the resource you're subscribing to has changed).
The reason the bash block runs irrespective of the notification is that, by default, bash blocks will run. If you only want a resource to run when notified, make sure to include action :nothing.
ie:
bash 'deploy-custom-docker-container' do
code <<-EO
#{CMD} restart
EO
action :nothing
subscribes :run, 'application[%s]' % [app[:name]]
end
Which spring-????-config.xml I should use to star GG nodes so the .net example GridClientApiExample works?
Each GridGain example provides a short description of how to run remote nodes in the example documentation.
Usually there are two ways to run remote nodes for the example. The first and, probably, the most convenient one is to run corresponding *NodeStartup class from IDE in the examples project. The name of startup class is specified in example documentation. The second way is to start a node with ggstart.{sh|bat} script with a configuration file specified in the documentation (if available).
GridClientApiExample works only with node started from IDE with ClientExampleNodeStartup, and there is a reason for it. The example expects a specific task class (org.gridgain.examples.misc.client.api.ClientExampleTask) to be in the node's classpath. Since this is an example-only class, it is not present in node classpath when running ggstart.{sh|bat}.
If for some reason you want to run a node with command line script for this example, you should build examples jar file and drop it to $GRIDGAIN_HOME/libs/ext (startup script will automatically pick up all additional libraries placed in this folder). Then you can use the same config which ClientExampleNodeStartup uses, namely examples/config/example-compute.xml
You can use ClientExampleNodeStartup or start node with ggstart.sh examples/config/example-compute.xml