Issues with messaging sample

[nivek83]

I am having trouble getting the built-in "dashboard" sample
app to work with JMS. It works fine with Flex messaging, but for
some reason, it seems like it can't stay subscribed to a topic when
I use JMS.



I am using WebSphere v6 with TibcoEMS v4.3 as the JMS
provider.



I know I have the destinations configured correctly, because
when I send a message over the chat, I can see the number of
pending messages in the topic increasing. I can publish to a topic,
but cannot subscribe. After turning on the EMS trace, here's what
it produces when I start up the dashboard application:



[10/23/06 17:51:19:030 EDT] 0000007d SystemErr R 2006-10-23
17:51:19 [564303409 WorkManager.DefaultWorkManager : 18] [TIBCO
EMS]: createSubscriber tsub=1871 tsess=214
topic=Topic[EMST.SS.FLEX_DASHBOARD_CHAT]

[10/23/06 17:51:19:030 EDT] 0000007d SystemErr R 2006-10-23
17:51:19 [564303409 WorkManager.DefaultWorkManager : 18] [TIBCO
EMS]: start conn=224

[10/23/06 17:51:19:030 EDT] 00000064 SystemErr R 2006-10-23
17:51:19 [1867667001 Thread-74] [TIBCO EMS]: before receiveNoWait
cons=1871 sess=214

[10/23/06 17:51:19:030 EDT] 00000064 SystemErr R 2006-10-23
17:51:19 [1867667001 Thread-74] [TIBCO EMS]: after receiveNoWait
cons=1871 sess=214 msg=null



...repeats last 2 lines 6 more times



