February 2008 - esb-issues - Jboss List Archives

[JBoss JIRA] Created: (JBESB-1398) Restructure labs page

by Mark Little (JIRA)

Restructure labs page --------------------- Key: JBESB-1398 URL: http://jira.jboss.com/jira/browse/JBESB-1398 Project: JBoss ESB Issue Type: Task Security Level: Public (Everyone can see) Components: Documentation Affects Versions: 4.2.1 Reporter: Mark Little Assigned To: Mark Little Priority: Critical Fix For: 4.2.1 CP1 Bring more immediately useful links up front on the page. Most of the information users and developers want is there, but spread over quite a few pages. Would be nice to have the front page hit the 80/20 mark. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 2 months

1
2
0 / 0

[JBoss JIRA] Created: (JBESB-1439) RegistryFactory.createRegistry() not setting the factory singleton

by Tom Fennelly (JIRA)

RegistryFactory.createRegistry() not setting the factory singleton ------------------------------------------------------------------ Key: JBESB-1439 URL: http://jira.jboss.com/jira/browse/JBESB-1439 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: Rosetta Affects Versions: 4.2.1 Reporter: Tom Fennelly Priority: Minor Fix For: 4.3 Causing the Registry impl class to be reflectively loaded on every call. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 3 months

1
6
0 / 0

[JBoss JIRA] Created: (JBESB-1369) Bad action breaks ESB

by Martin Vecera (JIRA)

