Surapuraju Venkatakishor

Greenhorn
+ Follow
since Dec 27, 2011
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Surapuraju Venkatakishor

there is no firewall in between console and managed server
application is deployed correctly and it's health is OK, the deployment order is 100
10 years ago
when you go for this kind of code, you have ideal implementation of an interface.
10 years ago
When deployer people Generates the deployment plan, and developers also generate their plan based on application. which one do you prefer usually and differentiate it?
10 years ago
Application is deployed fine and server health is OK, while accessing the application, we get the following


java.io.IOException: [DeploymentService:290066]Error occurred while downloading files from admin server for deployment request "1,387,026,623,513". Underlying error is: "[DeploymentService:290065]Deployment service servlet encountered an Exception while handling the deployment datatransfer message for request id "1,387,026,623,513" from server "msone". Exception is: "Read timed out"."
at weblogic.deploy.service.datatransferhandlers.HttpDataTransferHandler.getDataAsStream(HttpDataTransferHandler.java:86)
at weblogic.deploy.service.datatransferhandlers.DataHandlerManager$RemoteDataTransferHandler.getDataAsStream(DataHandlerManager.java:153)
at weblogic.deploy.internal.targetserver.datamanagement.AppDataUpdate.doDownload(AppDataUpdate.java:39)
at weblogic.deploy.internal.targetserver.datamanagement.DataUpdate.download(DataUpdate.java:56)
at weblogic.deploy.internal.targetserver.datamanagement.Data.prepareDataUpdate(Data.java:97)
at weblogic.deploy.internal.targetserver.BasicDeployment.prepareDataUpdate(BasicDeployment.java:682)
at weblogic.deploy.internal.targetserver.operations.AbstractOperation.prepareDataUpdate(AbstractOperation.java:898)
at weblogic.deploy.internal.targetserver.operations.AbstractOperation.stageFilesFromAdminServer(AbstractOperation.java:264)
at weblogic.deploy.internal.targetserver.DeploymentManager.createOperations(DeploymentManager.java:1409)
at weblogic.deploy.internal.targetserver.DeploymentManager.handleUpdateDeploymentContext(DeploymentManager.java:162)
at weblogic.deploy.internal.targetserver.DeploymentServiceDispatcher.updateDeploymentContext(DeploymentServiceDispatcher.java:155)
at weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer.doUpdateDeploymentContextCallback(DeploymentReceiverCallbackDeliverer.java:147)
at weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer.updateDeploymentContext(DeploymentReceiverCallbackDeliverer.java:28)
at weblogic.deploy.service.internal.statemachines.targetserver.ReceivedPrepare.callDeploymentReceivers(ReceivedPrepare.java:203)
at weblogic.deploy.service.internal.statemachines.targetserver.ReceivedPrepare.handlePrepare(ReceivedPrepare.java:112)
at weblogic.deploy.service.internal.statemachines.targetserver.ReceivedPrepare.receivedPrepare(ReceivedPrepare.java:52)
at weblogic.deploy.service.internal.targetserver.TargetRequestImpl.run(TargetRequestImpl.java:211)
at weblogic.deploy.service.internal.transport.CommonMessageReceiver$1.run(CommonMessageReceiver.java:457)
at weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:528)
at weblogic.work.ExecuteThread.execute(ExecuteThread.java:201)
at weblogic.work.ExecuteThread.run(ExecuteThread.java:173)
<Dec 14, 2013 6:59:09 PM IST> <Critical> <Management> <BEA-141190> <The commit phase of the configuration update failed with an exception:
java.lang.IllegalStateException: activateUpdate() called without first calling prepareUpdate()
at weblogic.descriptor.internal.DescriptorImpl.activateUpdate(DescriptorImpl.java:218)
at weblogic.management.provider.internal.RuntimeAccessDeploymentReceiverService$1.run(RuntimeAccessDeploymentReceiverService.java:362)
at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:121)
at weblogic.management.provider.internal.RuntimeAccessDeploymentReceiverService.commit(RuntimeAccessDeploymentReceiverService.java:357)
Truncated. see log file for complete stacktrace
>
<Dec 14, 2013 6:59:10 PM IST> <Alert> <WebLogicServer> <BEA-000396> <Server lock has been requested by <WLS Kernel>>
<Dec 14, 2013 6:59:10 PM IST> <Notice> <WebLogicServer> <BEA-000365> <Server state changed to SUSPENDING>
<Dec 14, 2013 6:59:10 PM IST> <Notice> <HTTP> <BEA-101278> <There are no active sessions. The Web service is ready to suspend.>
<Dec 14, 2013 6:59:11 PM IST> <Notice> <Cluster> <BEA-000163> <Stopping "async" replication service>
<Dec 14, 2013 6:59:11 PM IST> <Notice> <WebLogicServer> <BEA-000365> <Server state changed to ADMIN>
10 years ago
thank you so much ...

but deployment plan is an xml file which contains the deployment related information, by seeing this have you noticed any thing
10 years ago
There is no limit to deploy applications on weblogic server, but no one prefers to deploy multiple ear applications in a server. No.of apps will increased application feasibility will reduced.
10 years ago
re-deployment can happen in production environments only. If you re-deploy any application go for version deployment using "-version" option in weblogic.Deployer script.
10 years ago
It depends on mode of domain creation, if you choose Development mode there is a limited no. of servers could configured. whereas in Production mode there is no limit to configure servers.
10 years ago
make RequestDispatcher method logic is inside try block
11 years ago

Servlets are not Thread Safe. Servlet instances are inherently not thread safe because of the multi threaded nature of the Java programming language in general. The Java Virtual Machine supports executing the same code by multiple threads. This is a great performance benefit on machines which have multiple processors. This also allows the same code to be executed by multiple concurrent users without blocking each other.

Imagine a server with 5 processors wherein a normal servlet can handle 500 requests per second. If that servlet were threadsafe, then the web application would act like as if it runs on a server with 1 processor wherein the servlet can handle only 100 requests per second (okay, it's not exactly like that, but you got the idea).

If you encounter threadsafety issues when using servlets, then it is your fault, not Java's nor Servlet's fault. You'd need to fix the servlet code as such that request or session scoped data is never assigned as an instance variable of the servlet.
11 years ago