[10/23/06 17:51:19:733 EDT] 0000007d SystemErr R 2006-10-23
17:51:19 [564303409 WorkManager.DefaultWorkManager : 18] [TIBCO
EMS]: createTopicConnection tconn=227
tconfac=TopicConnectionFactory[URL=tcp://adal54:10222;clientID=null]
user=flex

[10/23/06 17:51:19:733 EDT] 0000007d SystemErr R 2006-10-23
17:51:19 [564303409 WorkManager.DefaultWorkManager : 18] [TIBCO
EMS]: setExceptionListener conn=227 lsnr=non-null

[10/23/06 17:51:19:780 EDT] 0000007d SystemErr R 2006-10-23
17:51:19 [564303409 WorkManager.DefaultWorkManager : 18] [TIBCO
EMS]: createTopicSession tsess=217 tconn=227 tran=false ackmode=1

[10/23/06 17:51:19:795 EDT] 00000064 SystemErr R 2006-10-23
17:51:19 [1867667001 Thread-74] [TIBCO EMS]: before receiveNoWait
cons=1871 sess=214

[10/23/06 17:51:19:795 EDT] 00000064 SystemErr R 2006-10-23
17:51:19 [1867667001 Thread-74] [TIBCO EMS]: after receiveNoWait
cons=1871 sess=214 msg=null

[10/23/06 17:51:19:842 EDT] 0000007d SystemErr R 2006-10-23
17:51:19 [564303409 WorkManager.DefaultWorkManager : 18] [TIBCO
EMS]: createSubscriber tsub=1873 tsess=217
topic=Topic[EMST.SS.FLEX_DASHBOARD_FEED]

[10/23/06 17:51:19:842 EDT] 0000007d SystemErr R 2006-10-23
17:51:19 [564303409 WorkManager.DefaultWorkManager : 18] [TIBCO
EMS]: start conn=227

[10/23/06 17:51:19:842 EDT] 00000064 SystemErr R 2006-10-23
17:51:19 [1867667001 Thread-74] [TIBCO EMS]: before receiveNoWait
cons=1873 sess=217

[10/23/06 17:51:19:842 EDT] 00000064 SystemErr R 2006-10-23
17:51:19 [1867667001 Thread-74] [TIBCO EMS]: after receiveNoWait
cons=1873 sess=217 msg=null

[10/23/06 17:51:19:889 EDT] 0000007d SystemErr R 2006-10-23
17:51:19 [564303409 WorkManager.DefaultWorkManager : 18] [TIBCO
EMS]: close cons=1871 sess=214

[10/23/06 17:51:19:889 EDT] 0000007d SystemErr R 2006-10-23
17:51:19 [564303409 WorkManager.DefaultWorkManager : 18] [TIBCO
EMS]: close cons=1873 sess=217

[10/23/06 17:51:19:904 EDT] 0000007d SystemErr R 2006-10-23
17:51:19 [564303409 WorkManager.DefaultWorkManager : 18] [TIBCO
EMS]: stop conn=227

[10/23/06 17:51:19:967 EDT] 0000007d SystemErr R 2006-10-23
17:51:19 [564303409 WorkManager.DefaultWorkManager : 18] [TIBCO
EMS]: stop conn=224



It looks like it's starting up, creating the subscriber
connection, and then once it doesn't find something to read, Flex
is closing the connection so that it can't read any new messages.
Has anyone run into anything similar in the past? Any suggestions
on how to troubleshoot this further?



Thanks,

Kevin

[aglosband]

What happens if you have a java client subscribed to the
topic? When you send the message from Flex does the java client get
the message? That might be something to try. In the meantime I'll
ask if those errors look familiar to anyone here.

[nivek83]

Thanks for the quick response.



I confirmed that a simple Java client can receive a message
sent from the Flex dashboard chat without a problem, so this is
definitely looking like a Flex issue.



Were you able to replicate this?



Thanks,

Kevin

[aglosband]

Hi Kevin,

I haven't tried to replicate this yet as we don't have a
system with WebSphere 6 and Tibco configured currently. I'm going
to go ahead and get one set up but in the meantime could you try
two things for me?



1. Can you try adding -Dtrace.rtmp and -Dtrace.message to the
jvm arguments before starting the server. Hopefully if there is an
exception that is causing the RTMP connection to close this will
show it to us.



2. Can you try changing the messaging destination to use the
AMF polling channel instead of the RTMP channel (this may actually
help you get around the problem for the time being). In the
WEB-INF\flex\messaging-config.xml, just change the channels
definition to the following and restart the server.



<channels>

<channel ref="my-polling-amf"/>

</channels>



We have had problems with the RTMP channel not working on
some platforms so this will help us determine if it's an RTMP issue
or not. Thanks.

[nivek83]

I tried #1, and received the following error:



javax.jms.IllegalStateException: Method setMessageListener
not permitted



I believe the explanation for this is in this article:




http://www-1.ibm.com/support/docview.wss?uid=swg21114239



Unfortunately, I don't have the full log trace for you
because I deleted it in trying to troubleshoot issues with the
second suggestion.



I tried to test out the polling-amf solution, but since
making that change, I have been unable to get anything to work,
whether I use polling amf or go back to rtmp. The error I'm getting
now is:



[11/1/06 10:09:24:408 EST] 00000048 SystemOut O [Flex]
[DEBUG] Error handling rtmp message:
flex.messaging.MessageException: Context:
MER2CONDA711373Node01Cell/nodes/MER2CONDA711373Node01/servers/server1,
name:

jms/TopicConnectionFactory

: First component in name

jms/TopicConnectionFactory

not found.



This doesn't make any sense, as I'm able to connect to the
TCF and the associated topics using the same plain JMS test program
I used to troubleshoot this earlier. This program is running under
the same server, and is actually part of the same WAR file, so I
really don't understand how my test program can do the JNDI lookup,
but Flex cannot. I am at a complete loss as to how to further
troubleshoot this.



I realize this is a completely different issue than what I
first posted about, but it started happening when I was trying your
two suggestions above. The *only* changes I made were to add the
two JVM args that you suggested, and to change the channel Flex is
trying to connect to. Even after reversing those two changes, I am
still getting these JMS errors.



Have you got any idea why this is happening?



Thanks,

Kevin

[CathyM]

We've installed WebSphere with Tibco and are unfortnately, we
see connections closing as well but haven't been able to pinpoint
the issue.



This leaves two options for running the samples with JMS -
either use the polling-amf channel (after resolving your issues) or
using the default JMS provider that somes with WebSphere.



> javax.jms.IllegalStateException: Method
setMessageListener not permitted



This isn't anything to worry about. This is something we
would expect to see with the additional debug output. On WebSphere,
when we encounter this exception we default to polling for JMS
messages via receiveNoWait, which you've seen in your previous
traces.



> tried to test out the polling-amf solution

> so I really don't understand how my test program can do
the JNDI lookup



In your test programming, what properties did you pass into
your initial context and how did you create the initial context?
And, when you did the TopicConnectionFactory and the Topic jndi
lookup, what did the code look like?



What does your destination configuration in
samples/WEB-INF/flex/messaging-config.xml look like?



The shipping sample contains -

<connection-factory>jms/flex/TopicConnectionFactory</connection-factory>


<destination-jndi-name>jms/topic/flex/dashboard_chat</destination-jndi-name>



From the errors, it looks like you may be using
jms/TopicConnectionFactory.



Also note that you'll need to use the name for the
TopicConnectionFactory as exposed through JNDI, in some cases, this
requires that resource-refs/resource-env-refs be resolved during
web app deployment. In some cases, you may only access JMS
resources if you've exposed the resources through the J2EE
deployment files.



If you're exposed your JMS resources through the
resource-env-refs then in many cases you'll access using -



java:comp/env/jms/flex/TopicConnectionFactory

java:comp/env/jms/flex/dashboard_chat

[nivek83]

I found the issue with the JNDI lookup. Apparently, when I
made the change to messaging-config.xml to test the polling-amf
solution, I did a Ctrl+Shift+F in Rational Application Developer,
which formatted the xml file, and changed:




<connection-factory>jms/TopicConnectionFactory</connection-factory>


<destination-jndi-name>jms/topic/flex/DashboardFeed</destination-jndi-name>



to:



<connection-factory>

jms/TopicConnectionFactory

</connection-factory>

<destination-jndi-name>

jms/topic/flex/DashboardFeed

</destination-jndi-name>



Seems there's a bug in the parser for the FDS config file
that can't handle white space between the tag and the value.



Anyways, now that that's out of the way, I was able to test
out the polling-amf solution, and I got the same results.



I don't know if this is actually helpful to you at all now
that you have your own test setup, but here's the exception I'm
getting now with the polling-amf solution. The first one is this,
which you said not to worry about.





[11/1/06 17:59:18:322 EST] 0000002c JMSMessageCon 1 Method
getMessageListener not permitted

javax.jms.IllegalStateException: Method getMessageListener
not permitted

at
com.ibm.ejs.jms.JMSCMUtils.methodNotPermittedException(JMSCMUtils.java:204)

at
com.ibm.ejs.jms.JMSMessageConsumerHandle.getMessageListener(JMSMessageConsumerHandle.java:358)

at
flex.messaging.services.messaging.adapters.JMSConsumer.receiverAdapter(JMSConsumer.java:161)

at
flex.messaging.services.messaging.adapters.JMSConsumer.asyncReceive(JMSConsumer.java:86)

at
flex.messaging.services.messaging.adapters.JMSAdapter.manage(JMSAdapter.java:368)

at
flex.messaging.services.MessageService.manageSubscriptions(MessageService.java:571)

at
flex.messaging.services.MessageService.serviceCommand(MessageService.java:152)

at
flex.messaging.MessageBroker.routeCommandToService(MessageBroker.java:622)

at
flex.messaging.endpoints.AbstractEndpoint.serviceMessage(AbstractEndpoint.java:298)

at
flex.messaging.endpoints.amf.MessageBrokerFilter.invoke(MessageBrokerFilter.java:93)

at
flex.messaging.endpoints.amf.LegacyFilter.invoke(LegacyFilter.java:156)

at
flex.messaging.endpoints.amf.SessionFilter.invoke(SessionFilter.java:46)

at
flex.messaging.endpoints.amf.BatchProcessFilter.invoke(BatchProcessFilter.java:67)

at
flex.messaging.endpoints.amf.SerializationFilter.invoke(SerializationFilter.java:130)

at
flex.messaging.endpoints.AMFEndpoint.service(AMFEndpoint.java:164)

at
flex.messaging.MessageBrokerServlet.service(MessageBrokerServlet.java:340)

at
javax.servlet.http.HttpServlet.service(HttpServlet.java:856)

at
com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:1212)

