You could write an api program that would hit all threads on all queues, only problem with this approach is that it will block ALL operations on the server for all the queues you are hitting. This would also have to be timed with the state expiration policy on the firewall, which for most firewalls are somewhere in the neighborhood of the following table:
tcp.first 120s tcp.opening 30s tcp.established 86400s tcp.closing 900s tcp.finwait 45s tcp.closed 90s tcp.tsdiff 30s * with tcp.established being the relevant parameter A keep-alive from arserver would be ideal, but only the people at BMC can make that happen, which, as unfortunate as it is, usually means a lot of waiting, the "don't hold your breath" kind of waiting. Hope someone with a mind to read the list and other web communities gets the AR System product manager position that David posted. Axton Grams On 9/20/07, Carey Matthew Black <[EMAIL PROTECTED]> wrote: > Just a few WAGs... I am not sure if these would cause DB IO for each > thread or not: > Maybe you could force the server to re-read is db? ( arsignal -g ) > Maybe you could change an ARS object's helptext and try force the > server to shake the threads.... > > > You could also write a small api program to login and used all the > right RPC numbers... but that would be tedious. And I am not sure you > could hit all of the threads in the Fast/List/Private set to. That > would be a bit more difficult, and exactly what your trying to do. :( > > -- > Carey Matthew Black > Remedy Skilled Professional (RSP) > ARS = Action Request System(Remedy) > > Love, then teach > Solution = People + Process + Tools > Fast, Accurate, Cheap.... Pick two. > > > > On 9/19/07, Axton <[EMAIL PROTECTED]> wrote: > > The escalation is (was) single threaded; in order to send traffic over > > every db connection, you have to exercise every thread. Since the > > escalation engine is single threaded, it will only occupy that one > > thread. If you notice in the arerror.log that all filter errors > > reported show 390693 as the rpc queue, it is executing everything on > > that one thread. > > > > In either case (single/multi-threaded escalation engine), it is only > > exercising the threads associated with the escalation engine, not the > > fast, list, callback, external auth, or custom queues. > > > > Axton Grams > > > > On 9/19/07, patrick zandi <[EMAIL PROTECTED]> wrote: > > > ** > > > Why not an afterhour escalation... instead.. > > > Say every 10 minutes.. to do table queries or a report or two.. > > > from 1800 - 0712 or something... > > > > > > > > > On 9/19/07, Axton <[EMAIL PROTECTED]> wrote: > > > > > > > > "Actually, now that I re-read your post I don't think putting a > > > > specific rule will side-step state checking." > > > > > > > > Depends on your firewall and the rule. Typically, states are created > > > > using only SYN packets, if state can be created on other packet types, > > > > you are still using stateful packet inspection, you are just allowing > > > > different packet types to add the session to the state table. > > > > > > > > "We talked to BMC a few weeks ago and they told us "theoretically" > > > > that it would be possible to write a custom API that would run custom > > > > workflow (neither of which they could give us) that would hit all of > > > > the server's Oracle connections at the same time often enough to > > > > prevent anything from seeing them as idle." > > > > > > > > I was thinking this as I was reading your email, though I am not sure > > > > how you would hit the admin and every fast/list/custom queue's threads > > > > without occupying all of them simultaneously. The api, to my > > > > knowledge, does not give you the capability to control what thread you > > > > are using, which means that your api will have to be multi-threaded > > > > and will have to occupy the max number of configured threads per rpc > > > > queue, which will cause your remedy server to appear to hang (i.e., > > > > block other operations on those queues). > > > > > > > > Can you share what type of firewall you are using? > > > > > > > > If you really want to remove the firewall from the equation, remove it > > > > from the network, or completely disable it. I can't see that vlan > > > > tagging would cause any issues with this. vlan's are configured in > > > > one of two way's, on the switch per port or the tagging is handled by > > > > the end nodes. If it is on the switch, it will be transparent to the > > > > client. > > > > > > > > Axton Grams > > > > > > > > On 9/19/07, J.T. Shyman < [EMAIL PROTECTED]> wrote: > > > > > ** > > > > > > > > > > > > > > > > > > > > Axton, > > > > > > > > > > > > > > > > > > > > Appreciate your input! > > > > > > > > > > > > > > > > > > > > I should have mentioned that we've been up and down that highway > > > and > > > > > > > > > > haven't seen a blasted thing. (apologies to Glen Frey) > > > > > > > > > > > > > > > > > > > > What you are saying is exactly what I thought and we've disabled > > > the > > > > > > > > > > idle timeout on the firewall. I know this may not be the same thing as > > > > > > > > > > preventing the firewall from using a state table but the firewall > > > > > admin > > > > > > > > > > tells us he now sees idle connections with idle times > 60 minutes. > > > > > So, > > > > > > > > > > we're kind of thinking we've eliminated the firewall as a > > > > > > > > > > cause...although we may not have, we aren't pursuing that any longer. > > > > > > > > > > > > > > > > > > > > Actually, now that I re-read your post I don't think putting a > > > > > > > > > > specific rule will side-step state checking. The purpose of a state > > > table > > > > > > > > > > on a firewall is to speed up handling of traffic by allowing already > > > known > > > > > > > > > > good traffic to pass without undergoing validation against the > > > > > rulebase > > > > > > > > > > for every packet. Adding a rule that allows a single port connection, > > > > > > > > > > which is what we had before, doesn't stop the state table from > > > > > > > > > > functioning. In fact, it may actually be what causes the connection to > > > be > > > > > > > > > > put in the state table in the first place, no? Also, turning the > > > firewall > > > > > > > > > > into, effectively, a packet-based firewall might have a detrimental > > > affect > > > > > > > > > > on network throughput not only between AR and Oracle but for any other > > > > > > > > > > connections on that firewall due to increased overhead...or am I > > > > > wrong? > > > > > > > > > > > > > > > > > > > > Additionally, we the firewall admin put in ANY<->ANY rule in > > > > > place > > > a > > > > > > > > > > few nights ago and the problem is still occurring. I'd hoped that this > > > > > > > > > > would circumvent the state table but it apparently doesn't. > > > > > > > > > > > > > > > > > > > > I don't suppose there is a AR-based solution? We could keep > > > > > trying > > > > > > > > > > changes on the network until we effectively distroy any semblance of > > > > > the > > > > > > > > > > original network design but that wouldn't mollify anyone. In fact, it > > > may > > > > > > > > > > have the opposite affect. > > > > > > > > > > > > > > > > > > > > We talked to BMC a few weeks ago and they told us "theoretically" > > > > > > > > > > that it would be possible to write a custom API that would run custom > > > > > > > > > > workflow (neither of which they could give us) that would hit all of > > > > > the > > > > > > > > > > server's Oracle connections at the same time often enough to prevent > > > > > > > > > > anything from seeing them as idle. Does this sound like a good > > > > > approach > > > to > > > > > > > > > > anyone? Any and all thoughts and comments are welcome! > > > > > > > > > > > > > > > > > > > > Thanks! > > > > > > > > > > > > > > > > > > > > J.T. > > > > > > > > > > > > > > > > > > > > __20060125_______________________This posting was > > > > > submitted with HTML in it___ > > > > > > > > > > > _______________________________________________________________________________ > > > > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where > > > the Answers Are" > > > > > > > > > > > > > > > > -- > > > Patrick Zandi __20060125_______________________This posting > > > was submitted with HTML in it___ > > > > _______________________________________________________________________________ > > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where > > the Answers Are" > > > > _______________________________________________________________________________ > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the > Answers Are" > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
