| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| IA91 Cache Nodes, Broker Domain Caches and ASBITSTREAM |
« View previous topic :: View next topic » |
| Author |
Message
|
| Calvino |
 Posted: Fri May 18, 2007 2:45 am Post subject: IA91 Cache Nodes, Broker Domain Caches and ASBITSTREAM |
 |
|
Novice
Joined: 06 Mar 2004
Posts: 19
Location: Scotland
|
Hi there I wondered if anyone had come across this problem before or has any ideas how to circumvent it?
We have a service which requires to store multiple messages from a back end, and then stitch them all up and forward on .... To best accomplish this we decided to use IA91 and set up a cache to store the replies in. We had this all working fine on 1 broker using an execution group level cache, but when we changed the cache scope to 'broker domain' we started hitting problems.
I have done a fair bit of investigation and narrowed the problem down to our use of the 'ASBITSTREAM' function.
We are using ESQL to call the java functions, and have successfully put a message into a broker domain cache and retrieved it using the following code:
| Code: |
--Put into Cache
SET OutputLocalEnvironment.Variables.CacheData.Input = 'TestData';
SET Status = Shared_Procedures.putIntoNamedCache
('Test', InputRoot.XML.Message.Key, OutputLocalEnvironment.Variables.CacheData.Input, 300000, TRUE);
|
However, when we try to use ASBITSTREAM to put a whole message into the cache things start to go wrong ...
The following code works fine, and returns the bitstream as expected:
| Code: |
--Put into Cache
SET OutputLocalEnvironment.Variables.CacheData.Input = ASBITSTREAM(InputRoot.XML);
SET Status = Shared_Procedures.putIntoNamedCache
('Test', InputRoot.XML.Message.Key, OutputLocalEnvironment.Variables.CacheData.Input, 300000, FALSE);
|
Returns bitstream as below
3c4d6573736167653e3c4b65793e3431346435313230343434353536333033303331353833373230323032303230343565313762366432313861386430313c2f4b65793e3c446174613e54657374446174613c2f446174613e3c2f4d6573736167653e
But when we change the scope to broker domain we get something like the following output from the cache: B@77e1b346
We've switched trace on via the Cache Config Node and it looks like the cache nodes do some extra conversion on the data - eg this is an extract of a test message being put into the cache:
2007-05-18 11:21:12.384 Pub4 Publisher onMessage | Received message (ITest@@414d512044455630303158372020202045e17b6d218a8302@@300000@@[B@8f26982)
2007-05-18 11:21:12.384 Pub4 Publisher onMessage | Put in cache Test, key=414d512044455630303158372020202045e17b6d218a8302, timeout=300000, value=[B@8f26982
2007-05-18 11:21:12.384 Pub4 Cache ] put Test
So it appears that when we use ASBITSTREAM in a broker domain level cache, the message is not being converted back properly when we retrieve it .....
Any ideas on how to proceed gratefully received ....
We're also going to try and contact the author (unless he happens to read this first ...  )
Thanks in advance
Corrine |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Fri May 18, 2007 3:02 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Hi Corrine.
When putting stuff into the cache using as Bitstream always specify encoding and CCSID (the one you want the cache to be in, not the one of the broker).
This way all of the parts of the message have the same CCSID and encoding. You can then conatenate them and parse them back correctly.
On parsing use CCSID and Encoding as well....
I suspect you have brokers with different CCSIDs in your domain...
Enjoy 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| Calvino |
| Posted: Fri May 18, 2007 4:13 am Post subject: |
|
|
Novice
Joined: 06 Mar 2004
Posts: 19
Location: Scotland
|
Hi fjb
We've tried it using specific CCSID and encoding too but we still get the same issue.
Ignoring the actual parsing of the message for now, what I am confused about is why the code returns a bitstream when the scope is set to EG, but as soon as we change the scope to broker domain we get something completely different back - if we could identify what this 'something' is then we could probably work out how to parse it correctly.
Why do we get this for the broker domain cache [B@8f26982
but this for the EG level cache 3c4d6573736167653e3c4b65793e34313464353132 ....
(edited)
Could it be base64 encoded or something like that? And shouldn't the support pac return the same value regardless of the scope of the cache? ...  |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri May 18, 2007 4:20 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
This does look like a bug. You should contact the author of the support pack.
What that value is, is a Java object ID. I'd guess, somehow, that the cache is having trouble serializing that object when passing it across the real-time pub/sub bus. Or unserializing it...
You did actually deploy a RealTimeOptomizedFlow node somewhere, right? To enable the broker level caching?
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| Calvino |
| Posted: Fri May 18, 2007 4:27 am Post subject: |
|
|
Novice
Joined: 06 Mar 2004
Posts: 19
Location: Scotland
|
Cheers Jeff
We are trying to contact him right now! From what I can see from the trace, it looks like the problem is possibly at the unserialising stage ....
We do have a RealTimeOptimizedFlow deployed on a broker and we have done some testing of basic messages - caching on 1 broker and retrieving the cached data from another broker. Everything worked fine, so as far as the underlying broker domain setup is concerned I'm happy that its OK - the problem seems confined to this particular situation! |
|
| Back to top |
|
|
| tfhays |
| Posted: Mon May 21, 2007 8:08 am Post subject: |
|
|
Newbie
Joined: 18 Jan 2006
Posts: 8
|
Interesting.
Tony Hays here, current owner of IA91. I'll take a look and see if I can recreate it. If I can, I may be able to fix it. If not, I may need more information (what version of IA91, full trace output, etc.) to find/fix it.
Regards, T. |
|
| Back to top |
|
|
| tfhays |
| Posted: Mon May 21, 2007 8:26 am Post subject: |
|
|
Newbie
Joined: 18 Jan 2006
Posts: 8
|
Hi, this is Tony again.
Well, looking at the code revealed at least part of the problem and a possible answer.
When you use Broker Domain caching, I currently have to transmit the value to the other broker via a string; apparently a bitstream isn't a string. Or at least, the toString for a bitstream doesn't return a string. Which makes sense, because ASBITSTREAM doesn't return a CHAR, it returns a BLOB.
When you use local caching only, I can store the value as an object directly, although I'm actually not sure in this case that this is such a good idea. I don't know that storing a BLOB reference like this is actually encouraged by the broker API. If I create a new copy of it, maybe....
In the IA91 documentation, I do say that I have only tested this with string values. You may want to cast the BLOB value to CHAR before storing it into the cache. That should eliminate the issue with Broker Domain caching.
I do have it on my to-do list to someday determine if I can actually store something other than string values in IA91 (like BLOB and ROW type variables, for example). However, that is a very large task for another time.
Regards, T. |
|
| Back to top |
|
|
| vmcgloin |
| Posted: Tue May 22, 2007 12:36 am Post subject: |
|
|
Knight
Joined: 04 Apr 2002
Posts: 560
Location: Scotland
|
Thanks for the quick response Tony.
I will try casting the BLOB value to CHAR before storing it into the cache, and vice versa after retrieving it and post an update here.
Thanks,
Vicky |
|
| Back to top |
|
|
| vmcgloin |
| Posted: Tue May 22, 2007 2:53 am Post subject: |
|
|
Knight
Joined: 04 Apr 2002
Posts: 560
Location: Scotland
|
It works great now.
Next time I'll be more careful to make sure what we are coding is actually supported. The reason we are using ASBITSTREAM is because it is an MRM message tree we want to store, and I was assuming that if it was a bitstream then it would behave as a string. Thanks again for your time - and a very useful supportpac.
Cheers,
Vicky |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
