SQLException weblogic.common.resourcepool.ResourceLimitException: No resources currently available in pool myDb.datasource to allocate to applications, please increase the size of the pool and retry.. .
Hi, people.
The above is the error I am getting. I am working with Struts 2, and I think, that I properly close connections opened throughout various actions, using finally blocks.
I am porting existing application to Struts 2, application originally is written with simply JSP and core Java, no framework whatsoever was used. I also took care or I think I took care of overriding the main class's finalize method, doing closing connection there.
This is the class that does all the business logic and then mixes the presentation logic to show on JSP Page.
So, the sort of logic used is such:
JSP page, makes calls to Main class's methods. and sometimes to static methods of the Helper class.
Main class in turn, can also use the static methods of the Helper class.
Can anybody suggest, what else can I look at to remedy the exception above? My pool on weblogic is allowing 15 connections now, and considering that there are potentially 1-3 users to my application and even those won't be using it at the same time, I think the pool size is fine and increasing it is not an option for us.
Here are some things to look at:
Enable "Inactive Connection Timeout" on the "Connection Pool" tab of
the Data Source
Enable "Profile Connection Leak" on the "Diagnostics" tab of the
Data Source
These can help you troubleshoot. Also, make sure you have a 'finally' block for the try/catch where you reserve your connections that makes sure they are released.
Related
I have an MVC project, and I'm looking at speeding things up. One thing I'm scratching my head over is the BeginProcesRequest() which I have no control over. Using New Relic I found that this method is, on average consuming 90% of the time required for the transaction to complete.
The code in my controller is pretty simple. It has a look for an action session for the user and redirects to their dashboard if it finds one. there isn't any database calls on the actual page. The only written is:
if (Session["UserID"] != null)
// Perform actions
The BeginProcessRequest() method takes almost 4 seconds as you can see in the screenshot
This can't be something unique to my site? I'm using a small EC2 instance for the server, and although there are other applications running on the site the CPU and memory stay pretty much at 0 throughout the request.
EDIT - Reviewed the following post:
What happens in BeginProcessRequest()?
However as my application is idle when the most time consuming requests take place I can't see how it could be related to competing threads.
I think the issue was with IIS, as after I changed the property of idle time-out in the application pool to be one day it now seems to load much faster on initial start.
I also explicitly disabled the session state on my home controller, and ensured that SQL Server's auto close parameter was set to off.
I am getting this AV message about 3 to 5 seconds after the applications close as expected:
Exception EAccessViolation in module rtl160.bpl at 00073225. Access violation at address 500A3225 in module 'rtl160.bpl'. Read of address 00000004.
These (20) applications are very similar in that they are IBX business applications. About half of them did not cause the AV to occur.
These applications were ported from Delphi-xe and they worked flawlessly for a long time. No changes were made to the projects in the port. Both 32 and 64 bit builds gave the same results.
Is this a bug in some library's finalization section freeing a resource or something?
I am using Delphi-XE2 Update 3.
Would appreciate the help.
Try using madExcept / EurekaLog etc. - they give you detailed stack trace on AV. This is not always a panacea, but can point you to the problem.
Access Violations are by their nature already very troublesome beasts since they deal with invalid pointers in memory. One that occurs a while after an application shuts down is even worse because that's when your app is in "cleanup" mode. You're could be dealing with something that went wrong much earlier in the application, but is only exposing itself at shutdown.
General Tips:
Try to always undo things in the reverse order you did them. E.g.
Create A, Create B ... Destroy B, Destroy A
Connect to Database, Open Dataset ... Close Dataset, Disconnect from Database
Even making sure you've done all the above before shutting down can help tremendously.
Any threads that are still running while your application is running can cause problems.
Preferably ensure all your child threads are properly terminated before final shutdown.
Refer back to Closing datasets above. Depending on what you're doing, some database components will create their own threads.
If you're using COM, try ensure ComObj is high up in the initialization sequence (I.e. place it as high as possible in your DPR).
Delphi finalizes units in the reverse order that they were initialized.
And you don't want ComObj to finalize before other things that are dependent on ComObj have also done so.
If you're using interface references, make sure you resolve circular reference issues.
Some of these problems can be tricky to find, but you can do the following:
Setup a source-code "sandbox" environment (you're going to chuck all your changes as soon as you've found the problem).
Figure out the simplest set of steps required to guarantee the error. (Start app and immediately shutdown would be ideal.)
Then you're going to comment-out delete wipe out chunks of code between tests and basically follow a divide and conquer approach to:
rip out code
test
if the problem persists, repeat. Else roll-back and rip out a different chunk of code.
eventually your code base will be small enough to pinpoint likely problems which can be tackled with targeted testing.
I've had this kind of access violation problem on occasion with old Delphi or C++Builder projects. Today I had it with C++Builder. At the time of the crash, by looking in the Debug -> Call Stack window, I can see that it's happening inside a call to fflush, called by __exit_streams and _exit.
I'm not sure what is causing it, since it's so deep in the Borland library code, but it seems to come and go at random when the code changes. And it seems to be more common with multi-form applications.
This time the error went away when I just added a new button on the main form. A button which is just there, has no event handlers and does not do anything. I think that any random change to the code, classes, variables etc rearranges the memory layout when you relink the application, and that either triggers or untriggers the error.
For now, I just leave the new button on the form, set it to "not visible" so that there's no visible change. As it seems to work, it's good enough solution for me at this time.
I heard numerous times that creating object for same database classes again and again is the bad practice.i really dont understand why is it so . Please somebody explain .
It's a bad idea in general , not just for database classes.
The more objects you have , the more memory being used to maintain your application.
For instance , take a look at: PHP Object Creation and Memory Usage
Hope I helped.
http://particletree.com/notebook/object-oriented-php-memory-concerns/
Have a look at that link to see how much memory is required to create an object (which has only 1 variable). Heavy class means bigger object. Having several memory-hungry scripts and a certain level of user base are enough to take up all memory in no time.
With regards to database classes, depending on whether the class opens up a connection on initialisation, as both the web server and database server have settings for maximum number of connections. The more objects you create, the more connections would be created which is not a good practice. One connection per database, if you can. If your database classes reuses the connection or use lazy initialisation to create the connection when required, you will still face the aforementioned memory problem.
To put it simply, reuse your objects (and your database connection).
I'm testing ASP.NET MVC web application and I use Lucene index files. For every test I need to rebuild Lucene index and then to force my web application to re-read these index files. The only way I've found is to recycle application pool, but it's rather slow.
Does anyone know a way to re-read files from disc without recycling application pool?
It seems like you might not be calling Close on the IndexWriter/Reader/Searchers that you use while performing your tests. If you don't do that and you are using the FSDirectory class (which represents a file system), then lock files are created which prevent the opening of the indexes in the directories.
That said, make sure to call the Close method on any objects that expose one when your test is complete. Make sure to use a try/finally block to ensure that the objects are closed.
Personally I've created an extension method which takes an object and returns an IDisposable implementation which will call Close when Dispose is called, allowing it to be used in using statements (I use reflection on the type to get the Close method and then I generate a lambda expression which is called in the Dispose method).
Also, if you are running a test harness and you are opening and closing the indexes in your text fixtures you either have to make sure that:
The tests that access the indexes are run synchronously so they don't try to open locked directories
OR
Have one test class for all search-related tests and handle the opening and closing of the indexes in whatever setup and teardown mechanisms exist for your test harness. You should also do the population of your index in the setup as well (and not make it one of the test cases, otherwise, you will have synchronization problems).
I am using a TWebModule with Apache. If I understand correctly Apache will spawn another instance of my TWebModule object if all previous created objects are busy processing requests. Is this correct?
I have created my own SessionObject and have created a TStringList to store them. The StringList is created in the initialization section at the bottom of my source code file holding the TWebModule object. I am finding initialization can be called multiple times (presumably when Apache has to spawn another process).
Is there a way I could have a global "Sessions" TStringlist to hold all of my session objects? Or is the "Safe", proper method to store session information in a database and retrieve it based on a cookie for each request?
The reason I want this is to cut down on database access and instead hold session information in memory.
Thanks.
As Stijn suggested, using a separate storage to hold the session data really is the best way to go. Even better is to try to write your application so that the web browser contains the state inherently in the design. This will greatly increase the ability to scale your application into the thousands or tens of thousands of concurrent users with much less hardware.
Intraweb is a great option, but suffers from the scale issue in the sense that more concurrent users, even IDLE users, require more hardware to support. It is far better to design from the onset a method of your server running as internally stateless as possible. Of course if you have a fixed number of users and don't expect any growth, then this is less of an issue.
That's odd. If initialization sections get called more than once, it might be because the DLL is loaded in separate process spaces. One option I can think up is to check if the "Sessions" object already exists when you create it on initialization. If the DLL really is loaded in separate processes, this will not help, and then I suggest writing a central Session storage process and use inter-process-communication from within your TWebModule (there are a few methods: messages, named pipes, COM...)
Intraweb in application mode really handles session management and database access very smoothly, and scales well. I've commented on it previously. While this doesn't directly answer the question you asked, when I faced the same issues Intraweb solved them for me.