users@glassfish.java.net

Re: Queueing jobs for processing in their own thread/transaction?

From: Dobes Vandermeer <dobesv_at_gmail.com>
Date: Tue, 10 Feb 2009 14:40:35 -0800 (PST)

Yeah, it's a bit disappointing. Hopefully the situation will improve, but
for now we just have to work around the issues or use another container,
right? I don't think I have the ability to fix the resource adapters myself
right now.


Brian Repko wrote:
>
>
> Its not the OpenMQ product. Its the resource adapters.
> jmsra, genericjmsra and sun-jms-adapter - none of them worked for us.
>
> I have a hard time believing that getting Sailfin working was a higher
> priority than a production ready JMS configuration.
>
>
> ----- Original message -----
> From: "Dobes Vandermeer" <dobesv_at_gmail.com>
> To: users_at_glassfish.dev.java.net
> Date: Tue, 10 Feb 2009 13:57:54 -0800 (PST)
> Subject: Re: Queueing jobs for processing in their own thread/transaction?
>
>
>
>
> glassfish-2 wrote:
>>
>>> I thought I could use JMS for this but the JMS
>>> implementation with glassfish
>>> v2ur2 is too buggy and I can't upgrade to 2.1 due to
>>> some weird classpath
>>> issues in 2.1 I couldn't resolve.
>>
>> What issues are you having with JMS? Seems to me that JMS with a
>> constrained MDB (i.e. container can not make more than, say, 5 instances)
>> would work well at letting you control resource uses. And this doesn't
>> sound like a particularly exotic use of JMS.
>>
>> So I'm curious what problems you're encountering with it.
>>
>
> This is the sort of thing JMS would be perfect for, if it worked. I was
> getting a lot of errors in the logs - for each message delivered it would
> print an error every once in a while (maybe 30 seconds?) and as more
> messages were sent the volume of errors increased.
>
> Generally, it's just a flaky unfinished product at the stage I was using
> it,
> for example when I first set up the Queue I got this:
>
> MQJMSRA_MC2001: createConnection API used w/ username, password for
> Container Auth
>
> Apparently I had to delete the username and password properties from the
> queue in the admin panel. Just something that shows a lack of usability
> testing. Why not just treat an empty username/password the same as a null
> one?
>
> Anyway, the actual error I was getting is discussed in this thread, I
> believe (it's been a couple weeks so I've gotten foggy on the exact error
> text):
>
> http://forums.java.net/jive/thread.jspa?messageID=278700
>
> For me, the suggested workaround of changing the connection type to LOCAL
> did not solve the problem, things actually got worse, so I gave up on the
> JMS solution.
>
>
>
> --
> View this message in context:
> http://www.nabble.com/Queueing-jobs-for-processing-in-their-own-thread-transaction--tp21795170p21943493.html
> Sent from the java.net - glassfish users mailing list archive at
> Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>
>
>

-- 
View this message in context: http://www.nabble.com/Queueing-jobs-for-processing-in-their-own-thread-transaction--tp21795170p21944323.html
Sent from the java.net - glassfish users mailing list archive at Nabble.com.