In production we have multiple containers deployed and any one can be a consumer of one JMS queue. In our development environment, we have multiple developers each with a container that will potentially consume messages. When a developer wants to test something related to JMS by putting something on the queue, though, the message is often consumed by someone else which can be be a time sink.
We use the same build files for every environment. We do not want to accidentally deploy something to an upper environment that is meant strictly for the development environment.
What is a best practice in handling something like this that will not involve build tokens, etc or building differently for different environments?
We currently have the developer ask the other developers to comment out the consuming code, but this is a risk as the commented out code could accidentally get checked in.
One potential way would be to store a property in the database that would change from environment to environment.
How have you handled this?
The way I've seen this done is for each developer to have their own topic, which is specific to their local dev environment. This depends on the developer having some control over the producer, obviously, not sure if this is viable for you.
You don't need build tokens to do this, but tokens do make things a lot nicer for local setup/configuration. I am quite surprised that you are able to use the same build files with no tokenization across every environment, I don't think I've ever worked on such a system.
Related
I am experimenting with OpenDolphin after a while of being interested in it's concept,
I am at the defining requirements phase with some friends for a project we want to make with hopes of earning some money from it this project's concept will be based on a server/multiple-client model where we want the server to have most of the logic, we have average to little experience couple of years each doing java projects but not anything big or exactly with the latests tools, so we struggled a little bit understanding the building process of the gradle setup, and after running this project, we are now faced with tons of groovy projects demos.
And I am struggling to keep my friends interested in the library as they think using what we know best is a better option than trying to understand a library that would mean to learn asap a new language
(we are not that lazy but there is some people that is helping us as consultants/associates and we are afraid that if we dont start producing something we are gonna lose their support [we are not earning anything from this yet but without them as "productowners", we wouldnt know what are exactly the market needs]).
I have watched multiple videos and videos like this: http://www.youtube.com/watch?v=z54hEJvpZys
are amazing , I think that is exactly what we need.
I would like to know if maybe there is an example/tutorial in java maybe a screencast,blog or recorded webinar of how to make a simple application where the server binds to a port and multiple java clients update the value and sends a pair of commands.
I dont know something like server starts, puts a default value in a variable, client connects and sees value, second client connects sees value, and a command is sent to server "erase", and both clients see that the server erased it and another command is sent "default" and server sets variable to default.
I am not asking for that exact example but something that I can read to make it like that.
I tried making something like that using the .8 release and I was utterly lost, but i think that an easy example like that could help me to make them see how good of a tool this is,
"Install this in your laptop, that's the server run it and see how my client and yours are synched automagically".
Ok, you made a good choice of technologies :-)
It appears that the Dolphin JumpStart project (https://github.com/canoo/DolphinJumpStart) covers exactly that combination: OpenDolphin with Java, view in JavaFX, built with Gradle (use dist/jumpstart-gradle.zip) and jetty as the minimal server implementation.
The Jumpstart project is also explained in a step-by-step fashion as part of the OpenDolphin user guide (http://open-dolphin.org/download/guide/guide/howto.html).
Concerning your question about the shared tacho demo: this demo is using only one server that all clients connect to. The "clients" update each other over the server-side event bus. To that end, we do not open any specific sockets. It is all plain HTTP POST that goes trough all proxies and firewalls and needs no special infrastructure.
your concerns are very understandable.
First let me clarify that you can use Java, Groovy, JavaScript or any other language that runs on the JVM with OpenDolphin. What would be your preferred language for a demo?
For a demo that shows many clients that share a common value, I would recommend the SharedTachoDemo.
As for making the build setup easier, we do have to make choices in the demos since there are so many combinations of build system (ant, maven, gradle), structure (all-in-one, multi-project), implementation language, IDE integration (intellij, netbeans, eclipse), server infrastructure (jetty, tomcat, grails, glassfish, jboss, weblogic, webshpere, ...), and last not least the intended UI toolkit (Swing, JavaFX, HTML5, others). If you tell me your preferred combination, I can point you to the respective resource or create one for you.
cheers, Dierk
What products/projects could help me with the following scenario?
More than one server (same location)
Some state should be shared between server (for instance information if a scheduled task is running and on what server).
The obvious answer could of course be databases but we are using Seam and there doesn't seem to be a good way to nest transactions inside a Seam-bean so I need to find a way where I don't have to go crazy over configuration (tried to use EJB:s but persistence.xml wasn't pretty afterwards). So i need another way around this problem until Seam support nested transactions.
This is basically the same scenario as I have if you need more details: https://community.jboss.org/thread/182126.
Any ideas?
Sounds like you need to do distributed job management.
The reality is that in the Java EE world, you are going to end up having to do Queues, as in MoM [Message-oriented Middleware]. Seam will work with JMS, and you can have publish and subscribe queues.
Where you might want to take a look for an alternative is at Akka. It gives you the ability to distribute jobs across machines using an Actor/Agent model that is transparent. That's to say your agents can cooperate with each other whether they are on the same instance or across the network from each other, and you are not writing a ton of code to make that happen, or having to special handle things up and down the message chain.
The other thing Akka has going for it is the notion of Supervision, aka Go Ahead and Fail, or Let it Crash. This is the idea (followed by the Telcos for years), that systems will fail and you should design for it and have a means of making things resilient.
Finally, the state of other options job wise in the Java world is dismal. Have used Seam for years. It's great, but they decided to just support Quartz for jobs, which is useless.
Akka is built on Netty, too, which does some pretty crazy stuff in terms of concurrency and performance.
[Not a TypeSafe employee, btw…]
I'm looking for a tool or set of tools to manage configuration both for our scala application stack and other applications, e.g. lighttpd.
I've been thinking of using Apache Zookeeper, but I haven't found anything that looks like a module for lighttpd (and possibly others). I also considered using for example Puppet, but there doesn't seem to be much of a Zookeeper module for it.
Essentially what I'm trying to achieve is to have one service that keeps configuration & that I can reconfigure dynamically and that would propagate to all services, both on and off the JVM.
Honestly, pick one of the Open Source Configuration Management Systems. One interesting choice that have recently appear and is not listed on Wiki is ANSIBLE.
Also, your problem might be one of orchestration, in which case tools like Chef's Knife, Capistrano, Fabric or MCollective are more adequate.
It might even be you want both, of course.
The best choice would be one written in a language you are familiar with. I don't know of any written in Scala, though this blog post is interesting. For programmers, Chef has great attraction, and handles very dynamic configurations well. I know someone who uses it to create/destroy VM instances on-demand, depending on the application load -- try that with Puppet, and you'll cry.
I like Puppet's declarative configuration style, and in particular the fact that it insulates you a lot from the Operating System differences. To Puppet, a Package is a Package, no matter what operating system you are using.
As for "Zookeeper module"... you might find good recipes/modules for these tools online, but you better be prepared to write your own. Do not chose based on the existence of one particular module -- chose based on how comfortable you feel writing them.
I'm going to deploy my webapp (WAR) in a server machine. But, server machine is in client people hand, and they take database dump(so new data can be created), and WAR file can be copied from tomcat webapp directory. OS is Windows. If they able to copy my WAR and create a database, they can use it elsewhere. How can I protect this? JNI? Something else? If JNI, what's the smart way?
Seriously, if you cannot trust the people who run the server on which your software is to run, then there is no viable technical solution that will prevent them stealing it and running it somewhere else.
All known technical "fixes" (e.g. obfuscation, encrypted classes, license managers, "call home", etc) only make it a bit harder for the bad guys. They all can can be defeated relatively easily. IMO, they are not worth the effort and the accompanying technical problems that they cause for you and/or your client.
Your best approach is the legal one:
Get your lawyers to help you draw up a contract with the client that expressly forbids them from reverse engineering your software, modifying it, running it in ways that you don't want, and so on.
Get the client to agree to the contract.
Monitor what they are doing (to the extent that you can), and if it looks like they are violating the contract ... SUE THEM.
Even this is not a guarantee, but it should cause your client to have second thoughts about stealing your stuff.
Possible solutions:
Use a code obfuscation library. This will make the code look complex in case they try to decompile it (in case they need to change anything). This is usually software that you need to buy and sometimes it will complicate things when you try to look through an exception when debugging the live system.
Include checks in your code that prevent the application of running in case some "hidden" environment variable (or whatever) is not found.
Setup a contract with your client which will explicitly forbit him of stealing and using your app/code elsewhere.
Solution #3 is the most common.
We have some service running on 'n' number of hosts behind a VIP. When there is some fault that occurs with specific request call, we might be interested to know the reason by looking at the logs on the respected host where the fault occurred. since the request could go to any host, when it comes to tracking logs, we need to know from which host the fault originated.
One solution is to store the host name in the database of our service along with other information.
The alternative is, pushing the logs onto a common store and tracing it there.
I personally feel that if we go with the first approach, we might end up in adding many such debugging related attributes in the application database thereby polluting it. However the second option is also not that easy to implement and incurs some overhead. Moreover on which host the fault occurred does not help much except in case the fault occurred due to some hardware specific issue.
What do you guys suggest?
Without knowing more about your infrastructure, it's hard to be precise, but here are some general points of view.
I don't like using databases for storing application logs - if the database falls over, you wouldn't be able to log it! It's also not really relational data, and you can't get the monitoring tools that are available for other solutions.
My recommendation is to use your operating system's built in event logging solution; most logging frameworks support this out of the box. On Windows, that's the event log; on *nix there's the syslog system. Logging should be quick, cheap, and bullet proof - that's what you get from the OS tools.
The second question is then how you use those logs for trouble shooting and monitoring. There are lots of tools for doing this, though mostly aimed at system administrators rather than developers. Microsoft have MoM, there's Tivoli and Big Brother - as well as a whole bunch of open source tools. I'd use those, rather than build your own solution.
The key point is - logging should be fast, cheap and robust; the analysis and monitoring stuff should be entirel separate from your application logic, so you can reuse the tools and processes acros multiple projects.
storing the hostname should be quite cheap I guess. I understand you are appending logs to a db?
you could also store the pid for each process, that can help you in case you have multiple processes running on same hostname. The combination hostname/pid/timestamp will ensure you identify uniquely a process.