Was planning to use namespace API for multitenant support for our GAE application so was going through namespace API documentation which suggests push queues are supported in namespace API but doesn't quite explain how does namespacing works for push queues.
So ideally what we want is to push tasks in the queue-A and for each namespace get it processed separately. That is if in queue-A with namespace-X there are 100 tasks waiting and namespace-Y there are only 5 tasks then namespace-Y's tasks should not wait for completion of 100 tasks in namespace-x.
So for example:-
queue name- queue-A
clients- client-X & client-Y
now both client-X & client-Y are pushing into queue-A with namespace name as X and Y respectively. So what we expect from namespace is if there is a lot of worklog in queue-A for client-X that shouldn't affect client-Y's task processing speed.
Does this get handled automatically in namespace API as I think this is a very common scenario in multitenant applications if no anyway to achieve it?
I don't think the namespace has any implication in the task scheduling logic. From the task queue example from the doc you mentioned you see that the namespace information is recovered only when the task is actually handled, when the scheduling logic is already completed.
But that's not too bad - for correct operation your app's scaling and queue configuration should normally be set to handle the maximum workload you expect (combined across all namespaces) anyways, in which case the impact of one particular tenant over another, if any, should be insignificant.
Related
I am working on an application that uses Apache Camel to flow a single request message (input) through some initial Camel components/logic and then to a multicast at which point the route branches out into multiple branches. The purpose of each branch is to retrieve data from a specific web service (or other back-end data source, e.g. database) and then after the web service invocation / data retrieval operation completes, each of the branches dumps its output data in the same way via a custom bean endpoint. I expect to eventually have approximately 40 different branches in the Camel route, each of which might flow through a different set of Camel components in order to prepare its request, submit the request, process the response, etc... I anticipate that a fair number of the branches will be quite similar (e.g. all SOAP invocations quite similar, all REST invocations quite similar, etc.) and so have concocted an approach whereby a config file stores the list of back-end data sources to be invoked/retrieved-from along with the ability to define (indirectly) the route that should be taken to reach each of those sources. The config file looks something like this:
[a]
route=X + Y
Y.url=http://someservice
[b]
route=Z
Z.someproperty=123
And then I have code that reads through that config file and treats each of the "sections" (e.g. "[a]", "[b]", etc.) as a branch (i.e. a destination out of the multicast) and relies on classes that are dynamically instantiated (e.g. XRouteSegment, YRouteSegment, ZRouteSegment) in order to each in-turn populate/define the route for its specific branch. As some examples, I have built RouteSegment helper classes for wiring up components such as Velocity, CXF, CXF-RS, for data marshalling/unmarshalling, etc... based on properties set in config file.
As far as initialization of the Camel context goes, it starts out in a fairly typical way with a single RouteBuilder which builds out the first part of the route up to the multicast. But then I go into a for loop and loop through all of the sources found in the config file (e.g. "a", "b", etc.) and create seda nodes for each of those which the multicast flows to. And then I call into each of the RouteSegment instances associated with a given source (e.g. X + Y) and allow those to add to the RouteDefinition as they need (e.g. from their seda start point going forward). And then back in my "main" RouteBuilder I tack on some final routing/components that is to be the same for all of the branches (i.e. the logic that forces each of the branches to store its data via the same custom bean).
The code works just fine, but I am questioning whether this approach is overkill and/or whether there is some easier/cleaner way of doing this that I am overlooking. Would I be better off just having individual Java classes (i.e. RouteBuilders) for each of the branches (in addition to the "trunk" and "tails" of the route)? What I was trying to avoid was having too much duplicated logic/code across all of those classes ... e.g. 20 classes all pulling data from SOAP web services in pretty much exactly the same way. So I am using a RouteSegment instance like "X" referenced above as re-usable shorthand for what would otherwise be a sequence of different Camel Java DSL calls (e.g. from/to/process/log/etc ... with parameters to control the specifics of the individual statements). Are there any other strategies/approaches I should consider in order to dynamically build out a Camel route (+ sizable number of branches) at runtime (e.g. within a for loop, or via some sort of reflection/discovery process (app runs using Spring Boot))?
Thanks in advance for any ideas you might be able to provide/suggest that I might not have thought of / tried yet!
I just want to throw in some subjects I am missing in your description.
If I understand your description correct, all your branches components that are called by multicast are not real components but kind of building blocks to build Camel routes at runtime. That sounds like they are not testable and not startable standalone (but perhaps you just not explained that aspect).
If you would build individual small components (every one with its own RouteBuilder) you would have something similar to a microservice architecture: small units to develop and deploy individually.
Since you use Spring Boot, you have autodiscovery of Routes, so they are kind of "pluggable". The components are also testable using Camel routetests etc.
The components would be much more "static" and small standalone projects. This also ensures a fast development roundtrip when you work on the components.
But as you write, this can lead to lots of redundant code. So I guess you have to decide what is more important for you.
For a project I need to have a unique ID generator. So I thought about a Singleton with synchronized methods.
Since a Singleton following the traditional Singleton pattern (private static instance) is shared accross Sessions, I'm wondering if the #Singleton Annotation is working the same way?
The documentation says: Identifies a type that the injector only instantiates once.
Does it mean, that a #Singleton will be independent per User Session (which is bad for an id-generator)? Should I prefer an old school Singleton with Class.getInstance() over an Injection of an #Singleton-Bean?
Or should I use neither nor and provide the Service within an #ApplicationScoped bean?
it musst be guaranteed that only ONE thread, independent of the user session can access the method to generate the next id. (It's not solvable with auto-increment database ids)
Edit: JSF 2.2, CDI and javax.inject.* i'm talking about :)
All those kinds of singletons (static, #javax.inject.Singleton, #javax.ejb.Singleton and #javax.enterprise.context.ApplicationScoped) are created once per JVM.
An object that is created once per user session must be annotated with #javax.enterprise.context.SessionScoped so no, singletons will not be instantiated per user session.
Notice that there are two #Singleton annotations, one in javax.inject and the other in the javax.ejb package. I'm referring to them by their fully-qualified names to avoid confusion.
The differences between all those singletons are subtle and I'm not sure I know all the implications, but a few come to mind:
#javax.ejb.Singleton is managed by the EJB container and so it can handle transactions (#javax.ejb.TransactionAttribute), read/write locking and time-outs (#javax.ejb.Lock, #javax.ejb.AccessTimeout), application startup (#javax.ejb.Startup, #javax.ejb.DependsOn) and so on.
#javax.enterprise.context.ApplicationScoped is managed by the CDI container, so you won't have the transaction and locking features that EJB has (unless you use a post-1.0 CDI that has added transactions), but you still have lots of nice things such as #javax.enterprise.inject.Produces, #javax.annotation.PostConstruct, #javax.inject.Named, #javax.enterprise.inject.Disposes (but many of these features are available to EJBs too).
#javax.inject.Singleton is similar to #ApplicationScoped, except that there is no proxy object (clients will have a reference to the object directly). There will be less indirection to reach the real object, but this might cause some issues related to serialization (see this: http://docs.jboss.org/weld/reference/latest-2.2/en-US/html_single/#_the_singleton_pseudo_scope)
A plain static field is simple and just works, but it's controlled by the class loader so in order to understand how/when they are instantiated and garbage collected (if ever), you will need to understand how class loaders work and how your application server manages its class loaders (when restarting, redeploying, etc.). See this question for more details.
javax.inject.Singleton - When used on your bean, you have to implement writeResolve() and readReplace to avoid any serialization issues. Use it judiciously based on what your bean actually has in it.
javax.enterprise.context.ApplicationScoped - Allows the container to proxy the bean and take care of serialization process automatically. This is recommended to avoid unprecedented issues.
For More information refer this page number 45.
My goal is to receive updates for some service (using http request-response) all the time, and when I get a specific information, I want to push it to the users. This code must run all the time (let's say every 5 seconds).
How can I run some code doing this when the server is up (means, not by an http request that initiates the execution of this code) ?
I'm using Java.
Thanks
You need to use
Scheduled Tasks With Cron for Java
You can set your own schedule (e.g. every minute), and it will call a specified handler for you.
You may also want to look at
App Engine Modules in Java
before you implement your code. You may separate your user-facing and backend code into different modules with different scaling options.
UPDATE:
A great comment from #tx802:
I think 1 minute is the highest frequency you can achieve on App Engine, but you can use cron to put 12 tasks on a Push Queue, either with delays of 5s, 10s, ... 55s using TaskOptions.countdownMillis() or with a processing rate of 1/5 sec.
It's actually all in the subject: When using Go's very convenient delay package, can I still upload a queue.yaml file and configure the limits etc. for the "built-in" queue? If so, is the queue name simply "delay"? Do any other restrictions apply?
Haven't tried this myself, but this page says:
The default queue is preconfigured with a throughput rate of 5 task
invocations per second. If you want to change the preconfigured
settings, simply define a queue named default in queue.yaml.
I'm not really sure how to handle the scenario I have in a good code manner.
The basic of the criteria of my work is this:
A WPF application that consumes a WCF service
The service uses per session instancing
The session starts soon after application is started and should live through the application lifetime (with small exceptions)
Some method calls in a session must precede and be finished before others are called
This means I will have to be able to have one instance of a proxy client throughout the whole application. I will also have to be able to handle async calls, so the client won't hang up, but at the same time ensure they are finished.
My technical understanding go WCF is limiting enough to not know if certain scenarios would work as intended. So I'm going to list my uncertainties:
When does a session start and when does it end. Is it based on the creation of clients or could a separate client instance access the same session if the first would go faulted.
What is the best way to handle exceptions through a WCF service
Is ChannelFactory something I should look at to help me put here.
So what I did in the first iteration to try to solve some of these problems.
I used dependency injection to inject the client instance throughout the classes of my WPF application (I'm using MVVM) to ensure the same instance is everywhere.
I made the service reference using the asynchronous generation method to get the Begin and End versions of all methods to ensure the calls would be async
I used the Coroutine (IResult interface) feature of the Caliburn.Micro framework to ensure one async action is finished before the other begins (have no idea if this is a proper usage or if it is a smart move at all).
Problems I still have is of course how to handle a faulted state of the client. I'm assuming right now that I could reinstance the client and either rescue the session or I could actually just set it up again as it was. I now need to reinstance it everyplace I injected it in with the same new instance.
So I though perhaps it would be best to create a ClientManager class that would wrap the Client. That way I could inject this ClientManager and reinstance inside of him if needed. I guess I should expose him outwards to be able to make method calls but it would be great if I could error handle inside him in somehow. I'm just having a hard time testing my methods and I'm never certain it will work properly in integration because I don't understand all of the inner workings of WCF, coroutines and threading.
Is there anyone out there with more experience then me in these matters that could give me a few pointers or at least tell me how WCF works in these situations ( per session ) and what I'm doing wrong and what right.
WCF supports sessions out-of-box, so I would recommend starting with this MSDN article.
At a very high level, first you set SessionMode=SessionMode.Required in your ServiceContract. And then, set the IsInitiating=True and IsTerminating=True properties on your OperationContract's to mark the start and end of each session.
However, note that WCF limits concurrent sessions by default to 16 to prevent DOS attacks, but you can always up the value. Also, you would have realized that the session is valid as long as its host (IIS / Windows Service / other) is not recycled.
On a related note, I have used WCF Durable Services earlier - which are meant to persist the state of your WCF service in a data-store (default is SQL Server). Ofcourse, there is a performance hit here. Suggest reading further to see if this is the right choice for you.
Hope this helps.