Re: Undocumented stomp header?
Ok, that clears it up. Thnx! On 12/19/06, Brian McCallister <[EMAIL PROTECTED]> wrote: On Dec 17, 2006, at 9:58 AM, Nathan Mittler wrote: > Hey guys, > I was just looking at the stomp transport and noticed what appears > to be an > undocumented extension to stomp adding a header for subscription ID > (literally the string "id" on the wire) to the subscribe and > unsubscribe > frames. I have just a few questions: Yep, this is the subscription id in activemq. It is added, as well, it might be useful :-) > 1) Is this equivalent to a consumer id? ... meaning that the client > application can use this value to subscribe multiple times to the same > destination through the same connection? I cannot think of any way to accomplish this in the stomp connector, but in theory, yes. > 2) Is there any reason that not providing this header might cause the > 4.1broker to throw an exception on an unsubscribe, but not > 4.0.2? It shouldn't even be used, actually. > 3) Is this header documented anywhere? I did not see it here > http://www.activemq.org/site/stomp.html or here > http://stomp.codehaus.org/Protocol Nope, is there for informational purposes if you are looking at JMX, basically. -Brian
[jira] Resolved: (SM-782) Re-deploy with In-Only Mep
[ https://issues.apache.org/activemq/browse/SM-782?page=all ]
Guillaume Nodet resolved SM-782.
Fix Version/s: 3.1
Resolution: Fixed
Assignee: Guillaume Nodet
Author: gnodet
Date: Tue Dec 19 15:17:57 2006
New Revision: 488850
URL: http://svn.apache.org/viewvc?view=rev&rev=488850
Log:
SM-782: jms component should be stateless when sending InOnly exchanges. Patch
provided by Gregoire A
Modified:
incubator/servicemix/trunk/deployables/bindingcomponents/servicemix-jms/src/main/java/org/apache/servicemix/jms/multiplexing/MultiplexingConsumerProcessor.java
> Re-deploy with In-Only Mep
> --
>
> Key: SM-782
> URL: https://issues.apache.org/activemq/browse/SM-782
> Project: ServiceMix
> Issue Type: Bug
> Components: servicemix-jms
>Affects Versions: 3.1
> Environment: Linux x86/ Java (1.5.0_09)
>Reporter: Grégoire A.
> Assigned To: Guillaume Nodet
> Fix For: 3.1
>
> Attachments: MultiplexingConsumerProcessor.java.2.diff,
> MultiplexingConsumerProcessor.java.3.diff,
> MultiplexingConsumerProcessor.java.diff
>
>
> First deploy JMS-endpoint with target InOnly Service like Mail.
> Run several call.
> redeploy the same JMS-endpoint without modification.
> And recall the service, u should have this exception.
> It could be a safe thread pb, this error is launched in 75% of the cases.
> I think the context of the message cannot be refind.
> ERROR - JmsComponent - Error
> processing exchange InOnly[
> id: ID:jjp-34393-1166462101789-6:229
> status: Done
> role: consumer
> service: {urn:fr.gouv.hello}mailSender
> endpoint: mailSender
> in: encoding="UTF-8"?> xmlns:ns1="http://tempuri.org/HashService/HashClass";
> xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/";
> xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/";
> xmlns:ZSI="http://www.zolera.com/schemas/ZSI/";
> xmlns:xsd="http://www.w3.org/2001/XMLSchema";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>Message
> Change dans BPEL 4 JMS Service
> MD5
> ]
> java.lang.NullPointerException
> at
> org.apache.servicemix.jms.multiplexing.MultiplexingConsumerProcessor.process(MultiplexingConsumerProcessor.java:105)
> at
> org.apache.servicemix.common.AsyncBaseLifeCycle.doProcess(AsyncBaseLifeCycle.java:490)
> at
> org.apache.servicemix.common.AsyncBaseLifeCycle.processExchange(AsyncBaseLifeCycle.java:464)
> at
> org.apache.servicemix.common.BaseLifeCycle.onMessageExchange(BaseLifeCycle.java:46)
> at
> org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.processInBound(DeliveryChannelImpl.java:610)
> at
> org.apache.servicemix.jbi.nmr.flow.AbstractFlow.doRouting(AbstractFlow.java:174)
> at
> org.apache.servicemix.jbi.nmr.flow.seda.SedaFlow.doRouting(SedaFlow.java:176)
> at
> org.apache.servicemix.jbi.nmr.flow.seda.SedaQueue$1.run(SedaQueue.java:134)
> at
> edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:665)
> at
> edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:690)
> at java.lang.Thread.run(Thread.java:595)
> ERROR - JmsComponent - Error setting
> exchange status to ERROR
> javax.jbi.messaging.MessagingException: illegal call
> to send / sendSync
> at
> org.apache.servicemix.jbi.messaging.MessageExchangeImpl.handleSend(MessageExchangeImpl.java:571)
> at
> org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.doSend(DeliveryChannelImpl.java:350)
> at
> org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.send(DeliveryChannelImpl.java:397)
> at
> org.apache.servicemix.common.BaseLifeCycle.onMessageExchange(BaseLifeCycle.java:58)
> at
> org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.processInBound(DeliveryChannelImpl.java:610)
> at
> org.apache.servicemix.jbi.nmr.flow.AbstractFlow.doRouting(AbstractFlow.java:174)
> at
> org.apache.servicemix.jbi.nmr.flow.seda.SedaFlow.doRouting(SedaFlow.java:176)
> at
> org.apache.servicemix.jbi.nmr.flow.seda.SedaQueue$1.run(SedaQueue.java:134)
> at
> edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:665)
> at
> edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:690)
> at java.lang.Thread.run(Thread.java:595)
> and this is my configuration
> endpoint="HELLOJmsReceiver"
> targetService="hello:mailSender"
> role="consumer"
> destinationStyle="queue"
> jmsProviderDestinationName="jms/queue/hello"
> connectionFactory="#jmsFactory"
> defaultMep="http://www.w3.org/2004/08/wsdl/in-only"; />
> FYI: wh
[jira] Commented: (SM-782) Re-deploy with In-Only Mep
[
https://issues.apache.org/activemq/browse/SM-782?page=comments#action_37734 ]
Guillaume Nodet commented on SM-782:
I think your modifications on the pendingExchanges map have no effect at all.
Anyway, I will commit these changes as the code is cleaner that way.
JMS objects are not closed in this processor, as it has been designed to use
with ActiveMQ which supports these reuse. However this code has some design
problems and I will soon commit a new JMS consumer endpoint which should
be more standard and more powerful at the same time.
> Re-deploy with In-Only Mep
> --
>
> Key: SM-782
> URL: https://issues.apache.org/activemq/browse/SM-782
> Project: ServiceMix
> Issue Type: Bug
> Components: servicemix-jms
>Affects Versions: 3.1
> Environment: Linux x86/ Java (1.5.0_09)
>Reporter: Grégoire A.
> Attachments: MultiplexingConsumerProcessor.java.2.diff,
> MultiplexingConsumerProcessor.java.3.diff,
> MultiplexingConsumerProcessor.java.diff
>
>
> First deploy JMS-endpoint with target InOnly Service like Mail.
> Run several call.
> redeploy the same JMS-endpoint without modification.
> And recall the service, u should have this exception.
> It could be a safe thread pb, this error is launched in 75% of the cases.
> I think the context of the message cannot be refind.
> ERROR - JmsComponent - Error
> processing exchange InOnly[
> id: ID:jjp-34393-1166462101789-6:229
> status: Done
> role: consumer
> service: {urn:fr.gouv.hello}mailSender
> endpoint: mailSender
> in: encoding="UTF-8"?> xmlns:ns1="http://tempuri.org/HashService/HashClass";
> xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/";
> xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/";
> xmlns:ZSI="http://www.zolera.com/schemas/ZSI/";
> xmlns:xsd="http://www.w3.org/2001/XMLSchema";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>Message
> Change dans BPEL 4 JMS Service
> MD5
> ]
> java.lang.NullPointerException
> at
> org.apache.servicemix.jms.multiplexing.MultiplexingConsumerProcessor.process(MultiplexingConsumerProcessor.java:105)
> at
> org.apache.servicemix.common.AsyncBaseLifeCycle.doProcess(AsyncBaseLifeCycle.java:490)
> at
> org.apache.servicemix.common.AsyncBaseLifeCycle.processExchange(AsyncBaseLifeCycle.java:464)
> at
> org.apache.servicemix.common.BaseLifeCycle.onMessageExchange(BaseLifeCycle.java:46)
> at
> org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.processInBound(DeliveryChannelImpl.java:610)
> at
> org.apache.servicemix.jbi.nmr.flow.AbstractFlow.doRouting(AbstractFlow.java:174)
> at
> org.apache.servicemix.jbi.nmr.flow.seda.SedaFlow.doRouting(SedaFlow.java:176)
> at
> org.apache.servicemix.jbi.nmr.flow.seda.SedaQueue$1.run(SedaQueue.java:134)
> at
> edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:665)
> at
> edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:690)
> at java.lang.Thread.run(Thread.java:595)
> ERROR - JmsComponent - Error setting
> exchange status to ERROR
> javax.jbi.messaging.MessagingException: illegal call
> to send / sendSync
> at
> org.apache.servicemix.jbi.messaging.MessageExchangeImpl.handleSend(MessageExchangeImpl.java:571)
> at
> org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.doSend(DeliveryChannelImpl.java:350)
> at
> org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.send(DeliveryChannelImpl.java:397)
> at
> org.apache.servicemix.common.BaseLifeCycle.onMessageExchange(BaseLifeCycle.java:58)
> at
> org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.processInBound(DeliveryChannelImpl.java:610)
> at
> org.apache.servicemix.jbi.nmr.flow.AbstractFlow.doRouting(AbstractFlow.java:174)
> at
> org.apache.servicemix.jbi.nmr.flow.seda.SedaFlow.doRouting(SedaFlow.java:176)
> at
> org.apache.servicemix.jbi.nmr.flow.seda.SedaQueue$1.run(SedaQueue.java:134)
> at
> edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:665)
> at
> edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:690)
> at java.lang.Thread.run(Thread.java:595)
> and this is my configuration
> endpoint="HELLOJmsReceiver"
> targetService="hello:mailSender"
> role="consumer"
> destinationStyle="queue"
> jmsProviderDestinationName="jms/queue/hello"
> connectionFactory="#jmsFactory"
> defaultMep="http://www.w3.org/2004/08/wsdl/in-only"; />
> FYI: when you block SMX with in a debugger, it seems to
> work fine.
--
This message is automati
Re: [VOTE] 2.0-M1 Release
+1 chris Matt Hogstrom wrote: All, I have prepared 2.0-M1 for release. Of course all the hard work was done by the lot of y'all :) I have tested DayTrader 2.0-SNAPSHOT on this build and I'm satisfied with the results. All modes of operation functioned well (SLSB, Direct, EJB and JPA). I toned all the logs down to error to not overwhelm the users with lots of diagnostic output (they can always turn it up later if they want.) The uploads are taking forever so you'll see some piece parts trickle in. For the review I expect you'll want to focus on http://people.apache.org/~hogstrom/2.0-M1 as this contains the assemblies for your review and testing. I've included both Tomcat and Jetty as well as the minimal and j5ee assemblies. The source code is also there. Note that if you are planning on building you'll need to obtain the openejb-2.2-incubating jars to your local repo. The easiest way to do this is to modify the root pom and add a repository for David's home directory at http://people.apache.org/~dblevins/stage/. For SNAPSHOTs of certain plugins I have resolved these files to the most recent SNAPSHOT date / timestamp. I'm pulling a copy of these and will be putting them into our SVN for folks who may want to build in the future. I'm not too concerned about repeatability as this Milestone will be superseded at the end of January with the next version. The other MAven artifacts will be trickling onto people across my horribly slow home pipe and dropped into http://people.apache.org/~hogstrom/stage over the next few hours. Please review and cast your vote early. The faster we determine this build is good or if there is an issue the better. Thanks in advance for all your help in this effort. This vote will conclude at 0400 ET on Dec 21 (unless all you PMC members vote quicker :) If a respin is is necessary this vote will be suspended and a new one will start. Matt Hogstrom [EMAIL PROTECTED]
[jira] Updated: (SM-782) Re-deploy with In-Only Mep
[ https://issues.apache.org/activemq/browse/SM-782?page=all ]
Grégoire A. updated SM-782:
---
Attachment: MultiplexingConsumerProcessor.java.3.diff
Now, the Context is remove.
I normalized the attribute initialisation in onStart method.
It could be safer to close correctly jms objects (eg: session.close()).
> Re-deploy with In-Only Mep
> --
>
> Key: SM-782
> URL: https://issues.apache.org/activemq/browse/SM-782
> Project: ServiceMix
> Issue Type: Bug
> Components: servicemix-jms
>Affects Versions: 3.1
> Environment: Linux x86/ Java (1.5.0_09)
>Reporter: Grégoire A.
> Attachments: MultiplexingConsumerProcessor.java.2.diff,
> MultiplexingConsumerProcessor.java.3.diff,
> MultiplexingConsumerProcessor.java.diff
>
>
> First deploy JMS-endpoint with target InOnly Service like Mail.
> Run several call.
> redeploy the same JMS-endpoint without modification.
> And recall the service, u should have this exception.
> It could be a safe thread pb, this error is launched in 75% of the cases.
> I think the context of the message cannot be refind.
> ERROR - JmsComponent - Error
> processing exchange InOnly[
> id: ID:jjp-34393-1166462101789-6:229
> status: Done
> role: consumer
> service: {urn:fr.gouv.hello}mailSender
> endpoint: mailSender
> in: encoding="UTF-8"?> xmlns:ns1="http://tempuri.org/HashService/HashClass";
> xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/";
> xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/";
> xmlns:ZSI="http://www.zolera.com/schemas/ZSI/";
> xmlns:xsd="http://www.w3.org/2001/XMLSchema";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>Message
> Change dans BPEL 4 JMS Service
> MD5
> ]
> java.lang.NullPointerException
> at
> org.apache.servicemix.jms.multiplexing.MultiplexingConsumerProcessor.process(MultiplexingConsumerProcessor.java:105)
> at
> org.apache.servicemix.common.AsyncBaseLifeCycle.doProcess(AsyncBaseLifeCycle.java:490)
> at
> org.apache.servicemix.common.AsyncBaseLifeCycle.processExchange(AsyncBaseLifeCycle.java:464)
> at
> org.apache.servicemix.common.BaseLifeCycle.onMessageExchange(BaseLifeCycle.java:46)
> at
> org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.processInBound(DeliveryChannelImpl.java:610)
> at
> org.apache.servicemix.jbi.nmr.flow.AbstractFlow.doRouting(AbstractFlow.java:174)
> at
> org.apache.servicemix.jbi.nmr.flow.seda.SedaFlow.doRouting(SedaFlow.java:176)
> at
> org.apache.servicemix.jbi.nmr.flow.seda.SedaQueue$1.run(SedaQueue.java:134)
> at
> edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:665)
> at
> edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:690)
> at java.lang.Thread.run(Thread.java:595)
> ERROR - JmsComponent - Error setting
> exchange status to ERROR
> javax.jbi.messaging.MessagingException: illegal call
> to send / sendSync
> at
> org.apache.servicemix.jbi.messaging.MessageExchangeImpl.handleSend(MessageExchangeImpl.java:571)
> at
> org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.doSend(DeliveryChannelImpl.java:350)
> at
> org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.send(DeliveryChannelImpl.java:397)
> at
> org.apache.servicemix.common.BaseLifeCycle.onMessageExchange(BaseLifeCycle.java:58)
> at
> org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.processInBound(DeliveryChannelImpl.java:610)
> at
> org.apache.servicemix.jbi.nmr.flow.AbstractFlow.doRouting(AbstractFlow.java:174)
> at
> org.apache.servicemix.jbi.nmr.flow.seda.SedaFlow.doRouting(SedaFlow.java:176)
> at
> org.apache.servicemix.jbi.nmr.flow.seda.SedaQueue$1.run(SedaQueue.java:134)
> at
> edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:665)
> at
> edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:690)
> at java.lang.Thread.run(Thread.java:595)
> and this is my configuration
> endpoint="HELLOJmsReceiver"
> targetService="hello:mailSender"
> role="consumer"
> destinationStyle="queue"
> jmsProviderDestinationName="jms/queue/hello"
> connectionFactory="#jmsFactory"
> defaultMep="http://www.w3.org/2004/08/wsdl/in-only"; />
> FYI: when you block SMX with in a debugger, it seems to
> work fine.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: svn commit: r488807 - in /geronimo/server/trunk: PROPOSAL.txt docs_nopublish/
Is server/trunk/STATUS gonna move too? --jason On Dec 19, 2006, at 12:51 PM, [EMAIL PROTECTED] wrote: Author: kevan Date: Tue Dec 19 12:51:10 2006 New Revision: 488807 URL: http://svn.apache.org/viewvc?view=rev&rev=488807 Log: Move old documents out of trunk into geronimo/private Removed: geronimo/server/trunk/PROPOSAL.txt geronimo/server/trunk/docs_nopublish/
[jira] Commented: (GERONIMO-2577) Geronimo cluster (Tomcat Version)cannot continue the HttpSession when current node is down.
[ http://issues.apache.org/jira/browse/GERONIMO-2577?page=comments#action_12459757 ] Dave Colasurdo commented on GERONIMO-2577: -- I have seen clustering fail in multicast mode when the physical machines were not on the same subnet... Even when you plug machines into adjacent wallports, oftentimes the subnets are different. That would be my first guess.. Lots more questions :) 5) I've heard that this same scenario works for you when using Tomcat w/o Geronimo. Did you run the tomcat test on the same exact same three machines as the geronimo test? 6) Are you certain that config.xml has a unique nodename (i.e jvmRoute)for each of the three nodes? 7) Are you certain that the IP addresses are unique (and correct) in the deployment plan for each node? 8) Can you provide all three deployment plans (one for each node)? 9) Any particular reason you set useDirtyFlag=true? 10) I see that you removed the mcastBindAddress setting in the deployment plan. I've heard differing information on whether or not this is needed. Have you tried setting this field in each of the nodes? 11) Have you tried removing waitForAck=true and using ackTimeout for the test? Thanks -Dave- > Geronimo cluster (Tomcat Version)cannot continue the HttpSession when current > node is down. > --- > > Key: GERONIMO-2577 > URL: http://issues.apache.org/jira/browse/GERONIMO-2577 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: Tomcat, Clustering >Affects Versions: 1.1, 1.1.1 > Environment: JDK - Sun java version "1_5_0_09"(32bit) > OS- Red Hat Enterprise Linux ES4 update4(32bit) > Http Server - Apache 2.0.59 +mod_jk 1.2.19 >Reporter: Kaoru Matsumura > Attachments: geronimo-web.xml > > > We run Geronimo cluster with three nodes. > In our environment, with DeltaManager set for replication module, we found > that the last node cound not continue the processes when the other nodes is > intentionally halted in order. > We recognize Tomcat 5.5.15 is OK with the same configuration and operations. > Test Application > > The Web application program, which was used for the test, simply reads the > number of access count, and then write the count to HttpSession object. > Configuration?Files > == > We refer http://cwiki.apache.org/GMOxDOC11/clustering-sample-application.html > * config.xml > We add the following parameters to the standard configuration. > > name=Geronimo > jvmRoute=nodeA > > Operations > === > 1 Have browser access to Test Application , and reload several times.(*1) > HttpSession object is created on the nodeA. > 2 And then, We kill the process of geronimo on the nodeA with $kill -9 > .(*2) > 3 Reload the browser at one time. The node changes to nodeB.(*3) > 4 Reload the browser several times.(*4) > 5 And then, We kill the process of geronimo on the nodeB with $kill -9 > .(*5) > 6 Reload the browser at one time.(And then, We expect that the process > continues at the nodeC.) > But the HttpSessionID of the HttpSession object is changed to another ID > and the counter value is back to 1.(*6) > As a result, the geronimo cluster cannot continue the process. > For avoidance > === > When replication module is SimpleTcpReplicationManager, the geronimo cluster > can continue the process. > Debug levels logs > == > (*1) > nodeA > -- > 20:06:17,736 DEBUG [CoyoteAdapter] Requested cookie session id is > 7160C8614D20687D3548E8488AB65AC3.nodeA > 20:06:17,736 DEBUG [JvmRouteBinderValve] Found Cluster DeltaManager [EMAIL > PROTECTED] at /ClusterCheck > 20:06:17,736 DEBUG [JvmRouteBinderValve] Turnover Check time 0 msec > 20:06:17,737 DEBUG [MsgContext] COMMIT > 20:06:17,737 DEBUG [JkInputStream] COMMIT sending headers [EMAIL PROTECTED] > === MimeHeaders === > 20:06:17,737 DEBUG [MsgContext] CLOSE > 20:06:17,738 DEBUG [REQ_TIME] Time pre=0/ service=2 242 /ClusterCheck/counter > 20:06:17,738 DEBUG [ReplicationValve] Invoking replication request on > /ClusterCheck/counter > 20:06:17,738 DEBUG [DeltaManager] Manager [/ClusterCheck]: create session > message [7160C8614D20687D3548E8488AB65AC3.nodeA] delta request. > 20:06:17,757 DEBUG [McastService] Mcast receive ping from member > org.apache.catalina.cluster.mcast.McastMember[tcp://192.168.1.3:4001,catalina,192.168.1.3,4001, > alive=58960] > --- > nodeC > --- > 20:06:17,655 DEBUG [SimpleTcpCluster] Assuming clocks are synched: > Replication for 7160C8614D20687D3548E8488AB65AC3.nodeA-1162811177738 took=-83 > ms. > 20:06:17,655 DEBUG [DeltaManager] Manager [/ClusterCheck]: Received > SessionMessage of type=(SESSION-DELTA) from > [org.apache.catalina.cluster.mcast.McastMember[
[jira] Created: (SM-788) start/stop/restart on SM
start/stop/restart on SM Key: SM-788 URL: https://issues.apache.org/activemq/browse/SM-788 Project: ServiceMix Issue Type: New Feature Affects Versions: 3.0.1 Environment: Unix/Win32 Reporter: Eyji Priority: Minor It would be a nice feature if the SM startup scripts were parameterized with -start, -restart, -stop, so you don't have to manually kill the processes as processes can be hard to distinguish between, at least in UNIX environments. I will try to provide a patch if I have the time -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SM-782) Re-deploy with In-Only Mep
[
https://issues.apache.org/activemq/browse/SM-782?page=comments#action_37732 ]
Guillaume Nodet commented on SM-782:
We can not put the context directly in the message exchange, because all
properties
put inside the exchange / message must be serializable, else clustering fails.
Upon redeployment, everything is recreated, so I don't think how setting the
pendingMessages
to null would solve the problem. But a modified patch should be fine.
> Re-deploy with In-Only Mep
> --
>
> Key: SM-782
> URL: https://issues.apache.org/activemq/browse/SM-782
> Project: ServiceMix
> Issue Type: Bug
> Components: servicemix-jms
>Affects Versions: 3.1
> Environment: Linux x86/ Java (1.5.0_09)
>Reporter: Grégoire A.
> Attachments: MultiplexingConsumerProcessor.java.2.diff,
> MultiplexingConsumerProcessor.java.diff
>
>
> First deploy JMS-endpoint with target InOnly Service like Mail.
> Run several call.
> redeploy the same JMS-endpoint without modification.
> And recall the service, u should have this exception.
> It could be a safe thread pb, this error is launched in 75% of the cases.
> I think the context of the message cannot be refind.
> ERROR - JmsComponent - Error
> processing exchange InOnly[
> id: ID:jjp-34393-1166462101789-6:229
> status: Done
> role: consumer
> service: {urn:fr.gouv.hello}mailSender
> endpoint: mailSender
> in: encoding="UTF-8"?> xmlns:ns1="http://tempuri.org/HashService/HashClass";
> xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/";
> xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/";
> xmlns:ZSI="http://www.zolera.com/schemas/ZSI/";
> xmlns:xsd="http://www.w3.org/2001/XMLSchema";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>Message
> Change dans BPEL 4 JMS Service
> MD5
> ]
> java.lang.NullPointerException
> at
> org.apache.servicemix.jms.multiplexing.MultiplexingConsumerProcessor.process(MultiplexingConsumerProcessor.java:105)
> at
> org.apache.servicemix.common.AsyncBaseLifeCycle.doProcess(AsyncBaseLifeCycle.java:490)
> at
> org.apache.servicemix.common.AsyncBaseLifeCycle.processExchange(AsyncBaseLifeCycle.java:464)
> at
> org.apache.servicemix.common.BaseLifeCycle.onMessageExchange(BaseLifeCycle.java:46)
> at
> org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.processInBound(DeliveryChannelImpl.java:610)
> at
> org.apache.servicemix.jbi.nmr.flow.AbstractFlow.doRouting(AbstractFlow.java:174)
> at
> org.apache.servicemix.jbi.nmr.flow.seda.SedaFlow.doRouting(SedaFlow.java:176)
> at
> org.apache.servicemix.jbi.nmr.flow.seda.SedaQueue$1.run(SedaQueue.java:134)
> at
> edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:665)
> at
> edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:690)
> at java.lang.Thread.run(Thread.java:595)
> ERROR - JmsComponent - Error setting
> exchange status to ERROR
> javax.jbi.messaging.MessagingException: illegal call
> to send / sendSync
> at
> org.apache.servicemix.jbi.messaging.MessageExchangeImpl.handleSend(MessageExchangeImpl.java:571)
> at
> org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.doSend(DeliveryChannelImpl.java:350)
> at
> org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.send(DeliveryChannelImpl.java:397)
> at
> org.apache.servicemix.common.BaseLifeCycle.onMessageExchange(BaseLifeCycle.java:58)
> at
> org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.processInBound(DeliveryChannelImpl.java:610)
> at
> org.apache.servicemix.jbi.nmr.flow.AbstractFlow.doRouting(AbstractFlow.java:174)
> at
> org.apache.servicemix.jbi.nmr.flow.seda.SedaFlow.doRouting(SedaFlow.java:176)
> at
> org.apache.servicemix.jbi.nmr.flow.seda.SedaQueue$1.run(SedaQueue.java:134)
> at
> edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:665)
> at
> edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:690)
> at java.lang.Thread.run(Thread.java:595)
> and this is my configuration
> endpoint="HELLOJmsReceiver"
> targetService="hello:mailSender"
> role="consumer"
> destinationStyle="queue"
> jmsProviderDestinationName="jms/queue/hello"
> connectionFactory="#jmsFactory"
> defaultMep="http://www.w3.org/2004/08/wsdl/in-only"; />
> FYI: when you block SMX with in a debugger, it seems to
> work fine.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/activemq/secure/Ad
Re: svn commit: r487651 - /geronimo/server/trunk/pom.xml
On Dec 19, 2006, at 6:23 AM, Vamsavardhana Reddy wrote: On 12/16/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote: On Dec 15, 2006, at 3:57 PM, Jason Dillon wrote: > Yikes... what happened on this change? > > The diff shows a lot more changed than just what was indicated in > the comment... > Ya, looks like a formatting change. A diff before would help :) I too am guilty of transgressions like this. Thanks for the reminder. I check the diff on each file before checkin and eliminate all unnecessary changes (like line with spaces replacing blank lines etc.). It costs some extra time :o(, but, keeps the commit clean. I hope that my energy will last for some more time :o) I usually do as Jason suggested and check my "beauty" diff in first. That is if I notice the formatting is not right before I start editing :) -David
[jira] Commented: (SM-782) Re-deploy with In-Only Mep
[
https://issues.apache.org/activemq/browse/SM-782?page=comments#action_37731 ]
Grégoire A. commented on SM-782:
i can improve my modification by remove the message's context before the
return action.
two rem:
- if we need a mapping between an message-exchange and context, why we cannot
carry the context in messageexchange object. I dont know if the architecture
agree this solution.
(4 guillaume: this meet the last paragraph of the previous message)
- We have a problem with the re-deploy, can we delete pendingMessages( = null)
object and create it in constructor or in a better way in a init method, it
could be resolve our pb.
(i will test this solution ASAP)
> Re-deploy with In-Only Mep
> --
>
> Key: SM-782
> URL: https://issues.apache.org/activemq/browse/SM-782
> Project: ServiceMix
> Issue Type: Bug
> Components: servicemix-jms
>Affects Versions: 3.1
> Environment: Linux x86/ Java (1.5.0_09)
>Reporter: Grégoire A.
> Attachments: MultiplexingConsumerProcessor.java.2.diff,
> MultiplexingConsumerProcessor.java.diff
>
>
> First deploy JMS-endpoint with target InOnly Service like Mail.
> Run several call.
> redeploy the same JMS-endpoint without modification.
> And recall the service, u should have this exception.
> It could be a safe thread pb, this error is launched in 75% of the cases.
> I think the context of the message cannot be refind.
> ERROR - JmsComponent - Error
> processing exchange InOnly[
> id: ID:jjp-34393-1166462101789-6:229
> status: Done
> role: consumer
> service: {urn:fr.gouv.hello}mailSender
> endpoint: mailSender
> in: encoding="UTF-8"?> xmlns:ns1="http://tempuri.org/HashService/HashClass";
> xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/";
> xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/";
> xmlns:ZSI="http://www.zolera.com/schemas/ZSI/";
> xmlns:xsd="http://www.w3.org/2001/XMLSchema";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>Message
> Change dans BPEL 4 JMS Service
> MD5
> ]
> java.lang.NullPointerException
> at
> org.apache.servicemix.jms.multiplexing.MultiplexingConsumerProcessor.process(MultiplexingConsumerProcessor.java:105)
> at
> org.apache.servicemix.common.AsyncBaseLifeCycle.doProcess(AsyncBaseLifeCycle.java:490)
> at
> org.apache.servicemix.common.AsyncBaseLifeCycle.processExchange(AsyncBaseLifeCycle.java:464)
> at
> org.apache.servicemix.common.BaseLifeCycle.onMessageExchange(BaseLifeCycle.java:46)
> at
> org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.processInBound(DeliveryChannelImpl.java:610)
> at
> org.apache.servicemix.jbi.nmr.flow.AbstractFlow.doRouting(AbstractFlow.java:174)
> at
> org.apache.servicemix.jbi.nmr.flow.seda.SedaFlow.doRouting(SedaFlow.java:176)
> at
> org.apache.servicemix.jbi.nmr.flow.seda.SedaQueue$1.run(SedaQueue.java:134)
> at
> edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:665)
> at
> edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:690)
> at java.lang.Thread.run(Thread.java:595)
> ERROR - JmsComponent - Error setting
> exchange status to ERROR
> javax.jbi.messaging.MessagingException: illegal call
> to send / sendSync
> at
> org.apache.servicemix.jbi.messaging.MessageExchangeImpl.handleSend(MessageExchangeImpl.java:571)
> at
> org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.doSend(DeliveryChannelImpl.java:350)
> at
> org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.send(DeliveryChannelImpl.java:397)
> at
> org.apache.servicemix.common.BaseLifeCycle.onMessageExchange(BaseLifeCycle.java:58)
> at
> org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.processInBound(DeliveryChannelImpl.java:610)
> at
> org.apache.servicemix.jbi.nmr.flow.AbstractFlow.doRouting(AbstractFlow.java:174)
> at
> org.apache.servicemix.jbi.nmr.flow.seda.SedaFlow.doRouting(SedaFlow.java:176)
> at
> org.apache.servicemix.jbi.nmr.flow.seda.SedaQueue$1.run(SedaQueue.java:134)
> at
> edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:665)
> at
> edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:690)
> at java.lang.Thread.run(Thread.java:595)
> and this is my configuration
> endpoint="HELLOJmsReceiver"
> targetService="hello:mailSender"
> role="consumer"
> destinationStyle="queue"
> jmsProviderDestinationName="jms/queue/hello"
> connectionFactory="#jmsFactory"
> defaultMep="http://www.w3.org/2004/08/wsdl/in-only"; />
> FYI: when you bl
Java EE 5.0 Report Card updated
The Java EE 5.0 Report card has been updated on the project wiki. This update incorporates all the recent 2.0-M1 activity and other recent developments relating to Java EE 5.0. Please take a second to review it for accuracy. http://cwiki.apache.org/confluence/display/GMOxPMGT/Geronimo+Java+EE+5.0+Report+Card Thanks -Dave-
Re: svn commit: r487651 - /geronimo/server/trunk/pom.xml
I actually use the diff to help me remember what I changed... so its part of my routine. TextMate is awesome too, you can `svn diff | mate` and it will open up an editor in diff mode with colors... so nice :-) --jason On Dec 19, 2006, at 6:23 AM, Vamsavardhana Reddy wrote: On 12/16/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote: On Dec 15, 2006, at 3:57 PM, Jason Dillon wrote: > Yikes... what happened on this change? > > The diff shows a lot more changed than just what was indicated in > the comment... > Ya, looks like a formatting change. A diff before would help :) I too am guilty of transgressions like this. Thanks for the reminder. I check the diff on each file before checkin and eliminate all unnecessary changes (like line with spaces replacing blank lines etc.). It costs some extra time :o(, but, keeps the commit clean. I hope that my energy will last for some more time :o) Matt Hogstrom [EMAIL PROTECTED]
Re: Performance Issue
Changing the delivery mode to NONpersisitent and creating the session using Session.DUPS_OK_ACKNOWLEDGE is effectively increasing the performance..now it is processing 1000 transactions in less than 2 sec James.Strachan wrote: > > On 12/19/06, garima015 <[EMAIL PROTECTED]> wrote: >> >> Thanks for the reply,but it is solved. > > How did you solve it? > > -- > > James > --- > http://radio.weblogs.com/0112098/ > > -- View this message in context: http://www.nabble.com/Performance-Issue-tf2841698.html#a7952578 Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
[jira] Updated: (GERONIMO-2671) Streaming API for XML and JAXB integration
[ http://issues.apache.org/jira/browse/GERONIMO-2671?page=all ] Jarek Gawor updated GERONIMO-2671: -- Attachment: stax-jaxb.patch It looks like the initial patch created classloader problems for the cxf module. This patch resolves those issues by creating a separate configuration for the jaxb and stax implementations. The patch also contains minor fixes to the tomcat6-deployer plan (enable CXF and remove unnecessary dependency on j2ee-server module). > Streaming API for XML and JAXB integration > -- > > Key: GERONIMO-2671 > URL: http://issues.apache.org/jira/browse/GERONIMO-2671 > Project: Geronimo > Issue Type: New Feature > Security Level: public(Regular issues) >Affects Versions: 2.0 >Reporter: Jarek Gawor > Attachments: stax-jaxb.patch, stax-jaxb.patch > > > The attached patch integrates the Streaming API for XML and JAXB with > Geronimo. Any web application (JSP, servlet) or EJB will be able to use the > StAX or JAXB API. The patch also includes basic tests to verify that the > streaming and JAXB API can be used within the web or ejb container. The > woodstox xml processor is used as the implementation behind the streaming > API. The Sun's JAXB RI is used for JAXB support. > Since this is my first attempt at such integration, please let me know if > there is a better way of doing things, if i missed something, etc. > This patch supersedes the patch in > https://issues.apache.org/jira/browse/GERONIMO-2667. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-2577) Geronimo cluster (Tomcat Version)cannot continue the HttpSession when current node is down.
[ http://issues.apache.org/jira/browse/GERONIMO-2577?page=comments#action_12459700 ] Dave Colasurdo commented on GERONIMO-2577: -- 1) Is node c (the failing node) always the same physical machine? 2) Are you 100% certain that all three nodes are on the same subnet? This is extremely important.. Applying the subnet mask to each nodes IP address should yield the exact same network portion of the IP address. 3) Have you added thetag to the web.xml for each clustered app? 4) Can you please elaborate on the following statement ..."When replication module is SimpleTcpReplicationManager, the geronimo cluster can continue the process." What exactly does that mean? What replication module are you using? Thanks > Geronimo cluster (Tomcat Version)cannot continue the HttpSession when current > node is down. > --- > > Key: GERONIMO-2577 > URL: http://issues.apache.org/jira/browse/GERONIMO-2577 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: Tomcat, Clustering >Affects Versions: 1.1, 1.1.1 > Environment: JDK - Sun java version "1_5_0_09"(32bit) > OS- Red Hat Enterprise Linux ES4 update4(32bit) > Http Server - Apache 2.0.59 +mod_jk 1.2.19 >Reporter: Kaoru Matsumura > Attachments: geronimo-web.xml > > > We run Geronimo cluster with three nodes. > In our environment, with DeltaManager set for replication module, we found > that the last node cound not continue the processes when the other nodes is > intentionally halted in order. > We recognize Tomcat 5.5.15 is OK with the same configuration and operations. > Test Application > > The Web application program, which was used for the test, simply reads the > number of access count, and then write the count to HttpSession object. > Configuration?Files > == > We refer http://cwiki.apache.org/GMOxDOC11/clustering-sample-application.html > * config.xml > We add the following parameters to the standard configuration. > > name=Geronimo > jvmRoute=nodeA > > Operations > === > 1 Have browser access to Test Application , and reload several times.(*1) > HttpSession object is created on the nodeA. > 2 And then, We kill the process of geronimo on the nodeA with $kill -9 > .(*2) > 3 Reload the browser at one time. The node changes to nodeB.(*3) > 4 Reload the browser several times.(*4) > 5 And then, We kill the process of geronimo on the nodeB with $kill -9 > .(*5) > 6 Reload the browser at one time.(And then, We expect that the process > continues at the nodeC.) > But the HttpSessionID of the HttpSession object is changed to another ID > and the counter value is back to 1.(*6) > As a result, the geronimo cluster cannot continue the process. > For avoidance > === > When replication module is SimpleTcpReplicationManager, the geronimo cluster > can continue the process. > Debug levels logs > == > (*1) > nodeA > -- > 20:06:17,736 DEBUG [CoyoteAdapter] Requested cookie session id is > 7160C8614D20687D3548E8488AB65AC3.nodeA > 20:06:17,736 DEBUG [JvmRouteBinderValve] Found Cluster DeltaManager [EMAIL > PROTECTED] at /ClusterCheck > 20:06:17,736 DEBUG [JvmRouteBinderValve] Turnover Check time 0 msec > 20:06:17,737 DEBUG [MsgContext] COMMIT > 20:06:17,737 DEBUG [JkInputStream] COMMIT sending headers [EMAIL PROTECTED] > === MimeHeaders === > 20:06:17,737 DEBUG [MsgContext] CLOSE > 20:06:17,738 DEBUG [REQ_TIME] Time pre=0/ service=2 242 /ClusterCheck/counter > 20:06:17,738 DEBUG [ReplicationValve] Invoking replication request on > /ClusterCheck/counter > 20:06:17,738 DEBUG [DeltaManager] Manager [/ClusterCheck]: create session > message [7160C8614D20687D3548E8488AB65AC3.nodeA] delta request. > 20:06:17,757 DEBUG [McastService] Mcast receive ping from member > org.apache.catalina.cluster.mcast.McastMember[tcp://192.168.1.3:4001,catalina,192.168.1.3,4001, > alive=58960] > --- > nodeC > --- > 20:06:17,655 DEBUG [SimpleTcpCluster] Assuming clocks are synched: > Replication for 7160C8614D20687D3548E8488AB65AC3.nodeA-1162811177738 took=-83 > ms. > 20:06:17,655 DEBUG [DeltaManager] Manager [/ClusterCheck]: Received > SessionMessage of type=(SESSION-DELTA) from > [org.apache.catalina.cluster.mcast.McastMember[tcp://192.168.1.1:4001,catalina,192.168.1.1,4001, > alive=130441]] > 20:06:17,655 DEBUG [DeltaManager] Manager [/ClusterCheck]: received session > [7160C8614D20687D3548E8488AB65AC3.nodeA] delta. > --- > (*2) > nodeB (same as nodeC) > --- > 20:06:39,817 INFO [SimpleTcpCluster] Received member > disappeared:org.apache.catalina.cluster.mcast.McastMember[tcp://192.168.1.1:4001,catalina,192.168.1.1,4001, > alive=149288] > 20:06:39,81
Re: Trunk runtime error GBeanInstanceState- deserializing GBeanState
Anecdotal evidence: i spent 4 days to get the builds working and took me 2 hours to fix the code problems related to the cxfPojoWS. thanks, -- dims On 12/19/06, Donald Woods <[EMAIL PROTECTED]> wrote: This is a very sad state of affairs, as we are spending more time getting this convoluted maven build to work than writing code, just as many have pointed out and I'm sure will cause jdillon and anyone doing CTS testing ulcers. Is it not time to split the Geronimo 2.0 build into separate maven-plugin, modules, applications, configs and assembly build steps??? We are using multiple groupIds, so why not split up the builds for each unique groupId? -Donald anita kulshreshtha wrote: > Dims, >Yes, it is not straightforward to do an offline build.. This is what > many of us do: > 1. If starting from an empty repo do a full online build. Delete > modules, configs and assemblies directory from .m2 repo. Do an offline > build of these items (sometimes car plugin). > 2. After an svn update, build the files that changed from their > respective modules directory online. This will download any new jars. > Delete the modules, configs, and assemblies from .m2 repo and do an > offline full build. > Not pretty but works.. I started using this after my local classes > went missing.. > I have been looking at the code to figure out why the > incompatibility was not caught by the compatibility test in > GBeanDataTest. Does anyone know? > > Thanks > Anita > > > --- Davanum Srinivas <[EMAIL PROTECTED]> wrote: > >> Anita, >> >> Try this when you have some time. >> >> 1. Remove your .m2 >> 2. "mvn install" from root. >> 3. cd to testsuite and run "mvn -N install" >> 4. cd to itests and run "mvn -N install" >> 5. cd to cxfPojoWS and run "mvn -o install" >> >> It's impossible to execute 5 with "-o" flag as the project needs to >> download cxf stuff from the remote repo. since you can't use the "-o" >> flag it will pick up the remote jar for geronimo-kernel. If you >> search >> all the sub directories after running 5, you will see 2 jars for >> geronimo-kernel, one built locally and one from the remote repo. >> Basically you are dead in the water. After this, you will have to >> replace the remote jar with the local jar and re-run "mvn install" to >> actually run the test. >> >> So basically "The only way to make sure that the local jars/cars are >> used is to do an offile build" is not possible. >> >> thanks, >> dims >> >> On 12/18/06, anita kulshreshtha <[EMAIL PROTECTED]> wrote: >>> --- Davanum Srinivas <[EMAIL PROTECTED]> wrote: >>> Anita, Anyone who builds geronimo from scratch is likely to into into problem. We can't really tell people they can't use the jars they build themselves on their boxes and have to use the published SNAPSHOT jars. >>> We do not tell people that they have to use the published jars. >> It is >>> clear from this error that maven is still downloading jars from a >>> remote repo instead of using the ones that were built locally. The >> only >>> way to make sure that the local jars/cars are used is to do an >> offile >>> build. >>> >>> Thanks >>> Anita >>> >>> So i think we need to fix it. >>> Just imagine that you are trying to fix a bug in Geronimo kernel for shipping to your customer, >> but the code does not have a serial version uid and the compiled jar is >> hence unusable...not a pretty picture. I don't think we have to "worry" about compatibility especially as right now if 2 jars built from >> same svn revision by 2 different people on different JDK's/JDK >> versions on different boxes, you can't mix the jars. So there is no "compatibility" right now :( Anyway my specific problem was because of lack of the UID in GBeanOperation and i checked in a patch for it (487759). thanks, dims On 12/16/06, anita kulshreshtha <[EMAIL PROTECTED]> wrote: > Dims, Joe, and Prasad > I wish I had seen this coming.. The compatibility of >> GBeanInfo was > broken for 4 days (Dec 10th - Dec 14), while we discussed >> whether we > should maintain this compatibility. In a perfect world it would >> not > have mattered.. But sometimes Maven does not use locally built > SNAPSHOTs in online build mode (some of the reasons for this >> are > known). Once the SNAPSHOTs published during this time, are overwritten, > this problem should go way. At least that is my thinking... >> Please > correct me if I am on wrong track. > > Thanks > Anita > > --- Joe Bohn <[EMAIL PROTECTED]> wrote: > >> Prasad, >> >> I'm hitting this particular problem in trunk (but I have hit similar >> problems in 2.0-M1). I actually was trying to recreate the problem >> today in both trunk and 2.0-M1 ... after 4 builds on 2.0-M1 I didn't >> hit >> the problem but I hit it with the first attempt on trunk. >
Re: Trunk runtime error GBeanInstanceState- deserializing GBeanState
This is a very sad state of affairs, as we are spending more time getting this convoluted maven build to work than writing code, just as many have pointed out and I'm sure will cause jdillon and anyone doing CTS testing ulcers. Is it not time to split the Geronimo 2.0 build into separate maven-plugin, modules, applications, configs and assembly build steps??? We are using multiple groupIds, so why not split up the builds for each unique groupId? -Donald anita kulshreshtha wrote: Dims, Yes, it is not straightforward to do an offline build.. This is what many of us do: 1. If starting from an empty repo do a full online build. Delete modules, configs and assemblies directory from .m2 repo. Do an offline build of these items (sometimes car plugin). 2. After an svn update, build the files that changed from their respective modules directory online. This will download any new jars. Delete the modules, configs, and assemblies from .m2 repo and do an offline full build. Not pretty but works.. I started using this after my local classes went missing.. I have been looking at the code to figure out why the incompatibility was not caught by the compatibility test in GBeanDataTest. Does anyone know? Thanks Anita --- Davanum Srinivas <[EMAIL PROTECTED]> wrote: Anita, Try this when you have some time. 1. Remove your .m2 2. "mvn install" from root. 3. cd to testsuite and run "mvn -N install" 4. cd to itests and run "mvn -N install" 5. cd to cxfPojoWS and run "mvn -o install" It's impossible to execute 5 with "-o" flag as the project needs to download cxf stuff from the remote repo. since you can't use the "-o" flag it will pick up the remote jar for geronimo-kernel. If you search all the sub directories after running 5, you will see 2 jars for geronimo-kernel, one built locally and one from the remote repo. Basically you are dead in the water. After this, you will have to replace the remote jar with the local jar and re-run "mvn install" to actually run the test. So basically "The only way to make sure that the local jars/cars are used is to do an offile build" is not possible. thanks, dims On 12/18/06, anita kulshreshtha <[EMAIL PROTECTED]> wrote: --- Davanum Srinivas <[EMAIL PROTECTED]> wrote: Anita, Anyone who builds geronimo from scratch is likely to into into problem. We can't really tell people they can't use the jars they build themselves on their boxes and have to use the published SNAPSHOT jars. We do not tell people that they have to use the published jars. It is clear from this error that maven is still downloading jars from a remote repo instead of using the ones that were built locally. The only way to make sure that the local jars/cars are used is to do an offile build. Thanks Anita So i think we need to fix it. Just imagine that you are trying to fix a bug in Geronimo kernel for shipping to your customer, but the code does not have a serial version uid and the compiled jar is hence unusable...not a pretty picture. I don't think we have to "worry" about compatibility especially as right now if 2 jars built from same svn revision by 2 different people on different JDK's/JDK versions on different boxes, you can't mix the jars. So there is no "compatibility" right now :( Anyway my specific problem was because of lack of the UID in GBeanOperation and i checked in a patch for it (487759). thanks, dims On 12/16/06, anita kulshreshtha <[EMAIL PROTECTED]> wrote: Dims, Joe, and Prasad I wish I had seen this coming.. The compatibility of GBeanInfo was broken for 4 days (Dec 10th - Dec 14), while we discussed whether we should maintain this compatibility. In a perfect world it would not have mattered.. But sometimes Maven does not use locally built SNAPSHOTs in online build mode (some of the reasons for this are known). Once the SNAPSHOTs published during this time, are overwritten, this problem should go way. At least that is my thinking... Please correct me if I am on wrong track. Thanks Anita --- Joe Bohn <[EMAIL PROTECTED]> wrote: Prasad, I'm hitting this particular problem in trunk (but I have hit similar problems in 2.0-M1). I actually was trying to recreate the problem today in both trunk and 2.0-M1 ... after 4 builds on 2.0-M1 I didn't hit the problem but I hit it with the first attempt on trunk. As I mentioned, the second build attempt corrected the problem. Joe Prasad Kashyap wrote: I was able to build G successfully on a RedHat machine. I started with a completely clean repo (rm -rf .m2/repository). I did an 'svn up' of my 2.0-M1 directory. I had done a fresh checkout of these files last night. The entire tree built successfully with a -Dmaven.test.skip=true. I verified that both jetty and tomcat binaries run fine. I used the console to successfully deploy jsp-examples app on both binaries. Cheers Prasad On 12/15/06, Joe Bohn <[EMAIL PROTECTED]> wrote: This might be the sporadic problem a
Re: Trunk runtime error GBeanInstanceState- deserializing GBeanState
Dims, Yes, it is not straightforward to do an offline build.. This is what many of us do: 1. If starting from an empty repo do a full online build. Delete modules, configs and assemblies directory from .m2 repo. Do an offline build of these items (sometimes car plugin). 2. After an svn update, build the files that changed from their respective modules directory online. This will download any new jars. Delete the modules, configs, and assemblies from .m2 repo and do an offline full build. Not pretty but works.. I started using this after my local classes went missing.. I have been looking at the code to figure out why the incompatibility was not caught by the compatibility test in GBeanDataTest. Does anyone know? Thanks Anita --- Davanum Srinivas <[EMAIL PROTECTED]> wrote: > Anita, > > Try this when you have some time. > > 1. Remove your .m2 > 2. "mvn install" from root. > 3. cd to testsuite and run "mvn -N install" > 4. cd to itests and run "mvn -N install" > 5. cd to cxfPojoWS and run "mvn -o install" > > It's impossible to execute 5 with "-o" flag as the project needs to > download cxf stuff from the remote repo. since you can't use the "-o" > flag it will pick up the remote jar for geronimo-kernel. If you > search > all the sub directories after running 5, you will see 2 jars for > geronimo-kernel, one built locally and one from the remote repo. > Basically you are dead in the water. After this, you will have to > replace the remote jar with the local jar and re-run "mvn install" to > actually run the test. > > So basically "The only way to make sure that the local jars/cars are > used is to do an offile build" is not possible. > > thanks, > dims > > On 12/18/06, anita kulshreshtha <[EMAIL PROTECTED]> wrote: > > --- Davanum Srinivas <[EMAIL PROTECTED]> wrote: > > > > > Anita, > > > > > > Anyone who builds geronimo from scratch is likely to into into > > > problem. We can't really tell people they can't use the jars they > > > build themselves on their boxes and have to use the published > > > SNAPSHOT > > > jars. > > > > We do not tell people that they have to use the published jars. > It is > > clear from this error that maven is still downloading jars from a > > remote repo instead of using the ones that were built locally. The > only > > way to make sure that the local jars/cars are used is to do an > offile > > build. > > > > Thanks > > Anita > > > > So i think we need to fix it. > > Just imagine that you are trying > > > to fix a bug in Geronimo kernel for shipping to your customer, > but > > > the > > > code does not have a serial version uid and the compiled jar is > hence > > > unusable...not a pretty picture. I don't think we have to "worry" > > > about compatibility especially as right now if 2 jars built from > same > > > svn revision by 2 different people on different JDK's/JDK > versions on > > > different boxes, you can't mix the jars. So there is no > > > "compatibility" right now :( > > > > > > Anyway my specific problem was because of lack of the UID in > > > GBeanOperation and i checked in a patch for it (487759). > > > > > > thanks, > > > dims > > > > > > On 12/16/06, anita kulshreshtha <[EMAIL PROTECTED]> wrote: > > > > Dims, Joe, and Prasad > > > > I wish I had seen this coming.. The compatibility of > GBeanInfo > > > was > > > > broken for 4 days (Dec 10th - Dec 14), while we discussed > whether > > > we > > > > should maintain this compatibility. In a perfect world it would > not > > > > have mattered.. But sometimes Maven does not use locally built > > > > SNAPSHOTs in online build mode (some of the reasons for this > are > > > > known). Once the SNAPSHOTs published during this time, are > > > overwritten, > > > > this problem should go way. At least that is my thinking... > Please > > > > correct me if I am on wrong track. > > > > > > > > Thanks > > > > Anita > > > > > > > > --- Joe Bohn <[EMAIL PROTECTED]> wrote: > > > > > > > > > Prasad, > > > > > > > > > > I'm hitting this particular problem in trunk (but I have hit > > > similar > > > > > problems in 2.0-M1). I actually was trying to recreate the > > > problem > > > > > today in both trunk and 2.0-M1 ... after 4 builds on 2.0-M1 I > > > didn't > > > > > hit > > > > > the problem but I hit it with the first attempt on trunk. > As I > > > > > mentioned, the second build attempt corrected the problem. > > > > > > > > > > Joe > > > > > > > > > > > > > > > Prasad Kashyap wrote: > > > > > > I was able to build G successfully on a RedHat machine. > > > > > > > > > > > > I started with a completely clean repo (rm -rf > .m2/repository). > > > > > > > > > > > > I did an 'svn up' of my 2.0-M1 directory. I had done a > fresh > > > > > checkout > > > > > > of these files last night. > > > > > > > > > > > > The entire tree built successfully with a > > > -Dmaven.test.skip=true. > > > > > > > > > > > > I verified that both jetty and tomcat binaries run fine. > > > > > > > > > > > > I used the console to succe
Re: svn commit: r487651 - /geronimo/server/trunk/pom.xml
On 12/16/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote: On Dec 15, 2006, at 3:57 PM, Jason Dillon wrote: > Yikes... what happened on this change? > > The diff shows a lot more changed than just what was indicated in > the comment... > Ya, looks like a formatting change. A diff before would help :) I too am guilty of transgressions like this. Thanks for the reminder. I check the diff on each file before checkin and eliminate all unnecessary changes (like line with spaces replacing blank lines etc.). It costs some extra time :o(, but, keeps the commit clean. I hope that my energy will last for some more time :o) Matt Hogstrom [EMAIL PROTECTED]
Re: svn commit: r488326 - /geronimo/server/tags/2.0-M1/testsuite/deployment-testsuite/manifestcp/manifestcp-ejb/src/main/resources/META-INF/ejb-jar.xml
I agree with Jason. We should not be changing code once tagged. --vamsi On 12/19/06, Jason Dillon <[EMAIL PROTECTED]> wrote: Ugh... this is why I don't like all that moving of branches to tags... A "tag" or "label" should never be modified... its a point in time, not indented (or expected) to be changed. I believe that we would be doing ourselves a major favor by following some SCM best practices... moving branches to tags is not one of them... neither is changing code in a tag. --jason On Dec 18, 2006, at 8:35 AM, [EMAIL PROTECTED] wrote: > Author: kevan > Date: Mon Dec 18 08:35:24 2006 > New Revision: 488326 > > URL: http://svn.apache.org/viewvc?view=rev&rev=488326 > Log: > add missing license header > > Modified: > geronimo/server/tags/2.0-M1/testsuite/deployment-testsuite/ > manifestcp/manifestcp-ejb/src/main/resources/META-INF/ejb-jar.xml > > Modified: geronimo/server/tags/2.0-M1/testsuite/deployment- > testsuite/manifestcp/manifestcp-ejb/src/main/resources/META-INF/ejb- > jar.xml > URL: http://svn.apache.org/viewvc/geronimo/server/tags/2.0-M1/ > testsuite/deployment-testsuite/manifestcp/manifestcp-ejb/src/main/ > resources/META-INF/ejb-jar.xml? > view=diff&rev=488326&r1=488325&r2=488326 > == > > --- geronimo/server/tags/2.0-M1/testsuite/deployment-testsuite/ > manifestcp/manifestcp-ejb/src/main/resources/META-INF/ejb-jar.xml > (original) > +++ geronimo/server/tags/2.0-M1/testsuite/deployment-testsuite/ > manifestcp/manifestcp-ejb/src/main/resources/META-INF/ejb-jar.xml > Mon Dec 18 08:35:24 2006 > @@ -1,4 +1,20 @@ > > + > xmlns="http://java.sun.com/xml/ns/j2ee"; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > >
Re: [VOTE] 2.0-M1 Release
+1 --vamsi On 12/18/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote: All, I have prepared 2.0-M1 for release. Of course all the hard work was done by the lot of y'all :) I have tested DayTrader 2.0-SNAPSHOT on this build and I'm satisfied with the results. All modes of operation functioned well (SLSB, Direct, EJB and JPA). I toned all the logs down to error to not overwhelm the users with lots of diagnostic output (they can always turn it up later if they want.) The uploads are taking forever so you'll see some piece parts trickle in. For the review I expect you'll want to focus on http:// people.apache.org/~hogstrom/2.0-M1 as this contains the assemblies for your review and testing. I've included both Tomcat and Jetty as well as the minimal and j5ee assemblies. The source code is also there. Note that if you are planning on building you'll need to obtain the openejb-2.2-incubating jars to your local repo. The easiest way to do this is to modify the root pom and add a repository for David's home directory at http://people.apache.org/~dblevins/stage/. For SNAPSHOTs of certain plugins I have resolved these files to the most recent SNAPSHOT date / timestamp. I'm pulling a copy of these and will be putting them into our SVN for folks who may want to build in the future. I'm not too concerned about repeatability as this Milestone will be superseded at the end of January with the next version. The other MAven artifacts will be trickling onto people across my horribly slow home pipe and dropped into http://people.apache.org/ ~hogstrom/stage over the next few hours. Please review and cast your vote early. The faster we determine this build is good or if there is an issue the better. Thanks in advance for all your help in this effort. This vote will conclude at 0400 ET on Dec 21 (unless all you PMC members vote quicker :) If a respin is is necessary this vote will be suspended and a new one will start. Matt Hogstrom [EMAIL PROTECTED]
Re: Error when deploying day trader - 2.0-M1-SNAPSHOT
Ran into the same thing... for both Geronimo 1.2 and 2.0 you need to add the following to the dependency list in the daytrader deployment plans. org.apache.geronimo.configs j2ee-corba-yoko car On 12/18/06, Krishnakumar B <[EMAIL PROTECTED]> wrote: 2.0-M1-SNAPSHOT On 12/18/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote: > What Geronimo Version are you deploying against? > > On Dec 15, 2006, at 6:20 AM, Krishnakumar B wrote: > > > I get a Nullpointer exception when deploying daytrader. I used the JPA > > plan to deploy the application. > > > > Tomcat error > > > > 16:26:22,715 ERROR [GBeanInstanceState] Error while starting; GBean is > > now in the FAILED state: > > abstractName="org.apache.geronimo.daytrader/daytrader/2.0-SNAPSHOT/ > > car?J2EEApplication=org.apache.geronimo.daytrader/daytrader/2.0- > > SNAPSHOT/car,j2eeType=WebModule,name=web.war" > > java.lang.NullPointerException > > at java.util.Hashtable.put(Hashtable.java:396) > > at org.apache.naming.resources.DirContextURLStreamHandler.bind > > (DirContextURLStreamHandler.java:234) > > at org.apache.geronimo.tomcat.TomcatWebAppContext.doStart > > (TomcatWebAppContext.java:477) > > at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance > > (GBeanInstance.java:984) > > at > > org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart( > > GBeanInstanceState.java:267) > > at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start > > (GBeanInstanceState.java:102) > > at org.apache.geronimo.gbean.runtime.GBeanInstance.start > > (GBeanInstance.java:529) > > at > > org.apache.geronimo.gbean.runtime.GBeanDependency.attemptFullStart > > (GBeanDependency.java:111) > > at org.apache.geronimo.gbean.runtime.GBeanDependency.addTarget > > (GBeanDependency.java:146) > > at org.apache.geronimo.gbean.runtime.GBeanDependency$1.running > > (GBeanDependency.java:120) > > at > > org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.fireRunningEven > > t(BasicLifecycleMonitor.java:173) > > at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.access > > $300(BasicLifecycleMonitor.java:41) > > at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor > > $RawLifecycleBroadcaster.fireRunningEvent > > (BasicLifecycleMonitor.java:251) > > at > > org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart( > > GBeanInstanceState.java:292) > > at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start > > (GBeanInstanceState.java:102) > > at > > org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive > > (GBeanInstanceState.java:124) > > at org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive > > (GBeanInstance.java:543) > > at org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean > > (BasicKernel.java:379) > > at > > org.apache.geronimo.kernel.config.ConfigurationUtil.startConfiguration > > GBeans(ConfigurationUtil.java:378) > > at > > org.apache.geronimo.kernel.config.ConfigurationUtil.startConfiguration > > GBeans(ConfigurationUtil.java:415) > > at > > org.apache.geronimo.kernel.config.KernelConfigurationManager.start > > (KernelConfigurationManager.java:187) > > at > > org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConf > > iguration(SimpleConfigurationManager.java:527) > > at > > org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConf > > iguration(SimpleConfigurationManager.java:508) > > at org.apache.geronimo.kernel.config.SimpleConfigurationManager$ > > $FastClassByCGLIB$$ce77a924.invoke() > > at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) > > at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke > > (FastMethodInvoker.java:38) > > at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke > > (GBeanOperation.java:124) > > at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke > > (GBeanInstance.java:820) > > at org.apache.geronimo.gbean.runtime.RawInvoker.invoke > > (RawInvoker.java:57) > > at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke > > (RawOperationInvoker.java:35) > > at > > org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept > > (ProxyMethodInterceptor.java:96) > > at org.apache.geronimo.kernel.config.EditableConfigurationManager$ > > $EnhancerByCGLIB$$b42bfad1.startConfiguration() > > at org.apache.geronimo.deployment.plugin.local.StartCommand.run > > (StartCommand.java:67) > > at java.lang.Thread.run(Thread.java:595) > > 16:26:22,965 WARN [TomcatWebAppContext] TomcatWebAppContext failed > > 16:26:22,965 ERROR [GBeanInstanceState] Error while starting; GBean is > > now in the FAILED state: > > abstractName="org.apache.geronimo.daytrader/daytrader/2.0-SNAPSHOT/ > > car?J2EEApplication=org.apache.geronimo.daytrader/daytrader/2.0- > > SNAPSHOT/car,j2eeType=WebModu
[jira] Commented: (SM-782) Re-deploy with In-Only Mep
[
https://issues.apache.org/activemq/browse/SM-782?page=comments#action_37726 ]
Guillaume Nodet commented on SM-782:
If you could just keep the indentation to 4 spaces, the patch will be perfect :)
To become a committer, keep sending patches and get involved on the mailing
lists.
All contributions can lead to committer status, be it bug fixes, docs or new
features,
help on examples If you need ideas, tell me :)
The only real need imho, is to show a sustained involvment (it does not need to
be
high, just sustained), and that's why it can not happen in a few days.
> Re-deploy with In-Only Mep
> --
>
> Key: SM-782
> URL: https://issues.apache.org/activemq/browse/SM-782
> Project: ServiceMix
> Issue Type: Bug
> Components: servicemix-jms
>Affects Versions: 3.1
> Environment: Linux x86/ Java (1.5.0_09)
>Reporter: Grégoire A.
> Attachments: MultiplexingConsumerProcessor.java.diff
>
>
> First deploy JMS-endpoint with target InOnly Service like Mail.
> Run several call.
> redeploy the same JMS-endpoint without modification.
> And recall the service, u should have this exception.
> It could be a safe thread pb, this error is launched in 75% of the cases.
> I think the context of the message cannot be refind.
> ERROR - JmsComponent - Error
> processing exchange InOnly[
> id: ID:jjp-34393-1166462101789-6:229
> status: Done
> role: consumer
> service: {urn:fr.gouv.hello}mailSender
> endpoint: mailSender
> in: encoding="UTF-8"?> xmlns:ns1="http://tempuri.org/HashService/HashClass";
> xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/";
> xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/";
> xmlns:ZSI="http://www.zolera.com/schemas/ZSI/";
> xmlns:xsd="http://www.w3.org/2001/XMLSchema";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>Message
> Change dans BPEL 4 JMS Service
> MD5
> ]
> java.lang.NullPointerException
> at
> org.apache.servicemix.jms.multiplexing.MultiplexingConsumerProcessor.process(MultiplexingConsumerProcessor.java:105)
> at
> org.apache.servicemix.common.AsyncBaseLifeCycle.doProcess(AsyncBaseLifeCycle.java:490)
> at
> org.apache.servicemix.common.AsyncBaseLifeCycle.processExchange(AsyncBaseLifeCycle.java:464)
> at
> org.apache.servicemix.common.BaseLifeCycle.onMessageExchange(BaseLifeCycle.java:46)
> at
> org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.processInBound(DeliveryChannelImpl.java:610)
> at
> org.apache.servicemix.jbi.nmr.flow.AbstractFlow.doRouting(AbstractFlow.java:174)
> at
> org.apache.servicemix.jbi.nmr.flow.seda.SedaFlow.doRouting(SedaFlow.java:176)
> at
> org.apache.servicemix.jbi.nmr.flow.seda.SedaQueue$1.run(SedaQueue.java:134)
> at
> edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:665)
> at
> edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:690)
> at java.lang.Thread.run(Thread.java:595)
> ERROR - JmsComponent - Error setting
> exchange status to ERROR
> javax.jbi.messaging.MessagingException: illegal call
> to send / sendSync
> at
> org.apache.servicemix.jbi.messaging.MessageExchangeImpl.handleSend(MessageExchangeImpl.java:571)
> at
> org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.doSend(DeliveryChannelImpl.java:350)
> at
> org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.send(DeliveryChannelImpl.java:397)
> at
> org.apache.servicemix.common.BaseLifeCycle.onMessageExchange(BaseLifeCycle.java:58)
> at
> org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.processInBound(DeliveryChannelImpl.java:610)
> at
> org.apache.servicemix.jbi.nmr.flow.AbstractFlow.doRouting(AbstractFlow.java:174)
> at
> org.apache.servicemix.jbi.nmr.flow.seda.SedaFlow.doRouting(SedaFlow.java:176)
> at
> org.apache.servicemix.jbi.nmr.flow.seda.SedaQueue$1.run(SedaQueue.java:134)
> at
> edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:665)
> at
> edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:690)
> at java.lang.Thread.run(Thread.java:595)
> and this is my configuration
> endpoint="HELLOJmsReceiver"
> targetService="hello:mailSender"
> role="consumer"
> destinationStyle="queue"
> jmsProviderDestinationName="jms/queue/hello"
> connectionFactory="#jmsFactory"
> defaultMep="http://www.w3.org/2004/08/wsdl/in-only"; />
> FYI: when you block SMX with in a debugger, it seems to
> work fine.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorr
Re: Start a 4.1.1 release ?
I guess we can wait a bit to upgrade to the upcoming xbean 2.8 which fixes the xml schema generation -- they can not be used :( atm On 12/19/06, Guillaume Nodet <[EMAIL PROTECTED]> wrote: I'd like to release jencks 2.0 and servicemix 3.1, but I'm a little reluctant to do so because both make heavy use of the ActiveMQ resource adapter, which is unfortunately quite unreliable in 4.1.0, mainly because of the following bug http://issues.apache.org/activemq/browse/AMQ-1078. Could we release a 4.1.1 ? -- Cheers, Guillaume Nodet -- Cheers, Guillaume Nodet
[jira] Resolved: (SM-755) The EIP pipeline should have another exchange target for faults
[ https://issues.apache.org/activemq/browse/SM-755?page=all ] Guillaume Nodet resolved SM-755. Fix Version/s: 3.1 Resolution: Fixed Assignee: Guillaume Nodet Author: gnodet Date: Tue Dec 19 03:10:02 2006 New Revision: 488633 URL: http://svn.apache.org/viewvc?view=rev&rev=488633 Log: SM-775: The EIP pipeline should have another target for faults Modified: incubator/servicemix/trunk/deployables/serviceengines/servicemix-eip/src/main/java/org/apache/servicemix/eip/patterns/Pipeline.java incubator/servicemix/trunk/deployables/serviceengines/servicemix-eip/src/test/java/org/apache/servicemix/eip/PipelineTest.java > The EIP pipeline should have another exchange target for faults > --- > > Key: SM-755 > URL: https://issues.apache.org/activemq/browse/SM-755 > Project: ServiceMix > Issue Type: Improvement > Components: servicemix-eip >Reporter: Guillaume Nodet > Assigned To: Guillaume Nodet > Fix For: 3.1 > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SM-782) Re-deploy with In-Only Mep
[ https://issues.apache.org/activemq/browse/SM-782?page=all ]
Grégoire A. updated SM-782:
---
Attachment: MultiplexingConsumerProcessor.java.diff
It is my first patch for SMX.
tell me how to improve it.
I would be interessed to become a committer,
do you need some help (doc, patch, improve) ?
> Re-deploy with In-Only Mep
> --
>
> Key: SM-782
> URL: https://issues.apache.org/activemq/browse/SM-782
> Project: ServiceMix
> Issue Type: Bug
> Components: servicemix-jms
>Affects Versions: 3.1
> Environment: Linux x86/ Java (1.5.0_09)
>Reporter: Grégoire A.
> Attachments: MultiplexingConsumerProcessor.java.diff
>
>
> First deploy JMS-endpoint with target InOnly Service like Mail.
> Run several call.
> redeploy the same JMS-endpoint without modification.
> And recall the service, u should have this exception.
> It could be a safe thread pb, this error is launched in 75% of the cases.
> I think the context of the message cannot be refind.
> ERROR - JmsComponent - Error
> processing exchange InOnly[
> id: ID:jjp-34393-1166462101789-6:229
> status: Done
> role: consumer
> service: {urn:fr.gouv.hello}mailSender
> endpoint: mailSender
> in: encoding="UTF-8"?> xmlns:ns1="http://tempuri.org/HashService/HashClass";
> xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/";
> xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/";
> xmlns:ZSI="http://www.zolera.com/schemas/ZSI/";
> xmlns:xsd="http://www.w3.org/2001/XMLSchema";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>Message
> Change dans BPEL 4 JMS Service
> MD5
> ]
> java.lang.NullPointerException
> at
> org.apache.servicemix.jms.multiplexing.MultiplexingConsumerProcessor.process(MultiplexingConsumerProcessor.java:105)
> at
> org.apache.servicemix.common.AsyncBaseLifeCycle.doProcess(AsyncBaseLifeCycle.java:490)
> at
> org.apache.servicemix.common.AsyncBaseLifeCycle.processExchange(AsyncBaseLifeCycle.java:464)
> at
> org.apache.servicemix.common.BaseLifeCycle.onMessageExchange(BaseLifeCycle.java:46)
> at
> org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.processInBound(DeliveryChannelImpl.java:610)
> at
> org.apache.servicemix.jbi.nmr.flow.AbstractFlow.doRouting(AbstractFlow.java:174)
> at
> org.apache.servicemix.jbi.nmr.flow.seda.SedaFlow.doRouting(SedaFlow.java:176)
> at
> org.apache.servicemix.jbi.nmr.flow.seda.SedaQueue$1.run(SedaQueue.java:134)
> at
> edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:665)
> at
> edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:690)
> at java.lang.Thread.run(Thread.java:595)
> ERROR - JmsComponent - Error setting
> exchange status to ERROR
> javax.jbi.messaging.MessagingException: illegal call
> to send / sendSync
> at
> org.apache.servicemix.jbi.messaging.MessageExchangeImpl.handleSend(MessageExchangeImpl.java:571)
> at
> org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.doSend(DeliveryChannelImpl.java:350)
> at
> org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.send(DeliveryChannelImpl.java:397)
> at
> org.apache.servicemix.common.BaseLifeCycle.onMessageExchange(BaseLifeCycle.java:58)
> at
> org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.processInBound(DeliveryChannelImpl.java:610)
> at
> org.apache.servicemix.jbi.nmr.flow.AbstractFlow.doRouting(AbstractFlow.java:174)
> at
> org.apache.servicemix.jbi.nmr.flow.seda.SedaFlow.doRouting(SedaFlow.java:176)
> at
> org.apache.servicemix.jbi.nmr.flow.seda.SedaQueue$1.run(SedaQueue.java:134)
> at
> edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:665)
> at
> edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:690)
> at java.lang.Thread.run(Thread.java:595)
> and this is my configuration
> endpoint="HELLOJmsReceiver"
> targetService="hello:mailSender"
> role="consumer"
> destinationStyle="queue"
> jmsProviderDestinationName="jms/queue/hello"
> connectionFactory="#jmsFactory"
> defaultMep="http://www.w3.org/2004/08/wsdl/in-only"; />
> FYI: when you block SMX with in a debugger, it seems to
> work fine.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SM-784) No support for xml message encodings such as ISO-8859-1
No support for xml message encodings such as ISO-8859-1 --- Key: SM-784 URL: https://issues.apache.org/activemq/browse/SM-784 Project: ServiceMix Issue Type: Bug Components: servicemix-components, servicemix-core, servicemix-soap Affects Versions: 3.0.1 Environment: Windows XP SP2 (Swedish), JDK 1.5.0_9 Reporter: Anders Hammar Attachments: HttpISO88591Test.java, JmsISO88591Test.java Servicemix only supports UTF-8 encoding, due to hard coded values. Support for other encodings such as ISO-8859-1 is essential for countries such as the Scandinavian ones. Xml has good support for this, and defined encoding in xml messages should be honored. The experienced problem occurs when passing an xml message (not soap, no attachments) with encoding ISO-8859-1 defined, through servicemix. Problems have been located in at least smx-core, smx-components, and smx-soap. Attached are two test cases (one for http and one for jms) that shows this. Use them with the http component and the jms component respectively (they use test configuration existing within smx 3.0.1). Another problem (duplicated characters) is related to a bug in woodstox. See separate jira for that. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (AMQ-1105) Misuse of maxMessages on the ActivationSpec
Misuse of maxMessages on the ActivationSpec --- Key: AMQ-1105 URL: https://issues.apache.org/activemq/browse/AMQ-1105 Project: ActiveMQ Issue Type: Improvement Components: Connector Reporter: Guillaume Nodet It seems the maxMessages given to the connection when creating a connection consumer is usually used to allow a maximum number of messages to be dispatched for a single ServerSession run (so the WorkManager is not exhaust by ever lasting works ?). Currently, this parameter is used to indicate the destination prefetch size. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (AMQ-1105) Misuse of maxMessages when creating a connection consumer
[ https://issues.apache.org/activemq/browse/AMQ-1105?page=all ] Guillaume Nodet updated AMQ-1105: - Summary: Misuse of maxMessages when creating a connection consumer (was: Misuse of maxMessages on the ActivationSpec) > Misuse of maxMessages when creating a connection consumer > - > > Key: AMQ-1105 > URL: https://issues.apache.org/activemq/browse/AMQ-1105 > Project: ActiveMQ > Issue Type: Improvement > Components: Connector >Reporter: Guillaume Nodet > > It seems the maxMessages given to the connection when creating a connection > consumer > is usually used to allow a maximum number of messages to be dispatched for a > single ServerSession > run (so the WorkManager is not exhaust by ever lasting works ?). > Currently, this parameter is used to indicate the destination prefetch size. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (AMQ-1104) The resource adapter should pool sessions
The resource adapter should pool sessions - Key: AMQ-1104 URL: https://issues.apache.org/activemq/browse/AMQ-1104 Project: ActiveMQ Issue Type: Improvement Components: Connector Reporter: Guillaume Nodet Connections are always put back to a clean state after use. This has the unfortunate effect that sending a JMS message when using JCA outbound needs at least three roundtrip to the broker, which is damn slow ! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (AMQ-1103) Prefetch size < 0 should throw an exception somewhere or be defaulted, as messages are not dispatched anymore
Prefetch size < 0 should throw an exception somewhere or be defaulted, as messages are not dispatched anymore - Key: AMQ-1103 URL: https://issues.apache.org/activemq/browse/AMQ-1103 Project: ActiveMQ Issue Type: Bug Affects Versions: 4.1.0 Reporter: Guillaume Nodet -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Start a 4.1.1 release ?
sounds a good idea! +1 On 19 Dec 2006, at 09:42, Guillaume Nodet wrote: I'd like to release jencks 2.0 and servicemix 3.1, but I'm a little reluctant to do so because both make heavy use of the ActiveMQ resource adapter, which is unfortunately quite unreliable in 4.1.0, mainly because of the following bug http://issues.apache.org/activemq/browse/AMQ-1078. Could we release a 4.1.1 ? -- Cheers, Guillaume Nodet
Start a 4.1.1 release ?
I'd like to release jencks 2.0 and servicemix 3.1, but I'm a little reluctant to do so because both make heavy use of the ActiveMQ resource adapter, which is unfortunately quite unreliable in 4.1.0, mainly because of the following bug http://issues.apache.org/activemq/browse/AMQ-1078. Could we release a 4.1.1 ? -- Cheers, Guillaume Nodet
Re: [VOTE] 2.0-M1 Release
+1 Matt Hogstrom wrote: All, I have prepared 2.0-M1 for release. Of course all the hard work was done by the lot of y'all :) I have tested DayTrader 2.0-SNAPSHOT on this build and I'm satisfied with the results. All modes of operation functioned well (SLSB, Direct, EJB and JPA). I toned all the logs down to error to not overwhelm the users with lots of diagnostic output (they can always turn it up later if they want.) The uploads are taking forever so you'll see some piece parts trickle in. For the review I expect you'll want to focus on http://people.apache.org/~hogstrom/2.0-M1 as this contains the assemblies for your review and testing. I've included both Tomcat and Jetty as well as the minimal and j5ee assemblies. The source code is also there. Note that if you are planning on building you'll need to obtain the openejb-2.2-incubating jars to your local repo. The easiest way to do this is to modify the root pom and add a repository for David's home directory at http://people.apache.org/~dblevins/stage/. For SNAPSHOTs of certain plugins I have resolved these files to the most recent SNAPSHOT date / timestamp. I'm pulling a copy of these and will be putting them into our SVN for folks who may want to build in the future. I'm not too concerned about repeatability as this Milestone will be superseded at the end of January with the next version. The other MAven artifacts will be trickling onto people across my horribly slow home pipe and dropped into http://people.apache.org/~hogstrom/stage over the next few hours. Please review and cast your vote early. The faster we determine this build is good or if there is an issue the better. Thanks in advance for all your help in this effort. This vote will conclude at 0400 ET on Dec 21 (unless all you PMC members vote quicker :) If a respin is is necessary this vote will be suspended and a new one will start. Matt Hogstrom [EMAIL PROTECTED]
Re: Trunk runtime error GBeanInstanceState- deserializing GBeanState
Anita, Try this when you have some time. 1. Remove your .m2 2. "mvn install" from root. 3. cd to testsuite and run "mvn -N install" 4. cd to itests and run "mvn -N install" 5. cd to cxfPojoWS and run "mvn -o install" It's impossible to execute 5 with "-o" flag as the project needs to download cxf stuff from the remote repo. since you can't use the "-o" flag it will pick up the remote jar for geronimo-kernel. If you search all the sub directories after running 5, you will see 2 jars for geronimo-kernel, one built locally and one from the remote repo. Basically you are dead in the water. After this, you will have to replace the remote jar with the local jar and re-run "mvn install" to actually run the test. So basically "The only way to make sure that the local jars/cars are used is to do an offile build" is not possible. thanks, dims On 12/18/06, anita kulshreshtha <[EMAIL PROTECTED]> wrote: --- Davanum Srinivas <[EMAIL PROTECTED]> wrote: > Anita, > > Anyone who builds geronimo from scratch is likely to into into > problem. We can't really tell people they can't use the jars they > build themselves on their boxes and have to use the published > SNAPSHOT > jars. We do not tell people that they have to use the published jars. It is clear from this error that maven is still downloading jars from a remote repo instead of using the ones that were built locally. The only way to make sure that the local jars/cars are used is to do an offile build. Thanks Anita So i think we need to fix it. Just imagine that you are trying > to fix a bug in Geronimo kernel for shipping to your customer, but > the > code does not have a serial version uid and the compiled jar is hence > unusable...not a pretty picture. I don't think we have to "worry" > about compatibility especially as right now if 2 jars built from same > svn revision by 2 different people on different JDK's/JDK versions on > different boxes, you can't mix the jars. So there is no > "compatibility" right now :( > > Anyway my specific problem was because of lack of the UID in > GBeanOperation and i checked in a patch for it (487759). > > thanks, > dims > > On 12/16/06, anita kulshreshtha <[EMAIL PROTECTED]> wrote: > > Dims, Joe, and Prasad > > I wish I had seen this coming.. The compatibility of GBeanInfo > was > > broken for 4 days (Dec 10th - Dec 14), while we discussed whether > we > > should maintain this compatibility. In a perfect world it would not > > have mattered.. But sometimes Maven does not use locally built > > SNAPSHOTs in online build mode (some of the reasons for this are > > known). Once the SNAPSHOTs published during this time, are > overwritten, > > this problem should go way. At least that is my thinking... Please > > correct me if I am on wrong track. > > > > Thanks > > Anita > > > > --- Joe Bohn <[EMAIL PROTECTED]> wrote: > > > > > Prasad, > > > > > > I'm hitting this particular problem in trunk (but I have hit > similar > > > problems in 2.0-M1). I actually was trying to recreate the > problem > > > today in both trunk and 2.0-M1 ... after 4 builds on 2.0-M1 I > didn't > > > hit > > > the problem but I hit it with the first attempt on trunk. As I > > > mentioned, the second build attempt corrected the problem. > > > > > > Joe > > > > > > > > > Prasad Kashyap wrote: > > > > I was able to build G successfully on a RedHat machine. > > > > > > > > I started with a completely clean repo (rm -rf .m2/repository). > > > > > > > > I did an 'svn up' of my 2.0-M1 directory. I had done a fresh > > > checkout > > > > of these files last night. > > > > > > > > The entire tree built successfully with a > -Dmaven.test.skip=true. > > > > > > > > I verified that both jetty and tomcat binaries run fine. > > > > > > > > I used the console to successfully deploy jsp-examples app on > both > > > > binaries. > > > > > > > > Cheers > > > > Prasad > > > > > > > > On 12/15/06, Joe Bohn <[EMAIL PROTECTED]> wrote: > > > > > > > >> This might be the sporadic problem after all. I just rebuilt > > > again > > > >> without any changes (still rev 487523) and the problem doesn't > > > exist > > > >> with the new images. > > > >> > > > >> Here's what I did this time: > > > >> - mvn clean > > > >> - from my local repo remove o/a/g/modules, configs, > assemblies, > > > and > > > >> applications rather than removing the entire local repo. > > > >> - mvn -Dstage=bootstrap > > > >>- still failed in the geronimo-jetty6 SecurityTest (yes, I > know > > > I > > > >> should have skipped the tests but I wanted to see if the > > > failure/restart > > > >> was in any way related to the failures) > > > >> - mvn -Dstage=bootstrap -Dmaven.test.skip=true > > > -Dmaven.itest.skip=true > > > >> - mvn -Dstage=assemble -Dmaven.test.skip=true > > > -Dmaven.itest.skip=true > > > >> > > > >> Joe > > > >> > > > >> > > > >> > > > >> Joe Bohn wrote: > > > >> > This is happening in trunk rev 487523. I'm not sure it is > the > > > same > > > >> > problem I reported earlier ..
