Search Results

Search found 4578 results on 184 pages for 'connections'.

Page 17/184 | < Previous Page | 13 14 15 16 17 18 19 20 21 22 23 24  | Next Page >

  • Is there an IE8 setting or policy to make it work like IE7 with respect to persistent connections?

    - by Stephen Pace
    I am working with a commercial application running on XP using IIS 5.1. Periodically the application is returning an IIS error "There are too many people accessing the Web site at this time." This is caused by Microsoft artificially limiting the number of connections (10) under IIS 5.1 under Windows XP, but in this case, there is really only one user (albeit a few tabs open at a time). Microsoft suggests you can reduce the problem by turning off HTTP Keep-Alives for that particular web site: http://support.microsoft.com/kb/262635 If you use IIS 5.0 on Windows 2000 Professional or IIS 5.1 on Microsoft Windows XP Professional, disable HTTP keep-alives in the properties of the Web site. When you do this, a limit of 10 concurrent connections still exists, but IIS does not maintain connections for inactive users. I may do that; however, I'm worried about performance degradation. However, I also notice that IE8 appears to handle this differently than IE7. By default, IE6 and IE7 use 2 persistent connections while IE8 uses 6. Perhaps in this case IE8 itself is generating multiple connections in an attempt to be faster, but those additional connections are overwhelming the artificially limited IIS 5.1 on XP? Assuming that is the case, is there an Internet Explorer option, registry setting, or policy I can set to force IE8 to behave like IE7 with respect to persistent connections? I would not set this for all users, but for the small number of users that used this application, it might solve their intermittent problem until the application can be rehosted on Windows Server 2008. Thanks.

    Read the article

  • [PHP] MySql Proccesslist filled with "Sleep" Entries leading to "To many Connections" ?

    - by edorian
    Hi, i'd like to ask your help on a longstanding issue with php/mysql connections. Every time i execute a "SHOW PROCESSLIST" command it shows me about 400 idle (Status: Sleep) connections to the database Server emerging from our 5 Webservers. That never was much of a problem (and i didn't find a quick solution) until recently traffic numbers increased and since then MySql reports the "to many connections" Problems repeatedly, even so 350+ of those connections are in "sleep" state. Also a server can't get a mysql connection even if there are sleeping connection to that same server. All those connections vanish when a apache server is restated. The PHP Code used to create the Database connections uses the normal "mysql" Module, the "mysqli" Module, PEAR::DB and Zend Framework Db Adapter. (Different projects). NONE of the projects uses persistent connections. Raising the connection-limit is possible but doesn't seem like a good solution since it's 450 now and there are only 20-100 "real" connections at a time anyways. My question: Why are there so many connections in sleep state and how can i prevent that. Thank you for your time, if theres anything unclear or missing please let me know

    Read the article

  • SoapUI JMS Connections

    - by Damo
    I am using SoapUI to do performance testing of some services over JMS using WebSphere MQ as the JMS Provider. SoapUI uses HermesJMS to provide the JMS Connection details for the JMS Endpoint. I've noticed that when I call a request from SoapUI the JMS Connection is never closed. This results in hundreds of SYSTEM.DEF.SVRCONN channel connections. It seems to be specific to SoapUI as HermeJMS doesn't exhibit this behaviour. Has anyone else seen this?

    Read the article

  • TcpListener is queuing connections faster than I can clear them

    - by Matthew Brindley
    As I understand it, TcpListener will queue connections once you call Start(). Each time you call AcceptTcpClient (or BeginAcceptTcpClient), it will dequeue one item from the queue. If we load test our TcpListener app by sending 1,000 connections to it at once, the queue builds far faster than we can clear it, leading (eventually) to timeouts from the client because it didn't get a response because its connection was still in the queue. However, the server doesn't appear to be under much pressure, our app isn't consuming much CPU time and the other monitored resources on the machine aren't breaking a sweat. It feels like we're not running efficiently enough right now. We're calling BeginAcceptTcpListener and then immediately handing over to a ThreadPool thread to actually do the work, then calling BeginAcceptTcpClient again. The work involved doesn't seem to put any pressure on the machine, it's basically just a 3 second sleep followed by a dictionary lookup and then a 100 byte write to the TcpClient's stream. Here's the TcpListener code we're using: // Thread signal. private static ManualResetEvent tcpClientConnected = new ManualResetEvent(false); public void DoBeginAcceptTcpClient(TcpListener listener) { // Set the event to nonsignaled state. tcpClientConnected.Reset(); listener.BeginAcceptTcpClient( new AsyncCallback(DoAcceptTcpClientCallback), listener); // Wait for signal tcpClientConnected.WaitOne(); } public void DoAcceptTcpClientCallback(IAsyncResult ar) { // Get the listener that handles the client request, and the TcpClient TcpListener listener = (TcpListener)ar.AsyncState; TcpClient client = listener.EndAcceptTcpClient(ar); if (inProduction) ThreadPool.QueueUserWorkItem(state => HandleTcpRequest(client, serverCertificate)); // With SSL else ThreadPool.QueueUserWorkItem(state => HandleTcpRequest(client)); // Without SSL // Signal the calling thread to continue. tcpClientConnected.Set(); } public void Start() { currentHandledRequests = 0; tcpListener = new TcpListener(IPAddress.Any, 10000); try { tcpListener.Start(); while (true) DoBeginAcceptTcpClient(tcpListener); } catch (SocketException) { // The TcpListener is shutting down, exit gracefully CheckBuffer(); return; } } I'm assuming the answer will be related to using Sockets instead of TcpListener, or at least using TcpListener.AcceptSocket, but I wondered how we'd go about doing that? One idea we had was to call AcceptTcpClient and immediately Enqueue the TcpClient into one of multiple Queue<TcpClient> objects. That way, we could poll those queues on separate threads (one queue per thread), without running into monitors that might block the thread while waiting for other Dequeue operations. Each queue thread could then use ThreadPool.QueueUserWorkItem to have the work done in a ThreadPool thread and then move onto dequeuing the next TcpClient in its queue. Would you recommend this approach, or is our problem that we're using TcpListener and no amount of rapid dequeueing is going to fix that?

    Read the article

  • Impersonation on Windows 2000 to Windows XP Leaves Connections Open

    - by Tallek
    I'm running on a Windows 2000 Pro SP4 box (off domain) and trying to impersonate a local user on a Windows XP box (on domain). I'm using code very similar to the WindowsImpersonationContextFacade in the question posted here: http://stackoverflow.com/questions/879704/how-can-i-temporarily-impersonate-a-user-to-open-a-file. I am using impersonation to remotely start and stop windows services as well as access network shares (for some automated integration tests). To get this working, i had to use LOGON32_PROVIDER_DEFAULT and LOGON32_LOGON_NEW_CREDENTIALS when calling LogonUser. Everything worked beautifully ( Windows XP on domain to Windows XP on domain, Windows XP on domain to Windows Server 2003 off domain, and even Windows XP on domain to Windows 2000 off domain). The one issue was running on Windows 2000 Pro SP4 off the domain and trying to impersonate a local user on a Windows XP box running on the domain. To get the Windows 2000 piece working, i had to use LOGON32_PROVIDER_WINNT50 and LOGON32_LOGON_NEW_CREDENTIALS when calling LogonUser. This seemed to get me 95% of the way there, i could now impersonate the local user on the XP box and start/stop services as well as access a network share using the impersonated credentials. I'm running in to one problem though, calling Undo impersonation and closing the token handle seems to leave the connection to the remote box open. After about 10 or so impersonation calls, further impersonation attempts will fail with an error saying something about too many connections are currently open. If i look at the Computer Management - System Tools - Shared Folders - Sessions on my remote Windows XP box, i can see about 10 sessions open to the Windows 2000 box. I can manually close these (i think they may eventually close themselves, but not very quickly) and then impersonation begins working again few more times. This open session issue doesn't seem to be a problem in any of my other test scenarios, just when running locally on a Windows 2000 box. Any ideas? Edit 1: After some more testing and trying out many different things, this seems to be an issue with open sessions not being reused. On Windows 2000 only, every call to LogonUser to get a token and then using that token to impersonate seems to result in a new session being created. I'm guessing Windows XP & Windows Server 2003 are reusing open sessions since i don't seem to be having any issues with them. If I call LogonUser once, then cache the token, I seem to be able to make as many calls to impersonate as I need using the cached token without running in to the "too many connections" issue. This seems like an ugly work around though since i can't call CloseHandle() on my token every time i perform impersonation. Anybody have any thoughts or ideas, or am i stuck with this ugly hack? Thanks

    Read the article

  • Finder conceals network connections from lsof?

    - by jdizzle
    If I use the Finder's Go-Connect to Server and connect to an smb/afs, I can see the connection in netstat. But I can't see it in lsof. I also use LittleSnitch, and it fails to detect outbound connections from the Finder. Why is this? Is there some sort of "Apple rootkit" that i'm not aware of?

    Read the article

  • Simaltaneous connections with PHP and SOAP?

    - by Dov
    I'm new to using SOAP and understanding the utmost basics of it. I create a client resource/connection, I then run some queries in a loop and I'm done. The issue I am having is when I increase the iterations of the loop, ie: from 100 to 1000, it seems to run out of memory and drops an internal server error. How could I possibly run either a) multiple simaltaneous connections or b) create a connection, 100 iterations, close connection, create connection.. etc. "a)" looks to be the better option but I have no clue as to how to get it up and running whilst keeping memory (I assume opening and closing connections) at a minimum. Thanks in advance! index.php <?php // set loops to 0 $loops = 0; // connection credentials and settings $location = 'https://theconsole.com/'; $wsdl = $location.'?wsdl'; $username = 'user'; $password = 'pass'; // include the console and client classes include "class_console.php"; include "class_client.php"; // create a client resource / connection $client = new Client($location, $wsdl, $username, $password); while ($loops <= 100) { $dostuff; } ?> class_console.php <?php class Console { // the connection resource private $connection = NULL; /** * When this object is instantiated a connection will be made to the console */ public function __construct($location, $wsdl, $username, $password, $proxyHost = NULL, $proxyPort = NULL) { if(is_null($proxyHost) || is_null($proxyPort)) $connection = new SoapClient($wsdl, array('login' => $username, 'password' => $password)); else $connection = new SoapClient($wsdl, array('login' => $username, 'password' => $password, 'proxy_host' => $proxyHost, 'proxy_port' => $proxyPort)); $connection->__setLocation($location); $this->connection = $connection; return $this->connection; } /** * Will print any type of data to screen, where supported by print_r * * @param $var - The data to print to screen * @return $this->connection - The connection resource **/ public function screen($var) { print '<pre>'; print_r($var); print '</pre>'; return $this->connection; } /** * Returns a server / connection resource * * @return $this->connection - The connection resource */ public function srv() { return $this->connection; } } ?>

    Read the article

  • Persistent connections with pipelining

    - by Summer_More_More_Tea
    Hi: I have a question about the behavior of a browser( especially Firefox ) tackling with persistent connections: Must all the requests sent in one pipelined persistent connection direct to the same server? What about a request specified by user from address bar -- may it reuse an already established persistent connection to send its request or need another connection? Regards.

    Read the article

  • Number of concurrent connections in Silverlight

    - by Darko Z
    Hi guys, Is there currently a way to programatically determine from within a Silverlight app the maximum number of concurrent connections that the browser will allow? I know I can do this on the server then pass it as a parameter, but I would like to know if its possible in Silverlight. This is for all versions of Silverlight including Silverlight 4 RC.

    Read the article

  • server performance: multiple external connections and performance

    - by websiteguru
    I am creating a php script that requires the server to make several cURL requests per run. I'll be running this script through cron every 3 minutes. Im looking to maximize the amount of cURL requests I can make in a 24 hr period. What I am wondering is if it would be better from a performance standpoint to get a dedicated server, or several small shared hosting accounts. With the problem being number of external connections and not system resources I'm wondering which is the best approach.

    Read the article

  • How to detect slow internet connections?

    - by Starx
    Currently, most of the popular websites, like google, yahoo detect if the user connection speed is slow and then give a option to load basic version of the website instead of the high end one. What are the methods available to detect slow internet connections? P.S. I think this is achieved through javascript, so I will tag it as a javascript question? However, I am looking for answers oriented more towards PHP, if this is also server related.

    Read the article

  • Maintaining many socket connections with a single thread

    - by John
    Many tutorials on socket communication I see seem to use 1 thread per socket. But on a server used for online gaming, you might have 10k concurrent users - 10k threads isn't probably a wonderful idea. I came across a tool (SmartFox) which claims to use a single thread for monitoring all socket connections, potentially thousands of them. This app happens to be in Java, but I figure C++ or C# could do the same... how would you achieve this?

    Read the article

  • Httpd problem, suspect an attack but not sure

    - by Bob
    On one of my servers when I type netstat -n I get a huge output, something like 400 entries for httpd. The bandwidth on the server isn't high, so I'm confused as to what's causing it. I'm suspecting an attack, but not sure. Intermittently, the web server will stop responding. When this happens all other services such as ping, ftp, work just normally. System load is also normal. The only thing that isn't normal I think is the "netstat -n" output. Can you guys take a look and see if there's something I can do? I have APF installed, but not sure what rules I should put into place to mitigate the problem. Btw, I'm running CentOS 5 Linux with Apache 2. root@linux [/backup/stuff/apf-9.7-1]# netstat -n|grep :80 tcp 0 0 120.136.23.56:80 220.181.94.220:48397 TIME_WAIT tcp 0 0 120.136.23.56:80 218.86.49.153:1734 TIME_WAIT tcp 0 0 120.136.23.56:80 67.195.37.99:48316 TIME_WAIT tcp 0 0 120.136.23.56:80 208.80.193.33:54407 TIME_WAIT tcp 0 0 120.136.23.56:80 65.49.2.180:46768 TIME_WAIT tcp 0 0 120.136.23.56:80 120.0.70.180:9414 FIN_WAIT2 tcp 0 0 120.136.23.56:80 221.130.177.101:43386 TIME_WAIT tcp 0 0 120.136.23.92:80 220.181.7.112:51601 TIME_WAIT tcp 0 0 120.136.23.94:80 220.181.94.215:53097 TIME_WAIT tcp 0 0 120.136.23.56:80 202.160.188.236:53203 TIME_WAIT tcp 0 0 120.136.23.56:80 119.119.247.249:62297 TIME_WAIT tcp 0 0 120.136.23.56:80 119.119.247.249:64345 TIME_WAIT tcp 0 0 120.136.23.56:80 67.195.115.105:36600 TIME_WAIT tcp 0 0 120.136.23.56:80 118.77.25.129:1743 TIME_WAIT tcp 0 0 120.136.23.56:80 220.181.94.220:35107 TIME_WAIT tcp 0 0 120.136.23.56:80 119.119.247.249:61801 TIME_WAIT tcp 0 0 120.136.23.56:80 66.249.69.155:57641 TIME_WAIT tcp 0 1009 120.136.23.56:80 114.249.218.24:17204 CLOSING tcp 0 0 120.136.23.93:80 119.235.237.85:45355 TIME_WAIT tcp 0 0 120.136.23.56:80 217.212.224.182:45195 TIME_WAIT tcp 0 0 120.136.23.56:80 220.189.10.170:1556 TIME_WAIT tcp 0 0 120.136.23.56:80 202.160.180.102:35701 TIME_WAIT tcp 0 0 120.136.23.56:80 118.77.25.129:1745 TIME_WAIT tcp 0 0 120.136.23.56:80 118.77.25.129:1749 TIME_WAIT tcp 0 0 120.136.23.56:80 118.77.25.129:1748 TIME_WAIT tcp 0 0 120.136.23.56:80 221.195.76.250:26635 TIME_WAIT tcp 0 0 120.136.23.56:80 67.195.111.239:58417 TIME_WAIT tcp 0 0 120.136.23.56:80 67.218.116.164:53370 TIME_WAIT tcp 0 0 120.136.23.56:80 220.181.94.236:56168 TIME_WAIT tcp 0 0 120.136.23.93:80 120.136.23.93:36947 TIME_WAIT tcp 0 1009 120.136.23.56:80 114.249.218.24:16991 CLOSING tcp 0 305 120.136.23.56:80 59.58.149.147:1881 ESTABLISHED tcp 0 0 120.136.23.56:80 61.186.48.148:1405 ESTABLISHED tcp 0 0 120.136.23.56:80 123.125.66.46:26703 TIME_WAIT tcp 0 0 120.136.23.56:80 222.84.58.254:4814 TIME_WAIT tcp 0 0 120.136.23.56:80 218.86.49.153:1698 TIME_WAIT tcp 0 0 120.136.23.56:80 222.84.58.254:4813 TIME_WAIT tcp 0 0 120.136.23.56:80 222.84.58.254:4810 TIME_WAIT tcp 0 0 120.136.23.56:80 220.181.94.236:60508 TIME_WAIT tcp 0 0 120.136.23.56:80 222.84.58.254:4811 TIME_WAIT tcp 0 0 120.136.23.56:80 220.181.125.71:43991 TIME_WAIT tcp 0 0 120.136.23.56:80 220.181.125.71:52182 TIME_WAIT tcp 0 0 120.136.23.56:80 222.84.58.254:4806 TIME_WAIT tcp 0 0 120.136.23.56:80 220.181.125.71:56024 TIME_WAIT tcp 0 0 120.136.23.56:80 222.84.58.254:4805 TIME_WAIT tcp 0 0 120.136.23.56:80 222.89.251.167:2133 TIME_WAIT tcp 0 0 120.136.23.56:80 67.195.37.99:48340 TIME_WAIT tcp 0 0 120.136.23.56:80 119.119.247.249:63543 TIME_WAIT tcp 0 0 120.136.23.56:80 220.181.94.220:39544 TIME_WAIT tcp 0 0 120.136.23.56:80 220.181.125.71:48066 TIME_WAIT tcp 0 0 120.136.23.56:80 222.84.58.254:4822 TIME_WAIT tcp 0 0 120.136.23.56:80 67.195.113.253:55817 TIME_WAIT tcp 0 0 120.136.23.56:80 219.141.124.130:11316 FIN_WAIT2 tcp 0 0 120.136.23.56:80 222.84.58.254:4820 TIME_WAIT tcp 0 0 120.136.23.56:80 222.84.58.254:4816 TIME_WAIT tcp 0 0 120.136.23.56:80 202.160.180.140:40743 TIME_WAIT tcp 0 0 120.136.23.56:80 220.181.125.71:60979 TIME_WAIT tcp 0 2332 120.136.23.56:80 221.180.12.66:29255 LAST_ACK tcp 0 0 120.136.23.56:80 117.36.231.149:4078 TIME_WAIT tcp 0 2332 120.136.23.56:80 221.180.12.66:29251 LAST_ACK tcp 0 0 120.136.23.56:80 117.36.231.149:4079 TIME_WAIT tcp 0 2332 120.136.23.56:80 221.180.12.66:29260 LAST_ACK tcp 0 0 120.136.23.56:80 220.181.94.236:51379 TIME_WAIT tcp 0 0 120.136.23.56:80 114.237.16.26:1363 TIME_WAIT tcp 0 2332 120.136.23.56:80 221.180.12.66:29263 LAST_ACK tcp 0 0 120.136.23.56:80 220.181.94.220:63106 TIME_WAIT tcp 0 0 120.136.23.56:80 221.130.177.101:45795 TIME_WAIT tcp 0 0 120.136.23.56:80 111.224.115.203:46315 ESTABLISHED tcp 0 0 120.136.23.56:80 66.249.69.5:35081 ESTABLISHED tcp 0 0 120.136.23.56:80 203.209.252.26:51590 TIME_WAIT tcp 0 2332 120.136.23.56:80 221.180.12.66:29268 LAST_ACK tcp 0 0 120.136.23.80:80 216.7.175.100:54555 TIME_WAIT tcp 0 0 120.136.23.92:80 220.181.7.38:47180 TIME_WAIT tcp 0 0 120.136.23.56:80 119.119.247.249:64467 TIME_WAIT tcp 0 2332 120.136.23.56:80 221.180.12.66:29265 LAST_ACK tcp 0 0 120.136.23.92:80 220.181.7.110:46593 TIME_WAIT tcp 0 2332 120.136.23.56:80 221.180.12.66:29276 LAST_ACK tcp 0 0 120.136.23.56:80 117.36.231.149:4080 TIME_WAIT tcp 0 0 120.136.23.56:80 117.36.231.149:4081 TIME_WAIT tcp 0 0 120.136.23.56:80 67.195.37.99:50215 TIME_WAIT tcp 0 101505 120.136.23.56:80 111.166.41.15:1315 ESTABLISHED tcp 0 2332 120.136.23.56:80 221.180.12.66:29274 LAST_ACK tcp 0 0 120.136.23.56:80 222.84.58.254:4878 TIME_WAIT tcp 0 1 120.136.23.93:80 58.33.226.66:4715 FIN_WAIT1 tcp 0 0 120.136.23.56:80 222.84.58.254:4877 TIME_WAIT tcp 0 1009 120.136.23.56:80 114.249.218.24:17062 CLOSING tcp 0 2332 120.136.23.56:80 221.180.12.66:29280 LAST_ACK tcp 0 0 120.136.23.56:80 222.84.58.254:4874 TIME_WAIT tcp 0 0 120.136.23.93:80 124.115.0.28:59777 TIME_WAIT tcp 0 0 120.136.23.56:80 222.84.58.254:4872 TIME_WAIT tcp 0 0 120.136.23.56:80 222.84.58.254:4870 TIME_WAIT tcp 0 0 120.136.23.56:80 67.195.37.99:50449 TIME_WAIT tcp 0 0 120.136.23.56:80 222.84.58.254:4868 TIME_WAIT tcp 0 0 120.136.23.56:80 221.130.177.107:37579 TIME_WAIT tcp 0 0 120.136.23.56:80 67.195.114.238:34255 TIME_WAIT tcp 0 0 120.136.23.56:80 221.130.177.105:35530 TIME_WAIT tcp 0 0 120.136.23.56:80 220.181.94.220:43960 TIME_WAIT tcp 0 0 120.136.23.56:80 67.195.111.229:41667 TIME_WAIT tcp 0 0 120.136.23.56:80 220.181.94.220:52669 TIME_WAIT tcp 0 0 120.136.23.56:80 67.195.111.239:56779 TIME_WAIT tcp 1 16560 120.136.23.56:80 210.13.118.102:43675 CLOSE_WAIT tcp 0 1009 120.136.23.56:80 114.249.218.24:17084 CLOSING tcp 0 0 120.136.23.56:80 221.130.177.105:33501 TIME_WAIT tcp 0 0 120.136.23.93:80 123.116.230.132:9703 TIME_WAIT tcp 0 0 120.136.23.56:80 67.195.37.99:49414 TIME_WAIT tcp 0 0 120.136.23.56:80 220.168.66.48:3360 ESTABLISHED tcp 0 0 120.136.23.56:80 220.168.66.48:3361 FIN_WAIT2 tcp 0 0 120.136.23.56:80 220.168.66.48:3362 ESTABLISHED tcp 0 0 120.136.23.80:80 66.249.68.183:39813 TIME_WAIT tcp 0 0 120.136.23.56:80 67.195.37.99:51569 TIME_WAIT tcp 0 0 120.136.23.56:80 216.129.119.11:58377 TIME_WAIT tcp 0 0 120.136.23.56:80 67.195.111.229:41914 TIME_WAIT tcp 0 0 120.136.23.56:80 60.213.146.54:33921 TIME_WAIT tcp 0 0 120.136.23.56:80 67.195.37.99:50287 TIME_WAIT tcp 0 0 120.136.23.56:80 61.150.84.6:2094 TIME_WAIT tcp 0 0 120.136.23.56:80 67.218.116.166:33262 TIME_WAIT tcp 0 0 120.136.23.56:80 221.130.177.101:38064 TIME_WAIT tcp 0 0 120.136.23.56:80 110.75.167.223:39895 TIME_WAIT tcp 0 0 120.136.23.56:80 67.195.37.99:48991 TIME_WAIT tcp 1 16560 120.136.23.56:80 210.13.118.102:61893 CLOSE_WAIT tcp 0 0 120.136.23.93:80 61.152.250.144:42832 TIME_WAIT tcp 0 0 120.136.23.56:80 202.160.180.174:37484 TIME_WAIT tcp 0 0 120.136.23.56:80 119.119.247.249:63403 TIME_WAIT tcp 0 0 120.136.23.56:80 119.119.247.249:62121 TIME_WAIT tcp 0 0 120.136.23.56:80 66.249.69.155:62189 TIME_WAIT tcp 0 0 120.136.23.56:80 202.160.180.80:60303 TIME_WAIT tcp 0 363 120.136.23.56:80 123.89.153.157:39067 ESTABLISHED tcp 0 0 127.0.0.1:80 127.0.0.1:49406 TIME_WAIT tcp 0 0 120.136.23.92:80 66.249.65.226:61423 TIME_WAIT tcp 0 0 120.136.23.56:80 122.136.173.33:19652 TIME_WAIT tcp 0 2332 120.136.23.56:80 221.180.12.66:29243 LAST_ACK tcp 0 0 120.136.23.56:80 122.136.173.33:19653 FIN_WAIT2 tcp 0 0 120.136.23.56:80 122.86.41.132:5061 TIME_WAIT tcp 0 0 120.136.23.56:80 202.160.179.90:51318 TIME_WAIT tcp 0 0 120.136.23.56:80 122.86.41.132:5060 TIME_WAIT tcp 0 0 120.136.23.56:80 220.181.94.235:54333 TIME_WAIT tcp 0 1 120.136.23.56:80 122.86.41.132:5062 LAST_ACK tcp 0 0 120.136.23.56:80 220.181.94.229:42547 ESTABLISHED tcp 0 0 120.136.23.56:80 123.125.66.135:39557 TIME_WAIT tcp 0 0 120.136.23.56:80 122.86.41.132:5057 TIME_WAIT tcp 0 0 120.136.23.56:80 202.127.20.37:17012 ESTABLISHED tcp 0 0 120.136.23.56:80 202.127.20.37:17013 ESTABLISHED tcp 0 0 120.136.23.93:80 222.190.105.186:4641 FIN_WAIT2 tcp 0 0 120.136.23.56:80 122.86.41.132:5059 TIME_WAIT tcp 0 0 120.136.23.56:80 202.127.20.37:17014 ESTABLISHED tcp 0 0 120.136.23.56:80 60.169.49.238:64078 ESTABLISHED tcp 0 0 120.136.23.56:80 122.86.41.132:5058 TIME_WAIT tcp 0 0 120.136.23.56:80 202.127.20.37:17015 ESTABLISHED tcp 0 0 120.136.23.56:80 60.169.49.238:64079 ESTABLISHED tcp 0 0 120.136.23.56:80 202.127.20.37:17016 ESTABLISHED tcp 0 0 120.136.23.56:80 67.195.113.224:53092 TIME_WAIT tcp 0 1 120.136.23.56:80 122.86.41.132:5065 LAST_ACK tcp 0 0 120.136.23.56:80 122.86.41.132:5064 TIME_WAIT tcp 0 0 120.136.23.56:80 122.86.41.132:5067 TIME_WAIT tcp 0 0 120.136.23.56:80 122.86.41.132:5066 TIME_WAIT tcp 0 0 120.136.23.80:80 125.46.48.20:58200 TIME_WAIT tcp 0 27544 120.136.23.56:80 124.160.125.8:8189 LAST_ACK tcp 0 0 120.136.23.56:80 123.125.66.27:30477 TIME_WAIT tcp 0 0 120.136.23.56:80 221.130.177.102:60019 TIME_WAIT tcp 0 0 120.136.23.56:80 60.169.49.238:64080 FIN_WAIT2 tcp 0 0 120.136.23.56:80 220.181.94.229:37673 TIME_WAIT tcp 0 26136 120.136.23.56:80 60.169.49.238:64081 ESTABLISHED tcp 0 0 120.136.23.56:80 202.127.20.37:17002 ESTABLISHED tcp 0 0 120.136.23.56:80 60.169.49.238:64082 ESTABLISHED tcp 0 0 120.136.23.56:80 60.169.49.238:64083 ESTABLISHED tcp 0 0 120.136.23.56:80 60.169.49.238:64084 FIN_WAIT2 tcp 0 0 120.136.23.56:80 60.169.49.238:64085 FIN_WAIT2 tcp 0 0 120.136.23.56:80 219.131.92.53:4084 TIME_WAIT tcp 0 0 120.136.23.56:80 219.131.92.53:4085 TIME_WAIT tcp 0 0 120.136.23.56:80 219.131.92.53:4086 TIME_WAIT tcp 0 0 120.136.23.56:80 220.181.94.235:42269 TIME_WAIT tcp 0 0 120.136.23.56:80 125.238.149.46:56911 TIME_WAIT tcp 0 0 120.136.23.56:80 125.238.149.46:56910 TIME_WAIT tcp 0 0 120.136.23.56:80 219.131.92.53:4081 TIME_WAIT tcp 0 0 120.136.23.56:80 220.181.94.221:34606 TIME_WAIT tcp 0 0 120.136.23.56:80 219.131.92.53:4082 TIME_WAIT tcp 0 0 120.136.23.80:80 125.46.48.20:25451 TIME_WAIT tcp 0 0 120.136.23.56:80 219.131.92.53:4083 TIME_WAIT tcp 0 0 120.136.23.56:80 221.130.177.100:55875 TIME_WAIT tcp 0 0 120.136.23.56:80 221.130.177.100:51522 TIME_WAIT tcp 0 0 120.136.23.56:80 111.9.9.224:49650 TIME_WAIT tcp 0 0 120.136.23.56:80 219.131.92.53:4088 TIME_WAIT tcp 0 0 120.136.23.56:80 219.131.92.53:4089 TIME_WAIT tcp 0 0 120.136.23.56:80 124.224.63.144:18753 TIME_WAIT tcp 0 0 120.136.23.56:80 124.224.63.144:18752 TIME_WAIT tcp 0 0 120.136.23.56:80 124.224.63.144:18755 TIME_WAIT tcp 0 0 120.136.23.56:80 66.249.69.2:43954 ESTABLISHED tcp 0 0 120.136.23.56:80 124.224.63.144:18754 TIME_WAIT tcp 0 0 120.136.23.56:80 220.181.94.231:48903 TIME_WAIT tcp 0 0 120.136.23.56:80 121.0.29.194:61655 TIME_WAIT tcp 0 0 120.136.23.56:80 125.238.149.46:56915 TIME_WAIT tcp 0 0 120.136.23.56:80 125.238.149.46:56914 TIME_WAIT tcp 0 0 120.136.23.80:80 125.46.48.20:16247 TIME_WAIT tcp 0 0 120.136.23.56:80 125.238.149.46:56913 TIME_WAIT tcp 0 0 120.136.23.56:80 220.181.94.235:59909 TIME_WAIT tcp 0 0 120.136.23.56:80 220.181.94.235:48389 TIME_WAIT tcp 0 0 120.136.23.56:80 125.238.149.46:56912 TIME_WAIT tcp 0 0 120.136.23.93:80 222.190.105.186:4635 TIME_WAIT tcp 0 0 120.136.23.56:80 221.130.177.106:44326 TIME_WAIT tcp 0 0 120.136.23.56:80 222.170.217.26:1812 TIME_WAIT tcp 0 0 120.136.23.56:80 222.170.217.26:1810 TIME_WAIT tcp 0 0 120.136.23.56:80 221.130.177.104:36898 TIME_WAIT tcp 0 0 120.136.23.56:80 220.181.94.235:39033 TIME_WAIT tcp 0 0 120.136.23.56:80 220.181.94.231:58229 TIME_WAIT tcp 0 0 120.136.23.56:80 222.170.217.26:1822 TIME_WAIT tcp 0 0 120.136.23.56:80 222.170.217.26:1820 TIME_WAIT tcp 0 0 120.136.23.56:80 121.206.183.172:2214 FIN_WAIT2 tcp 0 0 120.136.23.56:80 220.181.94.221:54341 TIME_WAIT tcp 0 0 120.136.23.56:80 222.170.217.26:1818 TIME_WAIT tcp 0 0 120.136.23.56:80 124.224.63.144:18751 TIME_WAIT tcp 0 0 120.136.23.56:80 124.224.63.144:18750 TIME_WAIT tcp 0 0 120.136.23.56:80 61.177.143.210:4226 TIME_WAIT tcp 0 0 120.136.23.56:80 116.9.9.250:55700 TIME_WAIT tcp 0 39599 120.136.23.93:80 125.107.166.221:3083 ESTABLISHED tcp 0 0 120.136.23.56:80 120.86.215.180:62554 TIME_WAIT tcp 0 0 120.136.23.56:80 221.130.177.100:48442 TIME_WAIT tcp 0 0 120.136.23.56:80 123.150.182.221:34199 TIME_WAIT tcp 0 69227 120.136.23.93:80 125.107.166.221:3084 ESTABLISHED tcp 0 0 120.136.23.56:80 220.181.94.231:53605 TIME_WAIT tcp 0 0 120.136.23.56:80 123.150.182.221:34196 TIME_WAIT tcp 0 0 120.136.23.56:80 120.86.215.180:62556 TIME_WAIT tcp 0 0 120.136.23.56:80 123.150.182.221:34203 TIME_WAIT tcp 0 0 120.136.23.56:80 221.130.177.104:40252 TIME_WAIT tcp 0 0 120.136.23.56:80 123.150.182.221:34202 TIME_WAIT tcp 0 0 120.136.23.56:80 124.224.63.144:18731 TIME_WAIT tcp 0 0 120.136.23.56:80 123.150.182.221:34201 TIME_WAIT tcp 0 0 120.136.23.56:80 123.150.182.221:34200 TIME_WAIT tcp 0 0 120.136.23.56:80 111.9.9.224:49538 TIME_WAIT tcp 0 0 120.136.23.56:80 202.160.180.57:49229 TIME_WAIT tcp 0 0 120.136.23.56:80 124.224.63.144:18734 TIME_WAIT tcp 0 0 120.136.23.56:80 123.150.182.221:34204 TIME_WAIT tcp 0 0 120.136.23.56:80 111.72.156.95:2517 TIME_WAIT tcp 0 0 120.136.23.56:80 220.181.94.229:59728 TIME_WAIT tcp 0 0 120.136.23.56:80 116.20.61.208:50598 TIME_WAIT tcp 0 0 120.136.23.56:80 122.86.41.132:5031 TIME_WAIT tcp 0 0 120.136.23.56:80 122.86.41.132:5030 TIME_WAIT tcp 0 0 120.136.23.56:80 220.191.255.196:46290 FIN_WAIT2 tcp 0 0 120.136.23.56:80 122.86.41.132:5037 TIME_WAIT tcp 0 1 120.136.23.56:80 122.86.41.132:5036 LAST_ACK tcp 0 0 120.136.23.80:80 115.56.48.140:38058 TIME_WAIT tcp 0 0 120.136.23.56:80 122.86.41.132:5039 TIME_WAIT tcp 0 0 120.136.23.80:80 115.56.48.140:38057 TIME_WAIT tcp 0 0 120.136.23.56:80 122.86.41.132:5038 TIME_WAIT tcp 0 0 120.136.23.80:80 125.46.48.20:45862 TIME_WAIT tcp 0 0 120.136.23.56:80 122.86.41.132:5033 TIME_WAIT tcp 0 0 120.136.23.56:80 122.86.41.132:5032 TIME_WAIT tcp 0 0 120.136.23.56:80 122.86.41.132:5034 TIME_WAIT tcp 0 0 120.136.23.56:80 111.9.9.224:49582 TIME_WAIT tcp 0 0 120.136.23.56:80 220.181.94.221:38777 TIME_WAIT tcp 0 0 120.136.23.56:80 123.125.66.15:27007 TIME_WAIT tcp 0 0 120.136.23.56:80 67.195.37.98:59848 TIME_WAIT tcp 0 0 120.136.23.56:80 122.86.41.132:5040 TIME_WAIT tcp 0 0 120.136.23.80:80 125.46.48.20:14651 TIME_WAIT tcp 0 0 120.136.23.56:80 220.181.94.221:58495 TIME_WAIT tcp 0 0 120.136.23.56:80 111.72.156.95:2765 TIME_WAIT tcp 0 0 120.136.23.56:80 122.86.41.132:5053 TIME_WAIT tcp 0 0 120.136.23.56:80 120.86.215.180:62578 ESTABLISHED tcp 0 0 120.136.23.56:80 202.160.179.58:36715 TIME_WAIT tcp 0 0 120.136.23.56:80 122.86.41.132:5048 TIME_WAIT tcp 0 0 120.136.23.93:80 61.153.27.172:4889 TIME_WAIT tcp 0 0 120.136.23.56:80 111.72.156.95:1995 TIME_WAIT tcp 0 0 120.136.23.56:80 111.9.9.224:49501 TIME_WAIT tcp 0 12270 120.136.23.56:80 119.12.4.49:49551 ESTABLISHED tcp 0 6988 120.136.23.56:80 119.12.4.49:49550 ESTABLISHED tcp 0 0 120.136.23.56:80 66.249.67.106:60516 TIME_WAIT tcp 0 0 120.136.23.56:80 202.160.179.76:56301 TIME_WAIT tcp 0 0 120.136.23.56:80 202.160.178.41:32907 TIME_WAIT tcp 0 0 120.136.23.93:80 61.153.27.172:24811 TIME_WAIT tcp 0 0 120.136.23.56:80 202.160.180.155:35617 TIME_WAIT tcp 0 0 120.136.23.56:80 220.181.94.229:50081 TIME_WAIT tcp 0 3650 120.136.23.56:80 119.12.4.49:49555 ESTABLISHED tcp 0 0 120.136.23.56:80 116.9.9.250:55632 TIME_WAIT tcp 0 4590 120.136.23.56:80 119.12.4.49:49554 ESTABLISHED tcp 0 823 120.136.23.56:80 119.12.4.49:49553 ESTABLISHED tcp 0 778 120.136.23.56:80 119.12.4.49:49552 ESTABLISHED tcp 0 31944 120.136.23.93:80 222.67.49.170:52229 ESTABLISHED tcp 0 0 120.136.23.93:80 219.219.127.2:44661 TIME_WAIT tcp 0 0 120.136.23.56:80 221.130.177.102:38602 TIME_WAIT tcp 0 0 120.136.23.56:80 61.177.143.210:4208 TIME_WAIT tcp 0 0 120.136.23.56:80 117.23.111.2:3297 TIME_WAIT tcp 0 0 120.136.23.56:80 111.72.156.95:2079 TIME_WAIT tcp 0 0 120.136.23.92:80 220.181.7.49:44133 TIME_WAIT tcp 0 0 120.136.23.80:80 125.46.48.20:38627 TIME_WAIT tcp 0 660 120.136.23.56:80 113.16.37.24:62908 LAST_ACK tcp 0 0 120.136.23.56:80 220.181.94.231:62850 TIME_WAIT tcp 0 0 120.136.23.56:80 220.181.94.235:33423 TIME_WAIT tcp 0 0 120.136.23.56:80 216.129.119.40:53331 TIME_WAIT tcp 0 0 120.136.23.56:80 116.248.65.32:2580 ESTABLISHED tcp 0 0 120.136.23.56:80 61.177.143.210:4199 TIME_WAIT tcp 0 0 120.136.23.93:80 125.107.166.221:3052 TIME_WAIT tcp 0 0 120.136.23.56:80 216.7.175.100:36933 TIME_WAIT tcp 0 1 120.136.23.56:80 183.35.149.94:2414 FIN_WAIT1 tcp 0 26963 120.136.23.56:80 124.160.125.8:8274 LAST_ACK tcp 0 0 120.136.23.93:80 61.153.27.172:16350 TIME_WAIT tcp 0 0 120.136.23.56:80 220.181.94.229:64907 TIME_WAIT tcp 0 0 120.136.23.56:80 219.131.92.53:4116 TIME_WAIT tcp 0 0 120.136.23.56:80 221.130.177.102:32937 TIME_WAIT tcp 0 0 120.136.23.56:80 218.59.137.178:52731 FIN_WAIT2 tcp 0 0 120.136.23.56:80 123.125.66.53:31474 ESTABLISHED tcp 0 8950 120.136.23.56:80 221.194.136.245:21574 ESTABLISHED tcp 0 0 120.136.23.56:80 216.7.175.100:36922 TIME_WAIT tcp 0 0 120.136.23.56:80 216.7.175.100:36923 TIME_WAIT tcp 0 0 120.136.23.56:80 221.130.177.106:41386 TIME_WAIT tcp 0 0 120.136.23.56:80 220.181.94.221:62681 TIME_WAIT tcp 0 0 120.136.23.56:80 111.72.156.95:1639 ESTABLISHED tcp 0 0 120.136.23.56:80 219.131.92.53:4103 TIME_WAIT tcp 0 0 120.136.23.56:80 220.181.94.231:44007 TIME_WAIT tcp 0 0 120.136.23.93:80 61.153.27.172:15026 TIME_WAIT tcp 0 0 120.136.23.56:80 202.160.180.125:59521 TIME_WAIT tcp 0 660 120.136.23.56:80 113.16.37.24:62921 FIN_WAIT1 tcp 0 0 120.136.23.56:80 220.181.94.229:54767 TIME_WAIT tcp 0 0 120.136.23.56:80 219.131.92.53:4148 ESTABLISHED tcp 0 0 120.136.23.93:80 202.104.103.210:2423 TIME_WAIT tcp 0 0 120.136.23.56:80 219.131.92.53:4149 ESTABLISHED tcp 0 0 120.136.23.56:80 219.131.

    Read the article

  • jboss 5.1 mysql connection pooling

    - by boyd4715
    I am using JBOSS 5.1.0.GA, MySQL 5.5 and Hibernate 3.3.1 GA (included with JBOSS) + Spring. My question is do I need to add c3p0 as a data source in my spring/hibernate configuration for connection pooling or are the setting in the JBOSS mysql-ds.xml setting enough. My mysql-ds.xml is the following: <datasources> <local-tx-datasource> <jndi-name>MySqlDS</jndi-name> <connection-url>jdbc:mysql://localhost:3306/ecotrak</connection-url> <driver-class>com.mysql.jdbc.Driver</driver-class> <user-name>ecotrak</user-name> <password>ecotrak</password> <min-pool-size>5</min-pool-size> <max-pool-size>20</max-pool-size> <idle-timeout-minutes>5</idle-timeout-minutes> <exception-sorter-class-name>org.jboss.resource.adapter.jdbc.vendor.MySQLExceptionSorter</exception-sorter-class-name> <!-- should only be used on drivers after 3.22.1 with "ping" support --> <valid-connection-checker-class-name>org.jboss.resource.adapter.jdbc.vendor.MySQLValidConnectionChecker</valid-connection-checker-class-name> <!-- sql to call when connection is created <new-connection-sql>some arbitrary sql</new-connection-sql> --> <!-- sql to call on an existing pooled connection when it is obtained from pool - MySQLValidConnectionChecker is preferred for newer drivers <check-valid-connection-sql>some arbitrary sql</check-valid-connection-sql> --> <!-- corresponding type-mapping in the standardjbosscmp-jdbc.xml (optional) --> <metadata> <type-mapping>mySQL</type-mapping> </metadata> </local-tx-datasource> </datasources>

    Read the article

  • Determining currently-serving files in IIS 7

    - by Nat Papovich
    serverfault showed me this topic, and I think I want to do the same thing, but in IIS, not Apache. I have a "dashboard" application I'm building and I want it to show what files are currently being served by IIS. They'll mostly all be large files. I believe that the ILogScripting COM Interface would have been one good place to start, but it's not available in IIS 7, and it relies on the underlying IIS logs for its data. And therein, I believe, lies my problem. How do I make IIS put in, essentially, two log entries, one as the request begins, and one when the connection is closed? Also, it looks like IIS doesn't "commit" log entries as they're occuring, in "real-time". There's some kind of delay/batch-job. That will cause a problem for me too. Or do I need to do something in isapi instead?

    Read the article

  • Data Source Connection Pool Sizing

    - by Steve Felts
    Normal 0 false false false EN-US X-NONE X-NONE MicrosoftInternetExplorer4 /* Style Definitions */ table.MsoNormalTable {mso-style-name:"Table Normal"; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-priority:99; mso-style-qformat:yes; mso-style-parent:""; mso-padding-alt:0in 5.4pt 0in 5.4pt; mso-para-margin:0in; mso-para-margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:10.0pt; font-family:"Times New Roman","serif";} One of the most time-consuming procedures of a database application is establishing a connection. The connection pooling of the data source can be used to minimize this overhead.  That argues for using the data source instead of accessing the database driver directly. Configuring the size of the pool in the data source is somewhere between an art and science – this article will try to move it closer to science.  From the beginning, WLS data source has had an initial capacity and a maximum capacity configuration values.  When the system starts up and when it shrinks, initial capacity is used.  The pool can grow to maximum capacity.  Customers found that they might want to set the initial capacity to 0 (more on that later) but didn’t want the pool to shrink to 0.  In WLS 10.3.6, we added minimum capacity to specify the lower limit to which a pool will shrink.  If minimum capacity is not set, it defaults to the initial capacity for upward compatibility.   We also did some work on the shrinking in release 10.3.4 to reduce thrashing; the algorithm that used to shrink to the maximum of the currently used connections or the initial capacity (basically the unused connections were all released) was changed to shrink by half of the unused connections. The simple approach to sizing the pool is to set the initial/minimum capacity to the maximum capacity.  Doing this creates all connections at startup, avoiding creating connections on demand and the pool is stable.  However, there are a number of reasons not to take this simple approach. When WLS is booted, the deployment of the data source includes synchronously creating the connections.  The more connections that are configured in initial capacity, the longer the boot time for WLS (there have been several projects for parallel boot in WLS but none that are available).  Related to creating a lot of connections at boot time is the problem of logon storms (the database gets too much work at one time).   WLS has a solution for that by setting the login delay seconds on the pool but that also increases the boot time. There are a number of cases where it is desirable to set the initial capacity to 0.  By doing that, the overhead of creating connections is deferred out of the boot and the database doesn’t need to be available.  An application may not want WLS to automatically connect to the database until it is actually needed, such as for some code/warm failover configurations. There are a number of cases where minimum capacity should be less than maximum capacity.  Connections are generally expensive to keep around.  They cause state to be kept on both the client and the server, and the state on the backend may be heavy (for example, a process).  Depending on the vendor, connection usage may cost money.  If work load is not constant, then database connections can be freed up by shrinking the pool when connections are not in use.  When using Active GridLink, connections can be created as needed according to runtime load balancing (RLB) percentages instead of by connection load balancing (CLB) during data source deployment. Shrinking is an effective technique for clearing the pool when connections are not in use.  In addition to the obvious reason that there times where the workload is lighter,  there are some configurations where the database and/or firewall conspire to make long-unused or too-old connections no longer viable.  There are also some data source features where the connection has state and cannot be used again unless the state matches the request.  Examples of this are identity based pooling where the connection has a particular owner and XA affinity where the connection is associated with a particular RAC node.  At this point, WLS does not re-purpose (discard/replace) connections and shrinking is a way to get rid of the unused existing connection and get a new one with the correct state when needed. So far, the discussion has focused on the relationship of initial, minimum, and maximum capacity.  Computing the maximum size requires some knowledge about the application and the current number of simultaneously active users, web sessions, batch programs, or whatever access patterns are common.  The applications should be written to only reserve and close connections as needed but multiple statements, if needed, should be done in one reservation (don’t get/close more often than necessary).  This means that the size of the pool is likely to be significantly smaller then the number of users.   If possible, you can pick a size and see how it performs under simulated or real load.  There is a high-water mark statistic (ActiveConnectionsHighCount) that tracks the maximum connections concurrently used.  In general, you want the size to be big enough so that you never run out of connections but no bigger.   It will need to deal with spikes in usage, which is where shrinking after the spike is important.  Of course, the database capacity also has a big influence on the decision since it’s important not to overload the database machine.  Planning also needs to happen if you are running in a Multi-Data Source or Active GridLink configuration and expect that the remaining nodes will take over the connections when one of the nodes in the cluster goes down.  For XA affinity, additional headroom is also recommended.  In summary, setting initial and maximum capacity to be the same may be simple but there are many other factors that may be important in making the decision about sizing.

    Read the article

  • SQL Server 2005, Sudden increase of connections - SharePoint 2007

    - by CrazyNick
    We observed that sudden increase of SQL connections during a specific hour, it is a backend of a SharePoint 2007 Farm. From SharePoint 2007 Perspective: 1. Incremental crawling is scheduled at that time and few of the Timer jobs (normal timer jobs) are scheduled to run every mins / per 10mins. 2. Number of user requests are less. From SQL Server 2005 Perspective: 1. Transaction log backup is scheduled at that time 2. No other scheduled jobs are running at that time. so, how to narrow down the issue, what would be causing the sudden SQL connection increase?

    Read the article

  • Websphere MQ using JMS, closed connections stuck on the MQ

    - by Ahmad
    I have a simple JMS application deployed on OC4J under AIX server, in my application I'm listening to some queues and sending to other queues on a Websphere MQ deployed under AS400 server. The problem is that my connections to these queues are terminated/closed when it stays idle for some time with the error MQJMS1016 (this is not the problem), and when that happens I attempt to recover the connection and it works, however, the old connection is stuck at the MQ and would not terminate until it is terminated manually. The recovery code goes as follows: public void recover() { cleanup(); init(); } public void cleanup(){ if (session != null) { try { session .close(); } catch (JMSException e) { } } if (connection != null) { try { connection.close(); } catch (JMSException e) { } } } public void init(){ // typical initialization of the connection, session and queue... }

    Read the article

  • Advice on HTTPS connections using Ruby on Rails

    - by user502052
    Since I am developing a "secure" OAuth protocol for my RoR3 apps, I need to send protected information over the internet, so I need to use HTTPS connections (SSL/TSL). I read How to Cure Net::HTTP’s Risky Default HTTPS Behavior aticle that mentions the 'always_verify_ssl_certificates' gem, but, since I want to be more "pure" (it means: I do not want to install other gems, but I try to do everything with Ruby on Rails) as possible, I want to do that work without installing new gems. I read about 'open_uri' (it is also mentioned in the linked article: "open_uri is a common exception - it gets things right!") that is from the Ruby OOPL and I think it can do the same work. So, for my needs, is 'open_uri' the best choice (although it is more complicated of 'always_verify_ssl_certificates' gem)? If so, can someone help me using that (with an example, if possible) because I have not found good guides about?

    Read the article

  • Atomikos with Hibernate will exhaust db connections

    - by peter
    I am testing an application (Spring 2.5, Hibernate 3.5.0 Beta, Atomikos 3.6.2, and Postgreql 8.4.2) with the configuration for the DAO listed below. The problem that I see is that the pool of 10 connections with the dataSource gets exhausted after the 10's transaction. I know 'hibernate.connection.release_mode' has no effect unless the session is obtained with openSession rather then using a contextual session. I am wandering if anyone has found a way to instruct atomikos code to release connections after any transaction. Thank you Peter <bean id="dataSource" class="com.atomikos.jdbc.AtomikosDataSourceBean" init-method="init" destroy-method="close"> <property name="uniqueResourceName"><value>XADBMS</value></property> <property name="xaDataSourceClassName"> <value>org.postgresql.xa.PGXADataSource</value> </property> <property name="xaProperties"> <props> <prop key="databaseName">${jdbc.name}</prop> <prop key="serverName">${jdbc.server}</prop> <prop key="portNumber">${jdbc.port}</prop> <prop key="user">${jdbc.username}</prop> <prop key="password">${jdbc.password}</prop> </props> </property> <property name="poolSize"><value>10</value></property> </bean> <bean id="sessionFactory" class="org.springframework.orm.hibernate3.LocalSessionFactoryBean"> <property name="dataSource"> <ref bean="dataSource" /> </property> <property name="mappingResources"> <list> <value>Abc.hbm.xml</value> </list> </property> <property name="hibernateProperties"> <props> <prop key="hibernate.dialect">org.hibernate.dialect.PostgreSQLDialect</prop> <prop key="hibernate.show_sql">on</prop> <prop key="hibernate.format_sql">true</prop> <prop key="hibernate.connection.isolation">3</prop> <prop key="hibernate.current_session_context_class">jta</prop> <prop key="hibernate.transaction.factory_class">org.hibernate.transaction.JTATransactionFactory</prop> <prop key="hibernate.transaction.manager_lookup_class">com.atomikos.icatch.jta.hibernate3.TransactionManagerLookup</prop> <prop key="hibernate.connection.release_mode">auto</prop> <prop key="hibernate.current_session_context_class">org.hibernate.context.JTASessionContext</prop> <prop key="hibernate.transaction.auto_close_session">true</prop> </props> </property> </bean> <!-- Transaction definition here --> <bean id="userTransactionService" class="com.atomikos.icatch.config.UserTransactionServiceImp" init-method="init" destroy-method="shutdownForce"> <constructor-arg> <props> <prop key="com.atomikos.icatch.service"> com.atomikos.icatch.standalone.UserTransactionServiceFactory </prop> </props> </constructor-arg> </bean> <!-- Construct Atomikos UserTransactionManager, needed to configure Spring --> <bean id="AtomikosTransactionManager" class="com.atomikos.icatch.jta.UserTransactionManager" init-method="init" destroy-method="close" depends-on="userTransactionService"> <property name="forceShutdown" value="false" /> </bean> <!-- Also use Atomikos UserTransactionImp, needed to configure Spring --> <bean id="AtomikosUserTransaction" class="com.atomikos.icatch.jta.UserTransactionImp" depends-on="userTransactionService"> <property name="transactionTimeout" value="300" /> </bean> <!-- Configure the Spring framework to use JTA transactions from Atomikos --> <bean id="txManager" class="org.springframework.transaction.jta.JtaTransactionManager" depends-on="userTransactionService"> <property name="transactionManager" ref="AtomikosTransactionManager" /> <property name="userTransaction" ref="AtomikosUserTransaction" /> </bean> <!-- the transactional advice (what 'happens'; see the <aop:advisor/> bean below) --> <tx:advice id="txAdvice" transaction-manager="txManager"> <tx:attributes> <!-- all methods starting with 'get' are read-only --> <tx:method name="get*" read-only="true" propagation="REQUIRED"/> <!-- other methods use the default transaction settings (see below) --> <tx:method name="*" propagation="REQUIRED"/> </tx:attributes> </tx:advice> <aop:config> <aop:advisor pointcut="execution(* *.*.AbcDao.*(..))" advice-ref="txAdvice"/> </aop:config> <!-- DAO objects --> <bean id="abcDao" class="test.dao.impl.HibernateAbcDao" scope="singleton"> <property name="sessionFactory" ref="sessionFactory"/> </bean>

    Read the article

  • .NET and Closing SQL Server connections

    - by user307076
    I am having a hard time figuring out why the following constructor will not close connnections. When I view the active connections. Here is the code that I have. Public Sub New(ByVal UserID As Integer) Dim oConn As New SqlConnection(ConfigurationManager.ConnectionStrings("connStr").ToString()) Dim cmd As New SqlCommand("stored proc", oConn) Dim sdr As SqlDataReader cmd.CommandType = CommandType.StoredProcedure cmd.Parameters.AddWithValue("@userID", UserID) oConn.Open() sdr = cmd.ExecuteReader() Try If Not sdr.HasRows Then sdr.Close() If Not oConn Is Nothing Then If oConn.State <> ConnectionState.Closed Then oConn.Close() End If End If cmd.Dispose() Exit Sub End If 'User has account in WATS, proceed to load account information While sdr.Read _firstname = Convert.ToString(sdr("First Name")) _lastname = Convert.ToString(sdr("Last Name")) End While Catch ex As Exception 'Throw New Exception("User Error: " + ex.Message) Finally sdr.Close() If Not oConn Is Nothing Then If oConn.State <> ConnectionState.Closed Then oConn.Close() End If End If cmd.Dispose() End Try End Sub

    Read the article

< Previous Page | 13 14 15 16 17 18 19 20 21 22 23 24  | Next Page >