Tilbake til start (Read with Google translator)
Fordelen
På jobben har vi fått ganske mye bruk av JMS. Det er ganske så kjekt å bruke dette til å lage løst koplede løsninger, men dette er ikke nødvendigvis helt uten utfordringer... Utfordingene er at nå kopler man sammen applikasjoner via en kø. Køen 'eies' av en såkallt buss, Buss'en overføre meldingene mellom køene. Bussen er ren infrastruktur, og dermed har ikke applikasjonene noe forhold til hvordan meldingene kommer fram. Det er nettopp dette som er fordelen med løst koplede systemer, man kan bytte ut bussen uten at applikasjonene 'merker' dette eller har noe forhold til det.
Ulempen
Så til sakens kjerne; Utfordingen nå er at meldinger blir borte ... Vel, de blir ikke borte, man kan merke meldinegen med at de aldri skal bli borte, da vil disse bli lagret på bussen helt til mottakeren har kvittert ut at meldingen er mottat. Problemet er at ulike årsaker kan medføre at meldingen bare blir liggende i en kø, og køen bare vokser og vokser, helt til det sprekker. Køen har nemlig en øvre grense over hvor mange meldinger den kan ha (litt forenklet, for det er MessageEngine som har denne begrensningen, men skal ikke gå for dypt inn i detaljene her. Se mer i ESB)
Problemet
Bussen må overvåkes. Hvordan overvåke infrastrukturen mhp meldinger ? Man må ha en kø monitor ! Og dette får man kjøpt, men slike overvåkingsverktøy er ganske kostbare og må ofte konfigureres og installeres i ukesvis før dette kan brukes... Sånnt får man ikke penger til uten månedsvis med analyser og prioriteringer..
Om å ta skjea i egen hånd
Vi kjører WebSphere på jobben og her finnes det api for alt mulig nært sagt..Så da er det bare å ta fra manualen, Google og WebSphere Forums.. Og etter litt prøving og feileing har jeg laget et lite program som kopler til infrastrukture og leser ut alle køene og sjekker hvor mange meldinger som ligger i køen. Normalsituasjonen er at det skal være 0 meldinger i køen, og hvis antallet øker er dette et tidlig tegn på at det er et problem i infrastrukturen. I dag opplever vi at dette øker til grensen på 50.000 og så stopper alt opp. Nå kan vi legge inn en grense på f.eks 1000. Hvis antallet overstiger 1000, så kan man sende en e-post eller alarmere på en annen måte og så kan infrastruktur folka titte på dette før dte blir et stort problem
Koden
Det er overraskene få kodelinjer som skal til for å gjøre dette. Jeg har her tatt bort unntaksbehandlingen og skriver kun ut køene og antall meldinger som er i køene
Properties connectProps = new Properties();
connectProps.setProperty(
AdminClient.CONNECTOR_TYPE, AdminClient.CONNECTOR_TYPE_SOAP);
connectProps.setProperty(AdminClient.CONNECTOR_HOST, "host");
connectProps.setProperty(AdminClient.CONNECTOR_PORT, "8879"); // 8879 is the default port in WebSphere
connectProps.setProperty(AdminClient.USERNAME, "user");
connectProps.setProperty(AdminClient.PASSWORD, "password");
AdminClient adminClient = AdminClientFactory.createAdminClient(connectProps);
Set s2 = adminClient.queryNames(new ObjectName("WebSphere:*,type=SIBQueuePoint"), null);
if (!s2.isEmpty()) {
Iterator<ObjectName> i = s2.iterator();
while(i.hasNext())
{
ObjectName on = i.next();
String type = on.getKeyProperty("type");
Object object = adminClient.getAttribute(on , "depth");
System.out.println(Size : " + ((Long)object).longValue() + " BUS: " + on.getKeyProperty("SIBus") + " > " + on.getKeyProperty("name"));
}
} else
System.out.println("Node agent MBean was not found");