Thank you LJ. I'm afraid the ideas for the c plugin haven't panned out, but I have a better idea of what is in my config files now! Always a good thing. I'm going to tackle the JAVA plugin now. I'll let you know what I find.
On Wed, Jan 28, 2015 at 11:50 AM, LJ LongWing <lj.longw...@gmail.com> wrote: > ** > Warren, > I first off apologize if any of this is rudimentary, or basic...but I want > to make sure that everything is clear and understood properly :) > > So, there are two different types of plugins > > C - These plugins are loaded in the ar.cfg file with a line similar to > Plugin: ServerAdmin.dll > > This is the only configuration, in general for these. The C plugin server > is loaded through the armonitor.cfg with a line that looks similar to > "<install path>\arplugin.exe" -i "<install path>" -m > > So, in your final example, the plug-in does not exist for server > administration....the 'Plugin: ServerAdmin.dll' is the line you are looking > for to exist in your ar.cfg file. > > The log file for C plugins is turned on/off through the Server Information > Console for with the name 'Plugin'. > > The other Plugin server is going to be a Java one > > Java ones are significantly more complicated. They are defined in > multiple places. First, in ar.cfg file, you will see a line similar to > > Server-Plugin-Alias: ARSYS.ALRT.TWITTER ARSYS.ALRT.TWITTER > <server-name>:9999 > > This line has several components that need to be explained, here is a > template of this > > Server-Plugin-Alias: <what the workflow calls it> <what it's configured > name is> <server the plugin server runs on>:<port the plugin server runs on> > > So....typically the first two are the same, unless you are wanting to run > two different instances of the same plugin, in which case the alias (the > first parameter would be different on the two instances, but the second > would be the same).... > > Now, in Server group scenarios, each server in the server group is > typically going to be running its own plugin servers, and you want the > server to connect to its OWN plugin server, so the <server-name> is > typically going to be that host, not the 'group' name, so I'll give an > example > > Server 1: > Server-Name: remedy-prod > Server-Connect-Name: remedy-prod-node1 > > Server 2: > Server-Name: remedy-prod > Server-Connect-Name: remedy-prod-node2 > > So, in this case, remedy-prod is going to be typically a load balancer > that at any point in time would point to either of the individual nodes, > where as remedy-prod-node1/2, are going to be DNS aliases (or even host > names) that point to a specific node. > > So, you will want your server-name in the Server-Plugin-Alias defined to > point to either node 1 or node 2 (as appropriate) > > The 4th piece is the port. This is defined in the pluginsvr_config.xml > for that particular plugin server...the default one is 9999, but in ITSM, > there are typically 3 or 4 of them that are running at any given time, so > the port is typically specific to the server...I don't use ITSM, so I don't > know their default ports for various functions > > Now....the Java plugin server is also started by the armonitor.cfg file, > but looks more like this > > "<path to java>\java" -Xmx512m -classpath "<path to > install>\pluginsvr;<path to > install>\pluginsvr\arpluginsvr81_build001.jar;<path to > install>\approval\bin\armaskingImpl81_build001.jar;<path to > install>\arserver\api\lib\arcmnapp81_build001.jar" > com.bmc.arsys.pluginsvr.ARPluginServerMain -x <server-name> -i "<path to > install>" -m > > Now, the important thing I have found about this line is that the -i > parameter should match what you have in your ar.cfg as the > 'server-name'...it doesn't really NEED to as long as both respond to the > same machine and such, but I have seen problems such as you are reporting > that it can't connect, and I have never had anyone report that after making > them the same, they still had problems. > > So, that's how the plugin server is loaded, and how the Remedy server > references the plugin name, now, going back to what loads it...that's in > the pluginsvr_config.xml file...for the one that defaults to 9999, that's > in the <install directory>\pluginsvr folder. Using the same example of the > ARSYS.ALRT.TWITTER plugin, this is what actually LOADS that plugin > > <plugin> > <name>ARSYS.ALRT.TWITTER</name> > <pathelement type="location"><path to > install>/pluginsvr/aralerttwitter81_build001.jar</pathelement> > > > <classname>com.bmc.arsys.plugins.alert.twitter.TwitterAlertDeliveryPlugin</classname> > </plugin> > > so, all 3 of those elements (ar.cfg, armonitor.cfg, > and pluginsvr_config.xml) must be in place properly for the plugin to load > properly. > > Now...logging for each Java Plugin server is defined in the > respective log4j_pluginsvr.xml file for each plugin server. You will find > an entry in that file that looks something like > > <appender class="org.apache.log4j.RollingFileAppender" name="PluginLog"> > <param name="File" value="<path to > install>/ARServer/Db/arjavaplugin.log"/> > <param name="MaxFileSize" value="5MB"/> > <!-- Keep two backups --> > <param name="MaxBackupIndex" value="2"/> > <layout class="org.apache.log4j.PatternLayout"> > <param name="ConversionPattern" value="%d %-5p [%t] %C (%F:%L) - > %m%n"/> > </layout> > </appender> > and then several lines that look like > <logger additivity="true" name="com.bmc.arsys.pluginsvr"> > <level value="warn"/> > </logger> > I typically set all of these to debug. These are not changeable during > runtime like the C plugin is...so I just set them to debug and let them run > constantly. > > So.....with this, you should be able to take a look at your configurations > and ensure that everything is correct.....please come back and ask any > clarifying question you might have :) > > > > On Wed, Jan 28, 2015 at 9:06 AM, Warren R. Baltimore II < > warrenbaltim...@gmail.com> wrote: > >> ** >> >> Good morning/afternoon/evening! >> >> Recently, we've been seeing plugin errors creeping into our environment. >> They have now gotten to a point where the system can no longer function as >> designed. >> >> ARS 7.6.04 Patch 5 >> >> CMDB 7.6.05 Patch 5 >> >> Mid-Tier 7.6.04 Patch 5 >> >> Apache Tomcat 6.0.20 >> >> Windows 2008 Standard Server (virtual) >> >> MS SQL 2008 >> >> We are seeing similar issues with different functionality on both our Dev >> and Prod environments. >> >> PRODUCTION >> >> 3 identical application servers and 3 identical Mid Tier servers (running >> Apache Tomcat 6.0.20). >> >> We see the following error when we try to create a "Seat" in our CMDB. >> >> [SERVER_GROUP_NAME] (9555) BMC.FILTERAPI.NORM.ENGINE : RPC: Miscellaneous >> tli error - System error (connection refused) >> >> If we attempt to open the Impact Simulator, we see a similar error: >> Cannot establish a network connection to the AR System Plug-In server : >> [SERVER_GROUP_NAME] (9556) AIS.FILTERAPI : RPC: Miscellaneous tli error - >> System error (Connection refused) (ARERR 8760) >> >> We turned down 2 of the 3 app servers and did not receive the error. >> However when we bring up the other 2, we continue to see them. >> >> >> DEVELOPMENT >> >> We see similar errors, but they come about differently. >> >> Single app server and a single mid tier. >> >> When we open the "AR System Administration: Server Information" form, we >> see this error: >> >> >> >> The specified plug-in does not exist. : >> REMEDY.ARDBC.SERVER.ADMINISTRATION (ARERR 8755) >> >> >> >> TROUBLESHOOTING TO DATE >> >> I've checked our ar.cfg files and armonitor files and they seem to be >> pointing to all the right places. I can't find anything that is specific >> to this error in the kbase (although I've found things similar). When I >> run through the troubleshooting for these similar things, everything seems >> to be OK. >> >> We have turned on just about every type of logging we can thing of. And >> other than the Plug in does not exist error, we haven't found anything. >> >> >> >> I suspect I have missed something. I'm hoping this will ring a bell with >> someone out there. >> >> I did open a ticket with BMC. They have escalated the issue to >> Engineering. >> >> Any help would be most appreciated. >> >> >> Thank you in Advance! >> >> Warren >> >> >> -- >> Warren R. Baltimore II >> Remedy Developer >> 410-533-5367 >> _ARSlist: "Where the Answers Are" and have been for 20 years_ > > > _ARSlist: "Where the Answers Are" and have been for 20 years_ > -- Warren R. Baltimore II Remedy Developer 410-533-5367 _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