Bad action breaks ESB --------------------- Key: JBESB-1369 URL: http://jira.jboss.com/jira/browse/JBESB-1369 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: Rosetta Affects Versions: 4.2.1 Environment: server/oracle/deploy/jbossesb.sar/jbossesb-properties.xml in the 'core' section: <property name="org.jboss.soa.esb.message.default.uri" value="urn:jboss/esb/message/type/JAVA_SERIALIZED"/> Reporter: Martin Vecera In one of my tests I sent several messages (text or object - doesn't matter, they both carried String) to Queue/A. There was one service listening on this queue. I tried to use org.jboss.soa.esb.actions.Notifier with target NotifyQueue. This was impossible because my message carried String and the notifier expected byte[]. This caused an exception (see later) and the ESB started to show another warning (connection pool exhausted). I would expect it to return the thread to the pool after this exception. It is 100% reproducible. Just try simple helloworld quickstart with NotifyQueue and ESB set according to 'Environment' field. The exception (this is expected behavior): 16:28:42,044 INFO [JBoss4ESBDeployer] create esb service, Performance1.esb 16:28:42,069 INFO [QueueService] Queue[/queue/quickstart_helloworld_Request_esb] started, fullSize=200000, pageSize=2000, downCacheSize=2000 16:28:42,077 INFO [QueueService] Queue[/queue/quickstart_helloworld_Request_gw] started, fullSize=200000, pageSize=2000, downCacheSize=2000 16:28:42,259 ERROR [STDERR] Found log4j.properties: jar:file:/home/mvecera/work/jboss-soa-p.4.2.0.IR6/bin/run.jar!/log4j.properties 16:28:42,261 INFO [MessageCounterAction] jbosstest.beancount: null 16:28:42,261 INFO [MessageCounterAction] jbosstest.iterationcount: null 16:28:42,261 INFO [MessageCounterAction] jbosstest.threadcount: null 16:28:42,261 INFO [MessageCounterAction] jbosstest.nodeploy: null 16:28:42,261 INFO [MessageCounterAction] jbosstest.jndiurl: localhost:1099 16:28:42,261 INFO [MessageCounterAction] jbosstest.jndifactory: org.jnp.interfaces.NamingContextFactory 16:28:42,541 INFO [JDBCDataStore] Generated token 'authToken:6F7CA190-9CFD-11DC-AC8B-AA0F09643FB4' for user: 'jbossesb/JBoss ESB User' 16:28:42,667 INFO [QuartzScheduler] Scheduler DefaultQuartzScheduler_$_NON_CLUSTERED started. 16:28:54,478 ERROR [STDERR] Test was finished by processing 1 messages in 1 ms 16:28:54,483 INFO [STDOUT] ConsoleNotifier 2007/11/27 04:28:54.483<Hello World> 16:28:54,532 ERROR [NotificationList] Can't instantiate target <target class="NotifyQueues"> <queue jndiName="queue/D"/> </target> org.jboss.soa.esb.notification.NotificationException: Expected payload type for 'urn:jboss/esb/message/type/JAVA_SERIALIZED' is byte[]. Recieved 'java.lang.String'. at org.jboss.soa.esb.notification.NotifyJMS.sendNotification(NotifyJMS.java:276) at org.jboss.soa.esb.notification.NotificationList.notifyAll(NotificationList.java:164) at org.jboss.soa.esb.actions.Notifier.notifyOK(Notifier.java:93) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.soa.esb.listeners.message.ActionProcessorMethodInfo.processSuccess(ActionProcessorMethodInfo.java:154) at org.jboss.soa.esb.listeners.message.OverriddenActionLifecycleProcessor.processSuccess(OverriddenActionLifecycleProcessor.java:108) at org.jboss.soa.esb.listeners.message.ActionProcessingPipeline.notifySuccess(ActionProcessingPipeline.java:610) at org.jboss.soa.esb.listeners.message.ActionProcessingPipeline.process(ActionProcessingPipeline.java:384) at org.jboss.soa.esb.listeners.jca.JcaMessageAwareListener.process(JcaMessageAwareListener.java:156) at org.jboss.soa.esb.listeners.jca.JcaJMSInflowMessageProcessorAdapter.onMessage(JcaJMSInflowMessageProcessorAdapter.java:44) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.soa.esb.listeners.jca.BaseJcaInflow$1.invoke(BaseJcaInflow.java:205) at org.jboss.soa.esb.listeners.jca.EndpointProxy.delivery(EndpointProxy.java:242) at org.jboss.soa.esb.listeners.jca.EndpointProxy.invoke(EndpointProxy.java:145) at $Proxy76.onMessage(Unknown Source) at org.jboss.resource.adapter.jms.inflow.JmsServerSession.onMessage(JmsServerSession.java:178) at org.jboss.jms.client.container.ClientConsumer.callOnMessage(ClientConsumer.java:157) at org.jboss.jms.client.container.SessionAspect.handleRun(SessionAspect.java:801) at org.jboss.aop.advice.org.jboss.jms.client.container.SessionAspect14.invoke(SessionAspect14.java) at org.jboss.jms.client.delegate.ClientSessionDelegate$run_N8003352271541955702.invokeNext(ClientSessionDelegate$run_N8003352271541955702.java) at org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:170) at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:105) at org.jboss.jms.client.delegate.ClientSessionDelegate$run_N8003352271541955702.invokeNext(ClientSessionDelegate$run_N8003352271541955702.java) at org.jboss.jms.client.delegate.ClientSessionDelegate.run(ClientSessionDelegate.java) at org.jboss.jms.client.JBossSession.run(JBossSession.java:199) at org.jboss.resource.adapter.jms.inflow.JmsServerSession.run(JmsServerSession.java:237) at org.jboss.resource.work.WorkWrapper.execute(WorkWrapper.java:204) at org.jboss.util.threadpool.BasicTaskWrapper.run(BasicTaskWrapper.java:275) at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:743) at java.lang.Thread.run(Thread.java:595) The problem: 16:30:58,740 INFO [STDOUT] ConsoleNotifier 2007/11/27 04:30:58.740<Hello World> 16:30:58,741 INFO [JmsConnectionPool] The connection pool was exhausted. Waiting 1 second before trying again.. 16:30:58,766 INFO [STDOUT] ConsoleNotifier 2007/11/27 04:30:58.766<Hello World> 16:30:58,766 INFO [JmsConnectionPool] The connection pool was exhausted. Waiting 1 second before trying again.. 16:30:58,770 INFO [STDOUT] ConsoleNotifier 2007/11/27 04:30:58.770<Hello World> 16:30:58,770 INFO [JmsConnectionPool] The connection pool was exhausted. Waiting 1 second before trying again.. 16:30:58,807 INFO [STDOUT] ConsoleNotifier 2007/11/27 04:30:58.807<Hello World> 16:30:58,807 INFO [JmsConnectionPool] The connection pool was exhausted. Waiting 1 second before trying again.. 16:30:59,741 INFO [JmsConnectionPool] The connection pool was exhausted. Waiting 1 second before trying again.. 16:30:59,766 INFO [JmsConnectionPool] The connection pool was exhausted. Waiting 1 second before trying again.. 16:30:59,770 INFO [JmsConnectionPool] The connection pool was exhausted. Waiting 1 second before trying again.. 16:30:59,808 INFO [JmsConnectionPool] The connection pool was exhausted. Waiting 1 second before trying again.. 16:31:00,741 INFO [JmsConnectionPool] The connection pool was exhausted. Waiting 1 second before trying again.. 16:31:00,767 INFO [JmsConnectionPool] The connection pool was exhausted. Waiting 1 second before trying again.. 16:31:00,770 INFO [JmsConnectionPool] The connection pool was exhausted. Waiting 1 second before trying again.. 16:31:00,808 INFO [JmsConnectionPool] The connection pool was exhausted. Waiting 1 second before trying again.. 16:31:01,741 INFO [JmsConnectionPool] The connection pool was exhausted. Waiting 1 second before trying again.. 16:31:01,767 INFO [JmsConnectionPool] The connection pool was exhausted. Waiting 1 second before trying again.. 16:31:01,770 INFO [JmsConnectionPool] The connection pool was exhausted. Waiting 1 second before trying again.. 16:31:01,808 INFO [JmsConnectionPool] The connection pool was exhausted. Waiting 1 second before trying again.. 16:31:02,741 INFO [JmsConnectionPool] The connection pool was exhausted. Waiting 1 second before trying again.. 16:31:02,769 INFO [JmsConnectionPool] The connection pool was exhausted. Waiting 1 second before trying again.. Undeploying the service didn't fix the problem. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 3 months

