I am trying to implement a custom RMI activation scheme, in which remote Activatable objects will be hosted in a custom EXE process, instead of the standard Java.exe/Javaw.exe.
In RMI 'Activatable' objects can be persisted and restored or launched on demand. After an 'Activatable' object is registered with the RMI registry and requested for the first time, RMID launches a host child process (typically java.exe/javaw.exe), passes two pieces of information through the stdin of the child process and asks the child process to run the main method of a special hidden class 'sun.rmi.server.ActivationGroupInit'. This class is bootstraps everything else prepares the process to create and host instances of the 'Activatable' object. Here after the client and server communicate over RMI.
I've gotten as far as defining a simple Win32 EXE project, writing some JNI code to launch the JVM inside this EXE and managed to invoke the main method of the 'sun.rmi'server.ActivationGroupInit'. This class is able to parse stdin and extract whatever it needs to create the ActivationGroup.
However I am running into some issues that is ultimately causing the activation of the remote object to fail (with an UnknownObjectException) and I am in the process of troubleshooting it.
At this point I just wanted to take a step back and ask if anyone has attempted this before, and knows if there are any gotchas that I should know early on?
Thanks,
Ranjit
As we have discussed endlessly on the Oracle forums, you don't need any of this. Just copy java.exe or javaw.exe, or write your own wrapper that just starts a JVM using all the arguments it is passed in exactly the same way that java.exe does. You don't need to worry about what the activation system sends you on stdin etc, the existing activation classes will do all that for you.
Related
I'd like to get an indication about the context in which my process is running from. I'd like to distinguish between the following cases :
It runs as a persistent scheduled task (launchDaemon/launchAgent)
It was called on-demand and created by launchd using open command-line or double-click.
It was called directly from command-line terminal (i.e. > /bin/myProg from terminal )
Perhaps is there any indication about the process context using Objective-c/swift framework or any other way ? I wish to avoid inventing the wheel here :-)
thanks
There is definetely no simple public API or framework for doing this, and doing this is hard.
Some parts of this info possibly could be retreived by your process itslef with some side-ways which will work on some system versions:
There is a launchctl C-based API, which you can try to use to enumerate all
launch daemon/agent tasks and search for your app path/pid. You may
require a root rights for your process for doing this.
Using open command-line sometimes could be traced with environment
variables it sets for your process.
Running directly from command-line could leave responsible_pid filled correctly (which is private API from libquarantine, unless you are observing it with Endpoint Security starting from 11.smth version)
All this things, except launchctl API, are not public, not reliable, could be broken at any time by Apple, and may be not sufficient for your needs.
But it is worth to take them a try, because there is nothing better :)
You could potentially distinguish all cases you want using system events monitoring from some other (root-permitted) process you control, possibly adopting Endpoint Security Framework (requires an entitlement from Apple, can't be distributed via AppStore), calling a lot of private APIs and a doing bunch of reversing tricks.
The open resource I could suggest on this topic is here
I have a rest endpoint which would start the scheduler of loading a XML to memory. Whenever I hit that rest endpoint, it loads the XML in memory and would return the XML after its ready (would take 10 - 15 seconds). When the same endpoint is accessed again, it would return the cached XML. Everything works fine but for now I have to manually hit the endpoint for the scheduler to start. Is there a way to hit the endpoint automatically via a simple code in startup? Or is there any other solution for this?
Normally, a component in the Nucleus is instantiated at first access, not at system start-up.
The way to have anything done at start-up in ATG is to create your component, and then to add its nucleus path to the list of initial services in the /Initial component (or from one of the many other Initial components changed off of it)
The component should be globally scoped. Because /Initial is instantiated at start-up, the services it references will also be instantiated as dependencies.
If your component is a POJO, then the no argument constructor will be invoked on component start-up, then the setX method will be called for each property with a value defined in its properties file.
If your component is extended from Generic Service, then additionally, beforeSet and afterSet methods will be called, before and after the set methods are invoked, if they exist, and finally doStartUp will be called.
This is all part of the fundamental lifecycle of components that the Nucleus manages.
This gives you a number of hooks with which to invoke your custom code.
Now, in your question, you ask how to call a REST endpoint at start-up. However, I believe what you actually want to ask is how to ensure that a particular piece of code gets executed at system start-up. A REST endpoint is how you are triggering it today, manually, from outside the Nucleus. But that does not mean that it must call a REST end point if it is to be automatically called at start up.
The easiest way to achieve what you want is
define a class that extends GenericService
override the doStartUp method
put the code you want to execute in this method, or invoke the code on another component from here
define a globally scoped component for the class
Add the component to the initialServices property of the Initial component
Restart the server and check that your code is being called at start-up. Put some debug statements in, and switch debug logging on in your layer.
Note, you may actually also want to think about whether you really need to invoke your code at system start-up. Anything in initial services adds to the start time of the server. Depending on your requirements, it may be better to do it on first access of your application service rather than at server start-up.
I have a kind of proxy server running on a WebServer module and I noticed that this server is being killed due to its memory consumption.
Every time the server gets a new request it creates a child client process, the problem I see is that the process remains alive indefinitely.
Here is the server I'm using:
server.js
I thought response.close() was closing and killing client connections, but it is not.
Here is the list of child processes displayed on htop:
(Those process are even more, it is just a fragment of the list)
I really need to kill those processes because they are using all the free memory. Am I missing something?
I could simply restart the server, but the memory will still be wasted.
Thanks you !
EDIT:
The processes I mentioned before are threads and no independient processes as I thought (check this).
Every http request creates a new thread, and that's ok, but this thread is not being killed after the script ends.
Also, I found out that no new threads are created if the request handler doesn't run casper (I mean casper.run(..)).
So, new threads are created only if the server runs a casper instance, the problem is that this instance doesn't end after run function does.
I tried casper.done() as mentioned below, but it kill the whole process instead of the current running thread. (I did not find any doc for this function).
When I execute other casper scripts, outside the server in the same machine, the instanced threads and the whole phantom process ends successfully. What would be happening?
I am using Phantom 2.1.1 and Casper 1.1.1 versions.
Please ask me anything if you want more or specific information.
Thanks again for reading !
This is a well known issue with casper:
https://github.com/casperjs/casperjs/issues/1355
It has not been fixed by the casper guys and is currently marked as an enhancement. I guess it's not on their priority list.
Anyways, the workaround is to write a server side component e.g. a node.js server to handle the incoming requests and for every request run a casper script to do the scraping in a new child process. This child process will be closed when casper terminates it's job. While this is a workaround, it is not an optimal solution as the cost of opening a child process for every request is not cheap. it will be hard to heavily scale an approach similar to this. However, it is a sufficient workaround. More on this fully sensible approach is in the link above.
How can I start a mod_perl handler (called MyCacheHandler.pm) directly from another perl module (called MyModule.pm). Because currently I'm starting the handler via a web browser, but it would be a little bit easier to call it with MyModule.
As I understand it, you want to have it (MyCacheHandler) running in the background, and it won't produce any visible (to a browser) output? (Just side effects).
If that's correct, why is it even implemented as a mod_perl handler. Just implement it as a script and run it from cron, or as a daemon of some kind.
You could still control MyCacheHandler from MyModule (say via IPC).
Do some refactoring. Split MyCacheHandler.pm into two modules: one which is doing the hard work and does not depend on mod_perl anymore (that is, no more handling with $r), so it's callable from other modules. The other would be a now thin mod_perl handler calling the first module.
Or leave it as is, and just use LWP::UserAgent to access MyCacheHandler from MyModule.
I have a tiny remote incremental update program (https://github.com/HitTheSticks/alamode), written in java, that needs to be launched before every execution of my main software (which is also written in java). It would be a bad idea to run the updater in the same process space as the main software, given that it's going to be stomping on all sorts of files that are pulled into the classpath by the main program.
Since the updater has basically no dependencies, I can simply generate a launcher with a safe context for it and run it before the main program.
But java's exec() facilities don't follow fork()/exec() semantics. Which means that for the updater to exec() the launcher will result in both JVMs running simultaneously, with all logging IO filtering through the updater. Yuck.
How can I make sure that when the user clicks [my start menu item], it always seamlessly runs [my updater]->[my program]?
I see 'com.install4j.api.launcher.ApplicationLauncher', but it doesn't specify whether or not the calling application can exit without also taking down the launched application. And preferably, I wouldn't nest the applications at all... I'd like them launched sequentially.
Oh, and it'd be cool if the solution were at least mostly portable.