seam actually proxies every class for interception. is there a difference between proxied classes and proxied classes that implement interfaces?? f.e. like in spring where a proxy instance is made implementing all interfaces specified in the class.
has someone any performance experiences between java.lang.reflect.Proxy vs. cglib or javassist? isn't instantiation over Proxy much faster than bytecode manipulation??
thanks in advance
there many comparison on the web like this:
Unproxied: 559009(ns) 5(ms)
cglib: 21374225(ns) 213(ms)
Proxy: 16506009(ns) 165(ms)
you can download the code and run it yourself.
Related
We use nomad to deploy our applications - which provide gRPC endpoints - as tasks. The tasks are then registered to Consul, using nomad's service stanza.
The routing for our applications is achieved with envoy proxy. We are running central envoy instances loadbalanced at IP 10.1.2.2.
The decision to which endpoint/task to route is currently based on the host header and every task is registered as a service under <$JOB>.our.cloud. This leads to two problems.
When accessing the service, the DNS name must be registered for the loadbalancer IP which leads to /etc/hosts entries like
10.1.2.2 serviceA.our.cloud serviceB.our.cloud serviceC.our.cloud
This problem is partially mitigated by using dnsmasq, but it is still a bit annoying when we add new services
It is not possible to have multiple services running at the same time which provide the same gRPC service. If we e.g. decide to test a new implementation of a service, we need to run it in the same job under the same name and all services which are defined in a gRPC service file need to be implemented.
A possible solution we have been discussing is to use the tags of the service stanza to add tags which define the provided gRPC services, e.g.:
service {
tags = ["grpc-my.company.firstpackage/ServiceA", "grpc-my.company.secondpackage/ServiceB"]
}
But this is discouraged by Consul:
Dots are not supported because Consul internally uses them to delimit service tags.
Now we were thinking about doing it with tags like grpc-my-company-firstpackage__ServiceA, ... This looks really disgusting, though :-(
So my questions are:
Has anyone ever done something like that?
If so, what are recommendations on how to route to gRPC services which are autodiscovered with Consul?
Does anyone have some other ideas or insights into this?
How is this accomplished in e.g. istio?
I think this is a fully supported usecase for Istio. Istio will help you with service discovery w/ Consul and you can use route rules to specify which deployment will provide the service. You can start explore from https://istio.io/docs/tasks/traffic-management/
We do something similar to this, using our own product, Turbine Labs.
We're on a slightly different stack, but the idea is:
Pull service discovery information into our control plane. (We use Kubernetes but support Consul).
Organize this service discovery information by service and by version. We use the tbn_cluster, stage, and version (like here).
Since version for us is the SHA of the release, we don't have formatting issues with it. Also, they don't have to be unique, because the tbn_cluster tag defines the first level of the hierarchy.
Once we have those, we use UI / API to define all the routes (e.g. app.turbinelabs.io/stats -> stats_service). These rules include the tags, so when we deploy a new version (deploy != release), no traffic is routed to it. Releases are done by updating the rules.
(There's even some nice UI affordances for updating those rules for the common case of "release 10% of traffic to the new version," like a slider!)
Hopefully that helps! You might check out LearnEnvoy.io -- lots of tutorials and best practices on what works with Envoy. The articles on Service Discovery Integration and Incremental Blue/Green Releases may be helpful.
I know from experience that injection of circular dependencies in EJB do work, at least in some application servers.
I've done it multiple times with self-injection (e.g. to get an EJB proxy for #TransactionAttribute, #RolesAllowed, #Asynchronous etc. to work).
I've done it with more complex graphs too (A->B->A etc.), which obviously work too.
I've done it at least in Glassfish 3/4, Weblogic, and JBoss 7.3. Maybe Weblogic, not sure.
Now, I've been trying to find some precise guarantee from the specification, without success. There are provisions for this in CDI, but I couldn't find any explanation on why it works for EJBs. Is there some indirect one, maybe?
I'm looking from some references from EJB specifications regarding this.
I don't believe the EJB specification explicitly disallows self-injection, which means it implicitly allows it since there is no reason for the bean's own interface to be different from the interface of some other EJB. In practice, self-injection can only work for stateless (and singleton in EJB 3.1) and not stateful since each lookup/injection of a stateful bean creates a new instance, which would result in infinite recusion. For stateful, you can inject SessionContext and use the getter methods to return a "self-proxy" rather than using injection. This technique also works for stateless/singleton, and it might be marginally faster than using injection (particularly if you cache the result in an instance field the same as injection) since the EJB container can probably return a self-proxy more directly than going through injection/JNDI.
The only additional authority I can give to this answer is that I was one of the primary developers/maintainers of the EJB container in WebSphere Application Server for 5 years. To add to your list of products, I know that self-injection also works in practice on WebSphere Application Server.
I understand that a servlet is an actual class in Java that basically extends and provides useful characteristics of a web server, but are there any alternative equivalents where the same similar key characteristics of a servlet are accomplished in a different language?
Particularly something that has:
the servlet life cycle of init(), service() and remove()
limitations on disk access (persistence)
performing page layout function
can be dynamically reloaded
can call other servlets
can operate like a URL
similar security
I have found servlets in AJAX, Spring and the like, but I mean something that is not in the java family at all. To specify further, I found the following but they don't seem to be used very much, both run over Java, and Armed Bear C-Lisp seems still employs a java virtual machine.
node-servlet
armed bear common lisp
There are quite a number of servlet alternative since servlet is just an implementation of HTTP request and response mechanism based on Java.
Almost all languages has a mechanism to deal with HTTP methods. They just not called 'servlet'. For example node.js has great tools for this. Have a look at express.js which is arguable most used node.js framework.
Make a google search like this: "x rest server" and use whatever language you want instead of 'x', you will most likely get what you asked for. Let's try it for a couple of languages:
ruby rest server : sinatra, grape
swift rest server : kitura, perfect, vapor
c# rest server : web api, servicestack
javascript rest server : node.js, express.js, hapi.js
phyton rest server : django, flash
I am confused between these two nuances:
Is EJB itself middleware, or is there any middleware used in the deployment of EJB?
Same goes for RMI- is RMI itself middleware or is middleware used in RMI?
Define Middleware, if it is in the middle what is it between? I agree with the basic idea of this Wikipedia definition:
Middleware is a computer software that provides services to software
applications beyond those available from the operating system. It can
be described as "software glue".[1] Middleware makes it easier for
software developers to perform communication and input/output, so they
can focus on the specific purpose of their application
So the key idea is you write software and exploit something more sophisticated than the plain operating system. I would not say that middleware is only doing communication and input/output, as I'll explain later.
Now define EJBs. There are two things here: the EJB itself, that is application software that you write; you write an EJB as part of your application development so it is not middleware. But you write to a specification defined by Java EE, and deploy your EJB to an EJB Container provided by an Application Server. The EJB Container and App Server are providing something more sophisticated than the operating system. So the container and server are middleware.
The EJB Container facilities include communications (eg. RMI access and JDBC database access) but also include things such as security and transactions.
EJBs are a component of Java EE, which is a middleware.
RMI is another one, and also another component of Java EE.
You can see that these terms aren't too precise.
I agree with EJP.
Middleware, as it says, is software that provides service for distributed applications, it connects kernel(like server) and user apps.
EJB is a component architecture in server-side and is part of Java EE, it is built on RMI. So both of them are components of middleware.
For me, I liken middleware to the UNIX philosophy per McIlroy: "Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface."
The middleware is all about handling the "text streams".
Each program does one thing, does it well. Having said that, it works on its own, but is also written to work together with others. If a program is to work on its own, then in my view, it is asynchronous. For this you need the middleware if it's to work with others.
I think the RPC (RMI) stuff is too tightly coupled, and synchronous, so it fails my definition of middleware. I think the EJB is trying to do far too much than handle "text streams".
There's obviously more to this topic. Try Middleware but it all gets too complicated for me, probably because people are trying to define middleware as stuff that allows programs from different vendors to talk to each other. Now you get into rivalry and competition, "standards" and ISO stuff.
Is it possible to intercept a constructor call with dynamic proxy?
I registered a proxy on a class that only contains a constructor as a test but it's not intercepted.
I am guessing that it's currently not possible but maybe there's something special I need to do?
No it is not possible. For the simple reason that the creation of proxies is managed by ProxyGenerator which precludes using new with proxies.