Working on a smack J2EE resource adapter but

Openfire Openfire Dev
1

I have implemented a JCA 1.5 resource adapter for XMPP based on the smack api but have run into a problem which will require modification to the way XMPPConnection creates and manages Threads through the PacketReader and PacketWriter classes. The purpouse of this post is to solicit comments on a possible solution to this problem.

By way of motivation let me breafly mention what a JCA resource adaptor is for those not in the know. The J2EE spec from 1.3 and later allows for a general interface to external enterprise information systems (EIS) - things like SAP, MQ or for that matter an XMPP server. The JCA framework include things like transaction management, connection pooling etc. By creating a resource adaptor for XMPP it is possible to use XMPP-based services from J2EE components (like for instance EJB session or message-driven beans). It is instructive to view a resource adaptor as a generalization of the JDBC database connection concept.

While doing this I have implemented most of publish-subscribe too but that is not why I need your help now.

The problem is that inside an EJB server components cannot create Threads. Instead the JCA framework provides an interface into the EJB thread management subsystem. This means that in order for my RA to work I need a way to supply alternative implementations of the PacketReader and PacketWriter classes that don’'t call new Thread directly.

I can see a couple of alternatives:

  1. Turn PacketWriter and PacketReader into interfaces. Also create the corresponding

Packet{Reader,Writer}Factory interface. Instances of these interfaces are associated

with the XMPPConnection which allows custom implementations to be set (perhaps

in the constructor).

  1. Modify PacketReader and PacketWriter to provide overridable methods and fields

to allow readerThread and writerThread to be substituted for objects which play the

same roles as theads inside an EJB container.

Personally I much prefer option 1. It is clean and will not affect deployed code. I am

perfectly willing (of course) to provide an implementation of these ideas if there is a

chance they will be acceptable to the community.

Cheers Leif

2

I have relized there is a third option which may be even simpler to implement: Instead of keeping track of the Thread objects in PacketReader and PacketWriter create two Runnables. Also define a SmackScheduler interface with a single method void start(Runnable r) throws Exception; By adding an instance of SmackScheduler (and creating a StandardSmackScheduler) to XMPPConnection it will possible to allow PacketReader and PacketWriter to call SmackScheduler#start() instead of creating Thread instances directly. In my resource adapter I would simply provide a SmackScheduler which calls the JCA WorkManager to create Theads.

How does this sound?

3

Cool! I want to do something similar. Is your code available to browsing and/or contribution?

Firstly, I think you might want to reconsider implementing the underlying IO in an application server. Secondly, the JCA should be an adapter and I would imagine it being an component or external component that talks to the server. Let me address each issue.

If you’‘re using the work manager, you’‘re typically interested in coordinating a transaction with a foreign JTA using XA 2PC protocol. In order for this to work correctly, the work manager is provided to the container to act as a client to the legacy service (or in our case, a not so legacy xmpp server). You might not gain any benefit from implementing the packet reader/writers this way, plus, if you’‘re looking to scale, you’‘ll want to avoid XA tx’‘s altogether. You also don’‘t want a tx associated with every connection, since this is how Jive is built. You’'d run out of resources pretty quickly and debugging xa is no fun.

That brings me to my second point. You probably want to create a component that contains a JTA (see http://jotm.objectweb.org/) and translate each packet into a tx context with the application server. The JCA would be responsible for communicating with the component and coordinating tx’'s that originate from the app server and support those that start from Jive.

My 2c.

4

It will be very soon - I am chasing a bug which seems related to

using the pullparser to construct DOM objects for handling

content in PubSub.

I will release the connector + my PubSub implementation under a

BSD-style license.

Firstly, I think you might want to reconsider

implementing the underlying IO in an application

server. Secondly, the JCA should be an adapter and I

would imagine it being an component or external

component that talks to the server. Let me address

each issue.

If you’‘re using the work manager, you’'re typically

interested in coordinating a transaction with a

foreign JTA using XA 2PC protocol. In order for this

to work correctly, the work manager is provided to

the container to act as a client to the legacy

service (or in our case, a not so legacy xmpp

server). You might not gain any benefit from

implementing the packet reader/writers this way,

plus, if you’‘re looking to scale, you’'ll want to

avoid XA tx’‘s altogether. You also don’'t want a tx

associated with every connection, since this is how

Jive is built. You’'d run out of resources pretty

quickly and debugging xa is no fun.

You are right! I have seen other threads here where the possibility

of using NIO is mentioned. Wouldn’'t that be a way forward?

That brings me to my second point. You probably want

to create a component that contains a JTA (see

http://jotm.objectweb.org/) and translate each packet

into a tx context with the application server. The

JCA would be responsible for communicating with the

component and coordinating tx’'s that originate from

the app server and support those that start from

Jive.

Right now my connector is working in no-tx mode but I will

start to work on implementing the XAResource contract soon.

I would appreciate any thoughts/comments/contributions !

My 2c.Cool! I want to do something similar. Is your code

available to browsing and/or contribution?

5

Hey Leifj

I will release the connector + my PubSub

implementation under a

BSD-style license.

Do you have any idea when that will be, I am very interessted in the pubsub implementation since i migrate some of my projects from PythonJabberPubSub to Java+Smack

Thanks Christoph

6

I am running the connector on jboss and it seems to work. I can give you a pre-release for testing if you like (send mail to leifj@it.su.se).

7

By adding an

instance of SmackScheduler (and creating a

StandardSmackScheduler) to XMPPConnection it will

possible to allow PacketReader and PacketWriter to

call SmackScheduler#start() instead of creating

Thread instances directly. In my resource adapter I

would simply provide a SmackScheduler which calls the

JCA WorkManager to create Theads.

That sounds like a good solution. Would you be willing to create a patch that we could evaluate and then committ?

Thanks!

-Matt

8

Sorry for missing this. I forgot to watch the forum. Anyway I solved the problem another way which made this patch less urgent. I will get back to it eventually.

The RA is now working and has been running in a JBoss instance for some months now wo problem.