| Author |
Message
|
| Vitor |
 Posted: Wed Sep 01, 2010 7:01 am Post subject: |
 |
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| codemonkey wrote: |
| Can you tell me why I should be using the XMS assembly from the client install rather than the supportpac? |
Because there's no point in using the support pac if you're using v7 that has XMS support built it.
Because the support pac (despite some slightly dubious wording) isn't supported for v7.
Because the inbuilt XMS support in v7 will be developed & get bug fixes. The support pac will not.
There are undoubtably other reasons. I'm also surprised & interested to discover they're the same; I was given to understand v7 differed from the v6 (support pac) offering internally.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Wed Sep 01, 2010 7:44 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Also, just because the version # is the same, doesn't mean that the actual code is quite the same.
You might, for example, find that there are more IBM.XMS.<*>.DLL files in the product install than in the supportPac. For example, I'd be a bit surprised if the supportPac came with IBM.XMS.WCF.dll..
Everything else my esteemable colleague said is correct, that the one that ships with the product is supported and subject to PMRs and etc. |
|
| Back to top |
|
|
| codemonkey |
| Posted: Wed Sep 01, 2010 8:45 am Post subject: |
|
|
Novice
Joined: 20 Jul 2010
Posts: 11
|
| mqjeff wrote: |
Also, just because the version # is the same, doesn't mean that the actual code is quite the same.
You might, for example, find that there are more IBM.XMS.<*>.DLL files in the product install than in the supportPac. For example, I'd be a bit surprised if the supportPac came with IBM.XMS.WCF.dll..
Everything else my esteemable colleague said is correct, that the one that ships with the product is supported and subject to PMRs and etc. |
Ok. I see. This is really getting pretty funny and ridiculous to me because I can't imagine releasing an messenger client (the SupportPac) that I didn't want my users to use. I'm sure you can see how confusing this might be.
Anyway. Yes there are lots of assemblies in the bin directory of the client install that are not in the SupportPac install. I hadn't bothered looking at those. This is good to know. The WCF assembly is especially interesting.
@Vitor You can download a freeware app called BitDiffer (http://www.bitwidgets.com/) and compare the assemblies and see that there are no differences between them. There is actually one difference, it's a guid value. Everything else is exactly the same. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Sep 01, 2010 9:05 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| codemonkey wrote: |
| I can't imagine releasing an messenger client (the SupportPac) that I didn't want my users to use. I'm sure you can see how confusing this might be. |
Well the support pac isn't a client. It's a support pac, which includes client libs.
But if you mean "why did IBM release a support pac that isn't supposed to be used", then a) it was essential if you wanted to use XMS in those days before v7 was released & b) it's still essential for those sites who are starting to use XMS but haven't yet upgraded to v7.
(And you might be surprised how many sites do new development on old and/or out of support levels. Strange but true)
| codemonkey wrote: |
| @Vitor You can download a freeware app called BitDiffer (http://www.bitwidgets.com/) and compare the assemblies and see that there are no differences between them. |
That's nice. If I cared especially I'd run them through my copy of DiffDog.
In this instance I'm more interested in what it does than how it does it, and will assume I misunderstood what I was told. Or they were referring to these other assemblies you've found.
As a wise man once said, "I'm one of those people who are happy to wear cotton, but have no idea how it works".
Extra points for anyone identifying the reference. 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Sep 01, 2010 9:14 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Yes, to be clear, the supportPac is to be used on Version 6.0 Server and Client installs, and not on version 7.0 Server and Client installs.
It wasn't made a part of the product until version 7.
And when I say that the 'version might be the same but not necessarily the code', I mean the GAC assembly version only. |
|
| Back to top |
|
|
| codemonkey |
| Posted: Wed Sep 01, 2010 11:59 am Post subject: |
|
|
Novice
Joined: 20 Jul 2010
Posts: 11
|
Thanks for the replies guys. Though it may not seem like, its been helpful.
Do either of you know the difference between these two factory assemblies?
"IBM.XMS.Impl.WmqiFactoryFactoryImpl";
"IBM.XMS.Impl.WpmFactoryFactoryImpl";
From what I can tell the documentation doesn't provide any information about the XMSFactoryFactory class. It seems the only way to figure out what the factories parameter options mean is to disassemble the XMS library and follow the chain of activity. If you happen to know the differences between these two and don't mind sharing, that would save me some time.
Thanks again. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Sep 01, 2010 2:18 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| codemonkey wrote: |
Thanks for the replies guys. Though it may not seem like, its been helpful.
Do either of you know the difference between these two factory assemblies?
"IBM.XMS.Impl.WmqiFactoryFactoryImpl";
"IBM.XMS.Impl.WpmFactoryFactoryImpl";
From what I can tell the documentation doesn't provide any information about the XMSFactoryFactory class. It seems the only way to figure out what the factories parameter options mean is to disassemble the XMS library and follow the chain of activity. If you happen to know the differences between these two and don't mind sharing, that would save me some time.
Thanks again. |
Don't know but off the top of my head you have 3 types of factories:
- QueueConnectionFactory
- TopicConnectionFactory
- ConnectionFactory (generic, depending on parms will create either a JMS 1.2 factory, or a qcf, or a tcf)
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Sep 01, 2010 3:01 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
XMS tries to be provider neutral, like JMS, even though it is shipped as a WMQ supportPac/part of the WMQ product.
WpmFactoryImpl may be the implementation factory for WebSphere SIBus.
It's really a far better idea to focus on the external documentation rather than trying to code from the assemblies or from the DLLS. |
|
| Back to top |
|
|
| codemonkey |
| Posted: Wed Sep 01, 2010 4:20 pm Post subject: |
|
|
Novice
Joined: 20 Jul 2010
Posts: 11
|
| mqjeff wrote: |
XMS tries to be provider neutral, like JMS, even though it is shipped as a WMQ supportPac/part of the WMQ product.
WpmFactoryImpl may be the implementation factory for WebSphere SIBus.
It's really a far better idea to focus on the external documentation rather than trying to code from the assemblies or from the DLLS. |
I agree. The only problem is that the samples and corresponding documentation actually say not to use the sample code because it could introduce an issue with buffering.
I have a successful prototype running right now. It does all sorts of cool parallel connections and we frequently hit the max number of threads on the queue server, or at least that's what the queue server is reporting back to us. It essentially says it has run out of available resources. I know that's not because of unclosed connections.
So, what I've got right now is probably more than adequate. What I'm most interested in at this point is figuring out how to establish a peer-to-peer connection with MQ to have a sort of real-time connection to publish and consume. I really want to push the throughput to the fastest possible state. I've read that this is done with some binding settings? but I haven't been able to figure out how to get this working yet or find where this is documented. I'm really struggling with the lack of documentation.
Do you guys know where I can find some code samples or docs that explain how to do this? |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Sep 01, 2010 6:11 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
In order to do bindings, you have to run on the same machine as the queue manager.
And then you stop specifying any connection information at all other than the name of the qmgr.
You can otherwise tune your qmgr to provide more available resources to client applications without taking that step.
If you're confused about that part, you may want to engage a consultant. |
|
| Back to top |
|
|
| codemonkey |
| Posted: Thu Sep 02, 2010 6:11 am Post subject: |
|
|
Novice
Joined: 20 Jul 2010
Posts: 11
|
| mqjeff wrote: |
| If you're confused about that part, you may want to engage a consultant. |
lol, which is exactly why this is documented so poorly.
Ok. Clearly I'm not going to get what I need from here. 
 |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Sep 02, 2010 6:39 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| codemonkey wrote: |
| mqjeff wrote: |
| If you're confused about that part, you may want to engage a consultant. |
lol, which is exactly why this is documented so poorly.
Ok. Clearly I'm not going to get what I need from here.
|
Performance tuning in MQ is fairly well documented, particularly in the Performance report SupportPacs.
It's just a complicated topic. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Sep 02, 2010 6:54 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| codemonkey wrote: |
| Ok. Clearly I'm not going to get what I need from here. |
No, you'll get it from here which describes the different .NET connection models.
It also explicitly describes the difference between a client connection (over network) and a bindings connection (via direct call) which explains the increase in speed.
There are also any number of redbooks that talk about tuning both code & queue manager to increase speed.
I think the base problem is that what you need is for the software to work the way you think it should, and for the documentation to be laid out the way you think it should be. Regretably neither of these things are true, nor are they likely to be in the short term. Which is why the suggestion was made that someone more experienced may be able to short circuit the process for me.
It certainly doesn't imply that you're in any way wrong about the software not being constructed correctly (we've discussed my weakness in .NET) nor that the documenation has shortcommings (which everyone has discussed).
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| shashikanth_in |
| Posted: Wed Sep 08, 2010 12:31 am Post subject: |
|
|
Centurion
Joined: 26 Feb 2009
Posts: 123
|
1) IBM Message Service Clients IA9H aka XMS .NET is a category 3 SupportPac and is fully supported. You get bug fixes also. This you can see in the SupporPac website in section "What is new in this release" and that lists the fixes went into a perticular release.
2) It is shipped as part of WebSphere MQ v7.0.1 and also available as a standalone. Both are forms are fully supported.
3) XMS .NET supports connections to WebSphere MQ, WebSphere Application Server and WebSphere Message Broker.
4) You can choose one of the form based on your requirement. If you application just connects to WebSphere MQ, then you could just install WMQ. Connections to WMQ requires WMQ client installation also. Hence it makes sense to install WMQ which will install XMS also.
On the other hand if you are connecting to WAS or WMB and not to WMQ, then you could just install the XMS supportPac.
5) To use XMS .NET API, you include IBM.XMS as a reference in your project. You could see IBM.XMS listed in your GAC.
6) AMQMDNET is for MQ .NET and hence can't be used in XMS .NET applications.
7) XMS .NET provides receiveing message asynchronously using message listerners. Please look at SampleConsumer sample.
9) You should be using any inner interfaces of XMS .NET like IBM.XMS.Impl.WmqiFactoryFactoryImpl";
"IBM.XMS.Impl.WpmFactoryFactoryImpl";
You always use IBM.XMS.
9) On MQ WCF, this is a custom channel functionality provided WMQ and a typical usage pattern scenario is as an interface to web services hosted over WebSphere MQ (SOAP/JMS). There are samples provided with WMQ 7.0.1 and you can have a look at them.
Just to clear the confusion: IA9H supportPac and IBM Message Service Clients shipped with WebSphere MQ v7.0.1 are one and same. Depending on your requirement, you can choose to install any one of them.
Hope this helps to clear most of the confusion/doubts. |
|
| Back to top |
|
|
| shashikanth_in |
| Posted: Wed Sep 08, 2010 8:40 pm Post subject: |
|
|
Centurion
Joined: 26 Feb 2009
Posts: 123
|
Correcting my previos update.
9) You should NOT be using any inner interfaces of XMS .NET like IBM.XMS.Impl.WmqiFactoryFactoryImpl";
"IBM.XMS.Impl.WpmFactoryFactoryImpl";
You should always use IBM.XMS.
Another point to note: ISession instance is what you will be using for sending and receiving messages. ISession objects can't be used across threads. It is recommended you use thread specific ISession instances. |
|
| Back to top |
|
|
|
|
