It seems as if the jboss teams doesn't want to say that the Java 6 compile of Jboss AS 4.2.3 is a GA, they write that it shouyld be considered expiremental.
Anyone using it in production? we're using it in test and plan to move it to prod as it hasn't shown any problems.
We've been running that same distribution (jboss-4.2.3.GA-jdk6.zip) in production for several months now and it's been working like a champ. However be aware of this issue in particular, it bit us in testing and would have killed us in production: (Add http://) jira.jboss.org/jira/browse/JBWEB-82 . We've installed JBoss Native as a work around and it's been running great.
We have now been running it for a quarter of a year. Seems stable, apart from some strange logs from the transaction manager for unreceverable XA transactions, but we havn't been able to connect those log entries to any application errors.
So it seems stable.
Related
After upgrade to sdk 2.5.216 and runtime 5.5.216 Test-ServiceFabricApplicationPackage command works only for complete package. In case of partial app upgrade (some Pkg are removed) it results in "Windows PowerShell has stopped working". I have tested on several computers and several apps. to reproduce:
create test app with 2 services and deploy.
change app version and particular service version.
create package and remove Pkg folder from it for the service without modifications.
connect to Service Fabric and test like Test-ServiceFabricApplicationPackage -ApplicationPackagePath "..path" -ImageStoreConnectionString "fabric:ImageStore"
Maybe somebody was able to overcome this issue? or at least has similar behavior so I'm not alone in Universe.
Thanks!
Alex
Take a look at https://github.com/Azure/service-fabric-issues/issues/259
This is a bug in our code. It happens when a compressed package was uploaded and provisioned in the cluster. Testing a new version of the application fails because settings file was not found in the provisioned version.
We fixed the issue and it will become available in one of our next releases.
Meanwhile, you can skip compression or test the version 2 application package without passing in the image store connection string.
Apologies for the inconvenience!
I am using jboss-4.0.5.GA for project deployment, but it is hanging at startup by displaying message
Trying to install an already registered mbean: jboss.management.local
it is showing this for 6 minutes and it takes total 7-8 minutes to start.
If I start server without deploying application, then also it's taking 7 to 8 min.
You seem to have corrupted the JBoss installation, highly reccomended to use a fresh installation and deploy your application rather than debug this.
I use Jboss 4.2.2 which is taken from a zipped folder. Today I have renamed the existing setup and tried unzipping again and use a fresh copy. This didn't work out as expected and server is in starting mode for several minutes and thrown error in the end. So removed this fresh setup and used the old one and it worked like a gem, though not sure where is the problem here.
I'm trying to learn about Heroku's deployment capabilities. I've used Google App Engine in the past and have found its support for multiple simultaneously-accessible live application versions useful, for example, in order to test a new version in the production context before making it the default, running a specially-instrumented version in parallel with the default version to debug a problem specific to the production environment (e.g. production data), for A/B testing, traffic splitting, gradual rollout, etc.
Does Heroku have support for this kind of thing? My Googling has not turned up anything.
No, it doesn't offer support for this right now.
We have our J2EE based application basically It is small e-commerce apps that run across global (multiple time zones). When ever we have to deploy the patch it take around 3 hrs time (DB backup,DB changes,Java changes,QA smoke testing). I knew its too high. I want to bring down this deployment time to less than 30 mins.
Now I would brief about application infra: We got two Jboss server and single DB, load balancer is configured for both jboss server. It is not cluster env.
Currently what we do :
We bring down both jboss and DB
Take DB backup
Make the DB changes, run some script
Make the java changes, run patches
Above steps will take around 2 hrs for us
Than QA will do testing for one hr. than bring up the server.
Can you suggest some better approach to achieve this? My main question, when we have multiple jboss and single DB. How to make deployment smooth
One approach I've heard that Netflix uses, but have not had a chance to use myself:
Make all of your DB schema changes both forward and backward compatible with the current version of software running, and the one you are about to deploy. Make the new software version continue to write any data the old version needs. Hopefully this is a minimal set.
Backup your running DB (most DBs don't require downtime for backups), and deploy your database schema updates at least a week prior to your software deploy.
Once your db changes have burnt in and seem to be bug free with the current running version, reconfigure your load balancer to point to only one instance of your JBoss servers. Deploy your updated software to the other instance and have QA smoke test it offline while the other server continues to server production request.
When QA is happy with the results, point the LB to just the offline JBoss server (with the new software). When that comes online, update the software on the newly offline JBoss server, and have QA smoke test if desired. If successful, point the LB to both JBoss instances.
If QA finds major bugs, and a quick bug fix and "roll-forward" is not possible, roll back to the previous version of the deployed software. Since your schema and new code is backward compatible, you won't have lost data.
On your next deploy, remove any garbage from your schema (like columns unused by the current deploy) in a way that makes it still backward and forward compatible.
Although more complex than your current approach, this approach should reduce your deployment downtime with minimal risk.
For a variety of unfortunate management reasons (budget constraints etc.) I, the developer, have been put in the position to deploy the app in a production environment. The catch is that I don't have any experience in production EJB application server deployment. That said, they are aware that there are no guarantees of success.
The context:
The dev server runs on the latest version of Netbeans with Glassfish v3, on a mac machine
98% / 99% uptime is ok, there are no financial/critical transactions
It is a client/server EJB 3 app, and the web tier, business tier, and resource tiers currently run on the same machine.
I have the liberty to choose the hw/sw infrastructure
Load estimations: 10 simultaneous connexions avg, rare 200 peaks
The outbound public data is text/small pics (it's for iPhone clients), inbound HTTP text only
Basic maintenance will be taken care of (backup, server reboot, etc)
My questions for production deployment:
What are the must haves infrastructure-wise? Minimum system specs etc?
Is it ok to keep Glassfish v3?
Which configuration aspects of the server should I focus on?
Worst case scenario: if I deploy the same software infrastructure (Netbeans/Glassfish v3) as during the development, would the server keep up?
Any piece of advice would be most welcome. Thanks!
For the architecture, you can start small with just a single GlassFish instance with no front web server (GlassFish has one built in that is very capable). If you can wait for the release of GlassFish 3.1 you'll be able to add instances (clustered or standalone) and offer scalability and centralized admin.
Most production instances of GlassFish I've seen run with 1GB-2GB of JVM heap (-Xmx) but your mileage may vary if you load lots of data in memory or if you use some frameworks. If you want better reliability, having them on separate machines is a plus obviously. With two instances on the same machine you can offer continuity of service if one instance fails (but not if the machine fails).
I'd suggest scripting as much as possible the provisioning of the resources (connection pool , JDBC datasource, etc...) and applications using the "asadmin" command-line tool and try to not use NetBeans on the production platform.
Benchmarking with simulated load sounds like a wise thing to try to put together before going live and this survival guide will probably come in handy.
You don't mention the database. Isn't there one?
I suggest the following:
Not a Mac expert but I'll say go with 6GB or more RAM
HDD space is not a problem these days
Do not know much abt Mac Processors (watever eq of dual core etc)
Personally I have not used GF3 in Production but I hope it's stable now so you should be ok.
System Architecture:
Receive all HTTP requests on some web server (Apache or Sun web server) and load balance with your Glassfish server(s).
Now depending on your physical (or virtual) machines create instance of Glassfish Application Server on each machine. If you just have one machine then create atleast 2 instances of Glassfish. This will help to put one node down for maintaince and other to keep going.
As far as deployment is concern make sure you stop debug logs and fine tune JPA logs etc.
Use Ant or other scripts to deploy code and taking backup of existing code.
I hope this will help to kick start and rest you can ask or solve as you go along.
Good luck.