at
com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:629)

at
com.ibm.ws.webcontainer.servlet.CacheServletWrapper.handleRequest(CacheServletWrapper.java:80)

at
com.ibm.ws.webcontainer.WebContainer.handleRequest(WebContainer.java:1657)

at
com.ibm.ws.webcontainer.channel.WCChannelLink.ready(WCChannelLink.java:77)

at
com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleDiscrimination(HttpInboundLink.java:421)

at
com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleNewInformation(HttpInboundLink.java:367)

at
com.ibm.ws.http.channel.inbound.impl.HttpICLReadCallback.complete(HttpICLReadCallback.java:94)

at
com.ibm.ws.tcp.channel.impl.WorkQueueManager.requestComplete(WorkQueueManager.java:548)

at
com.ibm.ws.tcp.channel.impl.WorkQueueManager.attemptIO(WorkQueueManager.java:601)

at
com.ibm.ws.tcp.channel.impl.WorkQueueManager.workerRun(WorkQueueManager.java:934)

at
com.ibm.ws.tcp.channel.impl.WorkQueueManager$Worker.run(WorkQueueManager.java:1021)

at
com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1332)





Then, I receive thousands of these exceptions, presumably
because they're being thrown every time Flex polls:





[11/1/06 17:59:18:541 EST] 0000003f JMSMessageCon 1 Caught
JMSException in receiveNoWait

javax.jms.IllegalStateException: Consumer closed

at
com.ibm.ejs.jms.JMSMessageConsumerHandle.checkOpen(JMSMessageConsumerHandle.java:747)

at
com.ibm.ejs.jms.JMSTopicSubscriberHandle.getOpenTopicSubscriber(JMSTopicSubscriberHandle.java:543)

at
com.ibm.ejs.jms.JMSTopicSubscriberHandle.getOpenMessageConsumer(JMSTopicSubscriberHandle.java:529)

at
com.ibm.ejs.jms.JMSMessageConsumerHandle.receiveNoWait(JMSMessageConsumerHandle.java:566)

at
flex.messaging.services.messaging.adapters.JMSConsumer.receiveNoWait(JMSConsumer.java:126)

at
flex.messaging.services.messaging.adapters.PollingMessageReceiver.run(PollingMessageReceiver.java:68)

at java.util.TimerThread.mainLoop(Timer.java:447)

at java.util.TimerThread.run(Timer.java:397)





There's a lot more info in the trace file than that. If you
give me an email address or an ftp location, I can send you the
whole file.



So, right now, I am working under the assumption that Flex
will not work with Websphere 6 and Tibco EMS. Is this something
that we can expect to be fixed in the near future, or something
that won't likely be fixed until the next major release, if it's
fixed at all?



Thanks,

Kevin

[seth_hodgson]

Hi Kevin,



Alex has reproduced this internally with Tibco EMS and we
have a bug logged. Thanks for raising this issue. The root problem
is that various vendors are more or less strict about which JMS
APIs they allow to be invoked from within a web container. For the
time being you'll need to try using a different JMS provider.



Sorry for the hassle,

Seth