I'm using CDI 1.2 with JBoss Weld 2.4.6, where one can configure in the weld.properties the key org.jboss.weld.proxy.dump to: "For debugging purposes, it’s possible to dump the generated bytecode of client proxies and enhanced subclasses to the filesystem." Can this classes somehow can be used to speed up the deployment by loading them to the container instead of letting the container doing the work again?
As the option says, those are purely for debugging purposes.
Weld dumps these proxies as an "on-the-side" action while creating the proxies and loading them anyway, so no slow down/speed up would happen. In other words, by the time the proxy can be dumped, it is already "loaded to the container" and no duplication of work happens.
Also note that creation of proxy does not mean the actual contextual instance will be created as well - those are created lazily when you first try to use them.
Related
I found 2 options how to add classes to hazelcast:
CodeDeployment
clientUserCodeDeploymentConfig.addClass(cz.my.DemoTask.class);
problem is when I change code in this task I got exception:
java.lang.IllegalStateException: Class com.model.myclass is already in a local cache and conflicting byte code representation
Use some serialization like IdentifiedDataSerializable or Portable and add jar to client and server hazelcast with configuration.
so even this is versioned when you need to change our Task you need to update jar and restart server
so is there some other options ?
I found similar issue which is almost 2 years old where is mention:
For the functional objects, we don't have a solution in place but it
is on the road map.
so I am curious if there is some update about this.
I have gone through the solution provided by peter for setting system properties dynamically in multithreading with the below link
System.setProperty used by a thread impacts other thread in communication to external network elements. How to resolve it?
But the problem is, tomcat is not considering the system properties that i am setting. So how to achieve this ?
I have mutiple threads in a management station connecting to different servers through RMI APIs and download the stub accordingly.
I am referring to the same name jar file as a stub at different locations for each server.
note: jar versions may differ at each location.
Eg: MS --> serv1 --> stublocation (http://15.xx.xx.xx:port/myfolder/myapp.jar)
MS --> serv2 --> stublocation (http://15.yy.yy.yy:port/myfolder/myapp.jar)
I want to set java.rmi.server.codebase system property for each of these locations dynamically and make it threadLocal so that it will not override each other settings.
With the example provided in the above link, I hope to achieve the solution for above problem.
But to test the resolution, i am unable to set these properties in tomcat.
Tomcat is ignoring the system properties that i am setting. Tomcat is considering the JVM arguments that are set through catalina.bat or service.bat but not through the system.properties as i need it to be dynamically set.
Any help here will be great! Thanks.
The java.rmi.server.codebase property is set at the JVM which exports remote objects. Setting it in a client JVM accomplishes exactly nothing, unless that JVM exports remote objects too, i.e. callbacks. It doesn't seem likely that you will be dealing with multiple versions of your own application within the same JVM.
In short, your question doesn't make sense.
As EJP points out, (successfully) setting that property is unlikely to achieve what you want.
But there are a couple of other important misconceptions in your question.
Tomcat doesn't implement RMI. RMI is actually implemented by the Java SE itself. Therefore, it is not up to Tomcat to pay attention to those property settings.
Typical Java services that use system properties for configuration purposes do it once during the lifetime of the JVM. Typically this happens when the relevant subsystem (e.g. RMI) initializes. The problem with setting system properties programmatically ("dynamically") is ensuring that they are set before the relevant initialization code uses them.
Going back to what you are trying to achieve, it seems that it is the same as or similar to this:
Java custom classloading and RMI
Nobody was able to help that person, and he ended up solving his problem another way. (I think he is saying that he handled serialVerionId mismatches with customized readObject / writeObject methods ...)
But his Q&A offers one possible way to solve the problem. It is a bit complicated.
The RMI system allows you to provide your own classloader for RMI to use. You do this by implementing the RMIClassLoaderSpi API and then registering your providers as described in the RMIClassLoader javadoc. That's one part of the equation.
The problem is that the RMI classloader is global, but you want RMI on different threads to use different class loaders.
Solution: delegate!
You implement your custom RMI classloader to delegate to one of a number of different classloaders, depending on which versions of the remote APIs that the context requires.
Since you have proposed using thread locals, you can declare a thread local variable for use by the custom RMI classloader, and have it use that variable's value to decide which classloader to delegate to.
CAVEAT ... I have not tried this!
I'm using the ibm_installation_manager module from the puppet forge and it is a bit basic because IBM wrote Installation Manager in a time where idempotency was done much.
ref: https://forge.puppet.com/puppetlabs/ibm_installation_manager
As such it does not cater nicely for upgrades - so the module will not detect if an upgrade is needed, stop existing processes, do the upgrade and then start the processes again. It will just detect if an upgrade is needed and try to install the desired version and if that constitutes an upgrade that's great, but it will probably fail due to running instances.
So I need to implement some "stop processes" pre-upgrade functionality.
I need to mention at this point I'm new to ruby and fairly new to puppet.
The provider that the module uses (imcl.rb) has an exists method.
The ideal way for me to detect if an upgrade is going to happen (and stop the instances if it is) would be for my puppet manifest to be able to somehow call the exists method. Is this possible?
Or how would you approach this problem?
Something like imcl.exists(ibm_pkg["my_imcl_pkg_resource"])
The ideal way for me to detect if an upgrade is going to happen (and stop the instances if it is) would be for my puppet manifest to be able to somehow call the exists method. Is this possible?
No, it is not possible, at least not in any useful way. Your manifests describe how to build a catalog of resources describing the target state of the machine. In a master / agent setup, this happens on the master. The catalog is then used as input to a separate step, in which it is transferred to the target machine and applied there. It is in this second step that providers are engaged.
To the extent that you want the contents of your catalogs to be influenced by the current state of the target machine, the Puppet mechanism for that is to convey the needed state details to the catalog builder in the form of facts. It is relatively straightforward to add your own facts. Indeed, there are at least two distinct, non-exclusive mechanisms, going under the names "external facts" and "custom facts".
How can I use puppet to build from source without using multiple Exec commands?. Do we have modules for it on forge that I could use?
It's possible to use Puppet to build applications from source without using execs, possibly with a custom written type and provider. Otherwise, yes, it'd have to be a few different exec resources with onlyif, creates etc. statements to stop them running every time the agent ran.
Puppet's model of configuration management is known as a desired state model: you define the end state of the system and let the system. This is why exec's are generally avoided in Puppet: they don't fit a desired state model. It also makes things like updating the application, or dealing with unknowns like a partial failure of the compilation that creates a required file.
In my opinion, I would not recommend using configuration management to build applications from source at all. There are a few issue inherent with doing so (this is not just for Puppet, but most config management languages):
Slower runs, as running the compilation can be longer and detecting that it's complete is normally a slightly trickier tasks
Issues with half complete state or failure: if the compilation breaks halfway through it's both harder to detect and resolve
Making the compilation idempotent: You have to wrap the command in logic that detects if the installation has already been done. However, this is difficult, as things like the detection of a flag file or particular binary could occur even when the compilation ends in failure
Upgrading or changing: There's no easy way to upgrade or change the application. A package would be easier to do this with.
This sounds like something that would be better served by packaging, using tools such as FPM or just native package building tools such as rpmbuild.
I need to perform some action (configure something) after stopping the tomcat service. Once the configuration is complete, I need to ensure that the tomcat service is up and running again. I have written following puppet code for the same:
Service {'tomcat': ensure => stopped }
->
class {'config':}
->
Service {'tomcat': ensure => running }
On puppet apply, it is complaining that
'Error: Duplicate declaration: Service[tomcat] is already declared in
file'
How to fix this problem. What is the recipe in puppet to stop a service, perform some action and then bring back the service again?
In puppet, you can't declare same service again. that's the error you have.
With puppet, you needn't care of tomcat stop/start processes. It takes care the final status (called "idemotency"). After you define the relationship between package, config files and services, it will do all jobs for you. For example, you need to understand below processes in puppet and the differences between -> and ~>.
Package['tomcat'] -> File['server.xml'] ~> Service['tomcat']
In your case, you apply the change in tomcat config file, and puppet will restart the tomcat services automatically.
For your reference, here is the copy-paste from Introduction to Puppet blog to explain what's the meaning of idempotency:
One big difference between Puppet and most other tools is that Puppet
configurations are idempotent, meaning they can safely be run multiple
times. Once you develop your configuration, your machines will apply
the configuration often — by default, every 30 minutes — and Puppet
will only make any changes to the system if the system state does not
match the configured state.
Update 2016:
Here another official Puppet blog post on idempotency: https://puppet.com/blog/idempotence-not-just-a-big-and-scary-word
This is not directly possible with Puppet, as #BMW concludes correctly. There are some more points to note, however.
There is some promising work in progress that will add limited support for transitional state declaration. However, this will not (in its current alpha state at least) allow you to enter such a state in preparation for and during application of a whole class.
A common workaround for this kind of issue is to manage the entity in question with two or more resources. The exec type is a good catch all solution because it can manage virtually anything. The obvious drawback is that the exec will have to be tailored to your agents (what do you know - there's a point to Puppet's type system after all ;-). Assuming that the manifest will be for one platform only, this is simple:
exec {
'stop-tomcat':
command => 'service tomcat stop',
onlyif => 'service tomcat status',
before => [
Class['config'],
Service['config'],
],
}
Ordering the exec before Service['config'] is redundant (because the service requires the class), but it is good practice to express that the service resource should have the final say.