XFire

Client does not work with JMS in 1.2.5

Details

  • Type: Sub-task Sub-task
  • Status: Open Open
  • Priority: Critical Critical
  • Resolution: Unresolved
  • Affects Version/s: 1.2.5
  • Fix Version/s: None
  • Component/s: None
  • Labels:
    None
  • Number of attachments :
    0

Description

The fix of XFIRE-270 breaks the use of the Client with asynchrone channels. A nullpointer is throw when recieving a reply.
When using an asynchrone channel a new messageContext is created and the client is not set on the messageContext because at that moment the client is not know yet.
It is only after the CorrolatorHandler that the client is known. (Warning: at the moment the CorrolatorHandler does not copy the client from old to new context)

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Tom Lambrechts added a comment -

It's about the code change on line 399:

//the Client object in the context is not necessary "this" (client.onReceive())
// we need to invoke the handlers from the client in the context not "this"
// was creating issues when used in multi-threaded
Client contextClient = context.getClient();
Regards,
T.

Show
Tom Lambrechts added a comment - It's about the code change on line 399: //the Client object in the context is not necessary "this" (client.onReceive()) // we need to invoke the handlers from the client in the context not "this" // was creating issues when used in multi-threaded Client contextClient = context.getClient(); Regards, T.
Hide
Permalink
Walter Seymore added a comment -

I came across the same NPE and just used "this" instance's XFire instead and I couldn't get it to break with an http transport (The JMS transport fails as the timeout is too short when firing tens of messages in multiple threads). What is the purpose of using context.getClient()?

Show
Walter Seymore added a comment - I came across the same NPE and just used "this" instance's XFire instead and I couldn't get it to break with an http transport (The JMS transport fails as the timeout is too short when firing tens of messages in multiple threads). What is the purpose of using context.getClient()?
Hide
Permalink
Walter Seymore added a comment -

I fixed this by replacing the line:

Client contextClient = context.getClient();

with

Client contextClient = correlator.correlate(context, invocations).getContext().getClient();

in Client. This does not seem to do any harm, but it works just as well for me if I use

Client contextClient = this;

but since it must have been changed for a reason, I guess the first option is the better one.

Could somebody please review this and make it (or a better fix) available in the next release since the JMS transport does not work at all without it.

Thanks
Walter

Show
Walter Seymore added a comment - I fixed this by replacing the line: Client contextClient = context.getClient(); with Client contextClient = correlator.correlate(context, invocations).getContext().getClient(); in Client. This does not seem to do any harm, but it works just as well for me if I use Client contextClient = this; but since it must have been changed for a reason, I guess the first option is the better one. Could somebody please review this and make it (or a better fix) available in the next release since the JMS transport does not work at all without it. Thanks Walter
Hide
Permalink
Christian Schneider added a comment -

I also experience the problem when using the JMS Channel. Can this be fixed in 1.2.7?

Show
Christian Schneider added a comment - I also experience the problem when using the JMS Channel. Can this be fixed in 1.2.7?
Hide
Permalink
Christian Schneider added a comment -

BTW. the problem also happens in 1.2.6 not only 1.2.5

Show
Christian Schneider added a comment - BTW. the problem also happens in 1.2.6 not only 1.2.5

People

  • Assignee:
    Dan Diephouse
    Reporter:
    Tom Lambrechts
Vote (2)
Watch (2)

Dates

  • Created:
    Updated: