[JBoss Seam] - Re: Bug in explicit conversation id management in SEAM 1.2.1
by raffaele.camanzo
anonymous wrote :
| You have defined this page to use a natural conversation id, and then you try to use other strategies *on the same page*??
|
Definitely no. Three Seam components, three pages, three navigation rules, to avoid any misunderstanding I created three separate projects too and made the tests again.
One project defines the conversation id in a natural way, another one defines it in the old fashion and the third one gets a generated conversation id.
The three projects have the same behaviour:
One link from the main page to the @Begin action of the conversation, from that link I move through the navigation rules in another page, the one related to that conversation.
This is the target page:
| <!DOCTYPE composition PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
| <ui:composition xmlns="http://www.w3.org/1999/xhtml"
| xmlns:ui="http://java.sun.com/jsf/facelets"
| xmlns:h="http://java.sun.com/jsf/html"
| xmlns:f="http://java.sun.com/jsf/core"
| xmlns:s="http://jboss.com/products/seam/taglib"
| xmlns:c="http://java.sun.com/jstl/core"
| template="template.xhtml">
|
| <!-- context manager -->
| <ui:define name="actioncontent">
| <h:dataTable value="#{actionTwo.starttimes}" var="iter">
| <h:column>
| <h:outputText value="#{iter}" />
| </h:column>
| </h:dataTable>
|
| <h:form>
| <s:link action="#{actionTwo.doIt}">
| <h:outputText value="Press me I should run into #{conversation.id} conversation" />
| </s:link>
| </h:form>
| </ui:define>
|
| </ui:composition>
|
The s:link refers to an action of the Seam component actionTwo, such action simply adds a string to a list, I guess I'm in a LRC, the @Begin method of the actionTwo component returned the outcome of this page, the s:link propagate the conversation, then I expect that Seam holds the component (saved in the conversation context) in the current conversation, but this does not happen in the two test cases with explicit conversation id.
In the Seam-assigned conversation id test everything works properly.
I can post you both the test cases and a more detailed description, anyway, I don't think you need server logs of Seam.
Can you please answer to these two questions?
anonymous wrote :
| - Can I expect that if I click twice on a link connected to the start conversation of an explicit id conversation Seam will understand that I'm asking for that conversation and resumes it?
| - Is it legal to use the Redirect API knowing the conversation id (regardless generated or explicit) in order to resume a conversation?
|
| Both the questions without a LRC in place (s:conversationPropagation type="none")
|
Actually my application does not work with Seam 1.2.1, I'd like to move to a natural conversation id compliant usage and I want to avoid any misunderstanding of the framework.
Regards,
Raffaele Camanzo
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4033149#4033149
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4033149
17Â years, 9Â months
[JBoss Messaging] - Re: Failed to get a server session
by imaeses
We solved this problem. Turns out it has nothing to do with JBoss Messaging and everything to do with our code. I'm relating our experiences here in case anyone else encounters a similar problem.
Queue clients are not only a JBoss server hosting MDB's listening to those queues, but also freestanding programs. Because there is a fair number of these freestanding programs, they each cache a QueueConnection. These programs are multithreaded. In short, there was a race condition in our code which caused the QueueConnection.close() to hang. After this occurred enough times, the JBoss session pool ran out of sessions. We observed other strange behavior as well, including the fact that we could not undeploy applications from JBoss listening in on queue's affected by this problem. Our initial approach was to interrupt() one of the deadlocked threads, drop the reference, and create a new one with a fresh QueueConnection. However, onMessage() was called immediately once again, before the deadlock condition could resolve itself. A side-effect of this nonsense was that the JVM filled up with orphaned threads all waiting on QueueConnection.close(). Eventually we had OutOfMemoryE!
rrors.
The race condition never occurred in JBossMQ because it seems that the thread which calls onMessage() in a MessageListener was the same thread as calls onException() in an ExceptionListener. In JBoss Messaging, it appears these are different threads. Our problem was that an onException() called while onMessage() was being processed caused a deadlock under a particular, application-specific condition. After this, QueueConnection.close() would wait for onMessage() to complete, which was forever.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4033144#4033144
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4033144
17Â years, 9Â months
[JBossCache] - Class not found JBossObjectStreamFactory$JBossObjectInputStr
by ben_ben
Hi,
I've implemented a clustered cache on JBoss and, using one machine in isolation, everything seems fine. However, as soon as I cluster and a rollback takes place I get the following exception...
Caused by: java.lang.NoClassDefFoundError: org/jboss/cache/marshall/JBossObjectStreamFactory$JBossObjectInputStreamOverride
| at java.lang.Class.forName0(Native Method)
| at java.lang.Class.forName(Class.java:164)
| at org.jboss.cache.marshall.ObjectSerializationFactory.<clinit>(ObjectSerializationFactory.java:39)
| at org.jboss.cache.marshall.VersionAwareMarshaller.objectToByteBuffer(VersionAwareMarshaller.java:128)
| at org.jgroups.blocks.RpcDispatcher.callRemoteMethods(RpcDispatcher.java:181)
| at org.jgroups.blocks.RpcDispatcher.callRemoteMethods(RpcDispatcher.java:163)
| at org.jboss.cache.TreeCache.callRemoteMethodsViaReflection(TreeCache.java:4404)
| at org.jboss.cache.TreeCache.callRemoteMethods(TreeCache.java:4358)
| at org.jboss.cache.TreeCache.callRemoteMethods(TreeCache.java:4311)
| at org.jboss.cache.TreeCache.callRemoteMethods(TreeCache.java:4422)
| at org.jboss.cache.interceptors.BaseRpcInterceptor.replicateCall(BaseRpcInterceptor.java:110)
| at org.jboss.cache.interceptors.BaseRpcInterceptor.replicateCall(BaseRpcInterceptor.java:88)
| at org.jboss.cache.interceptors.ReplicationInterceptor.runPreparePhase(ReplicationInterceptor.java:152)
| at org.jboss.cache.interceptors.ReplicationInterceptor.invoke(ReplicationInterceptor.java:69)
| at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
| at org.jboss.cache.interceptors.TxInterceptor.runPreparePhase(TxInterceptor.java:861)
| at org.jboss.cache.interceptors.TxInterceptor$LocalSynchronizationHandler.beforeCompletion(TxInterceptor.java:1126)
| ... 10 more
Has anyone got any ideas why it can find the rest of the jboss cache classes but not this one?
Thanks
Ben
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4033139#4033139
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4033139
17Â years, 9Â months