5
10
0 / 0

[JBoss JIRA] Created: (JBESB-1568) FileGateways are not safe when used with more than one thread

by Jiri Pechanec (JIRA)

FileGateways are not safe when used with more than one thread ------------------------------------------------------------- Key: JBESB-1568 URL: http://jira.jboss.com/jira/browse/JBESB-1568 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: Transports Affects Versions: 4.2.1 CP1 Reporter: Jiri Pechanec Assigned To: Kevin Conner Priority: Critical Fix For: 4.2.1 CP2 See attached example. Unzip it in quickstarts dir and do only deploy. The QS will create 200 files in input dir and then will deploy the app. The app will process messages and notifie the console and JMS queue/A. The problem is that the numebr of processed messages is larger than the number of received. An example of output 12:03:28,188 INFO [STDOUT] ConsoleNotifier 2008/02/29 12:03:28.188<> 12:03:28,191 INFO [STDOUT] ConsoleNotifier 2008/02/29 12:03:28.191<Hello World In A File 10> 12:03:28,194 INFO [STDOUT] ConsoleNotifier 2008/02/29 12:03:28.194<Hello World In A File 94> 12:03:28,198 INFO [STDOUT] ConsoleNotifier 2008/02/29 12:03:28.198<Hello World In A File 37> 12:03:28,201 INFO [STDOUT] ConsoleNotifier 2008/02/29 12:03:28.201<Hello World In A File 150> 12:03:28,204 INFO [STDOUT] ConsoleNotifier 2008/02/29 12:03:28.204<> 12:03:28,208 INFO [STDOUT] ConsoleNotifier 2008/02/29 12:03:28.208<Hello World In A File 19> 12:03:28,211 INFO [STDOUT] ConsoleNotifier 2008/02/29 12:03:28.211<> The contains this messages 2008-02-29 12:03:28,434 DEBUG [org.jboss.soa.esb.util.FileUtil] Could not open input file for reading java.io.FileNotFoundException: /home/jpechane/pokus/GAAS/jboss-as/samples/quickstarts/helloworld_perfile_action/build/dirs/input/MyInput132.dat (No such file or directory) at java.io.FileInputStream.open(Native Method) at java.io.FileInputStream.<init>(FileInputStream.java:106) at org.jboss.soa.esb.util.FileUtil.copyFile(FileUtil.java:89) at org.jboss.soa.esb.util.FileUtil.renameTo(FileUtil.java:63) at org.jboss.soa.esb.listeners.gateway.FileGatewayListener.renameFile(FileGatewayListener.java:151) at org.jboss.soa.esb.listeners.gateway.AbstractFileGateway.setFileWorking(AbstractFileGateway.java:257) at org.jboss.soa.esb.listeners.gateway.AbstractFileGateway.onSchedule(AbstractFileGateway.java:147) at org.jboss.soa.esb.schedule.ScheduleProvider$ESBScheduledJob.execute(ScheduleProvider.java:217) at org.quartz.core.JobRunShell.run(JobRunShell.java:203) at org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:520) The issue is due to buggy FileUtil class. The expected processing is 1) Find a file with message 2) Copy the file and rename add .processing extension But if there are more threads then two can process the same file. The issue is that copying file returns true/false which is ignored in FileUtil.renameTo method. Delete old files also can fail and value is ignored. Thus the empty message is generated and processed by ESB. The FileGateway and FileUtils should be either revisited or documented as usable with only one trhead over one dir. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 3 months

3
13
0 / 0

[JBoss JIRA] Created: (JBESB-1327) Prepend leading slash programatically in JBossRulesRouter

by toby (JIRA)

Prepend leading slash programatically in JBossRulesRouter --------------------------------------------------------- Key: JBESB-1327 URL: http://jira.jboss.com/jira/browse/JBESB-1327 Project: JBoss ESB Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Content Based Routing Affects Versions: 4.2.1 Reporter: toby Priority: Trivial The getRules method in org.jboss.internal.soa.esb.services.routing.cbr.JBossRulesRouter.java automatically prepends a leading slash ("/") to the resource path (the ruleSet file path) however it may be more intuitive to prepend this only if there isnt already a slash at the start: ClassUtils.getResourceAsStream( rulesFile.charAt(0) == '/' ? rulesFile : "/" + rulesFile, JBossRulesRouter.class); -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 3 months

2
3
0 / 0

[JBoss JIRA] Created: (JBESB-1170) Unregister an EPR during bootstrapper shutdown does not work

by Burr Sutter (JIRA)

Unregister an EPR during bootstrapper shutdown does not work ------------------------------------------------------------ Key: JBESB-1170 URL: http://jira.jboss.com/jira/browse/JBESB-1170 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: Registry and Repository Affects Versions: 4.2.1 IR1 Reporter: Burr Sutter Assigned To: Mark Little Fix For: 4.2.1 Steps to reproduce: - Using the quickstart helloworld: ant run, 3 windows, 3 times - Review the number of EPRs for this service in your registry. You might use a UDDI GUI tool and you will see all 3 instances - Shutdown the bootstrapper via Ctrl-C, you'll see the Stopping JBossESB... message - however, those EPRs were not removed from UDDI -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 3 months

3
5
0 / 0

[JBoss JIRA] Created: (JBESB-454) Allow no inputSuffix on the FileGateway

by Kurt Stam (JIRA)

Allow no inputSuffix on the FileGateway --------------------------------------- Key: JBESB-454 URL: http://jira.jboss.com/jira/browse/JBESB-454 Project: JBoss ESB Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: 4.0 Environment: any Reporter: Kurt Stam Assigned To: Mark Little Make the suffix on input Files optional so that it simply picks up all the files in the directory. Check to see that in this case the output directory is not the same as the input directory. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 3 months

3
10
0 / 0

[JBoss JIRA] Created: (JBESB-1344) Not all gateways are using ServiceInvoker

by Jiri Pechanec (JIRA)

Not all gateways are using ServiceInvoker ----------------------------------------- Key: JBESB-1344 URL: http://jira.jboss.com/jira/browse/JBESB-1344 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: Adapters, Rosetta Affects Versions: 4.2.1 Reporter: Jiri Pechanec Priority: Critical Few gateways do not use Service Invoker. It means that they do not provide load balancing facility right now. This needs to be documented and fixed later. The guilty gateways are JmsGatewayListener.java HibernateInterceptor.java SqlTableGatewayListener.java -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 3 months

4
7
0 / 0

[JBoss JIRA] Created: (JBESB-1110) Need a two-servers-on-one-machine quickstart

by Tom Cunningham (JIRA)

Need a two-servers-on-one-machine quickstart -------------------------------------------- Key: JBESB-1110 URL: http://jira.jboss.com/jira/browse/JBESB-1110 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: Examples Affects Versions: 4.2 Reporter: Tom Cunningham Assigned To: Tom Cunningham We need a quickstart that involves sending messages from one ESB on a single machine to another. Such a quickstart would demonstrate the servicebindings capabilities and other issues with running multiple ESB's on the same machine. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 3 months

3
6
0 / 0

[JBoss JIRA] Created: (JBESB-1555) Investigate ServiceInvoker/policy behaviour

by Kevin Conner (JIRA)

Investigate ServiceInvoker/policy behaviour ------------------------------------------- Key: JBESB-1555 URL: http://jira.jboss.com/jira/browse/JBESB-1555 Project: JBoss ESB Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 4.2.1 CP1 Reporter: Kevin Conner Fix For: 4.2.1 CP2, 4.3 >From Noel. Using the JBESB 4.2.1.GA.CP1, I'm pretty sure that there's an issue in the load balancing behaviour. I've got a very simple use case with a service deployed into 2 nodes and sending 2 messages only. With a debugger, I can see that the two EPR are used by the ServiceInvoker and that the RoundRobin Policy that I've set is used to choose alternatively each one. However, I can see that the same JMS connection properties are reused (by JMSCourier) instead of having the properties extracted from the second EPR. Is there a way for you to check this ? ------------------------------------------------ I forgot to mention that I'm sending messages to esb services from a standalone JSE java application with the ServiceInvoker. Going further, I can see that the EPR's <wsa:address .../> value is not used to initialise the JMS connection. <ReferenceProperties /> are used instead. This problem happens when the jndi-url is not setup for your esb service (because you want to use the default value defined for your esb node in the jbossesb.sar/jbossesb-properties.xml). Then you have two ways to fix this : - when declaring the EPR, reuse the wsa:address values when nothing is defined for the provider (JMS) - when the service invoker is creating the JMS connection to send the message, use the <wsa:address if <ReferenceProperties is not defined (at least for the JNDI-URL part -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 3 months

4
11
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

esb-issues February 2008