Re: Configuring Quartz under TomEE

[Ihsan Ecemis]

No, we did not try using a Custom Resource and it is not clear to me how to 
solve our problem with this.  Could you please provide some more detail?  Thank 
you.


> On Dec 20, 2019, at 08:23, Richard Monson-Haefel  
> wrote:
> 
> You probably tried this but I was going to suggest a Custom Resource.
> http://tomee.apache.org/application-resources.html
> 
> On Thu, Dec 19, 2019 at 10:13 PM Ihsan Ecemis  wrote:
> 
>> 
>> Hello Everyone,
>> 
>> We would like to store Quartz scheduling information within a relational
>> database. We tried different configuration options to use our own
>> properties file instead of TomEE's default, but could not get it to work.
>> 
>> Here are the things we tried:
>> 
>> (1) We defined the system property 'org.quartz.properties', e.g. did
>> "-Dorg.quartz.properties=/tmp/quartz.properties".
>> (2) Since TomEE shades org.quartz, we also tried
>> "-Dorg.apache.openejb.quartz.properties=/tmp/quartz.properties".
>> (3) We also tried configuring this via web.xml file by adding:
>> 
>>  
>>quartz:config-file
>>/tmp/quartz.properties
>>  
>> 
>> 
>> In all these cases, even though we set org.quartz.jobStore.class =
>> org.quartz.impl.jdbcjobstore.JobStoreTX (or
>> org.apache.openejb.quartz.jobStore.class =
>> org.apache.openejb.quartz.impl.jdbcjobstore.JobStoreTX) and adjust all
>> parameters as documented at Quartz User Guide,  TomEE is initializing
>> RAMJobStore instead of JobStoreTX.  Also, there is no indication in the
>> logs that Quartz is opening our properties file.
>> 
>> How can we configure Quartz under TomEE?
>> 
>> Any help would be greatly appreaciated.
>> 
>> Thanks,
>> 
>> Ihsan.
> 
> 
> 
> -- 
> Richard Monson-Haefel
> https://twitter.com/rmonson
> https://www.linkedin.com/in/monsonhaefel/

Re: Configuring Quartz under TomEE

[Ihsan Ecemis]

Thanks for the suggestion Jon.  We added org.quartz-scheduler as a dependency 
to our project and configured it in web.xml.  With that, we could get a second 
Scheduler started and use JobStoreTX.

However, our code schedules task using javax.ejb.Schedule annotation, e.g.: 

@Schedule(minute = "*", hour = "*")
public void schedulerTest() {
LOGGER.info("Entered schedulerTest");
}

and this still uses the Scheduler started by TomEE and not the one we want. 

AFAIK,  @Schedule does not have any parameter to specify which Scheduler to 
use.  

How can we make this to use the Scheduler we want? 


> On Dec 20, 2019, at 04:23, Jonathan Gallimore  
> wrote:
> 
> TomEE uses Quartz internally to schedule EJB timers etc - the reason for
> shading it is to avoid it conflicting with Quartz packaged in your
> application. So theoretically, you should be able to package Quartz in your
> application, and use it per its own documentation. If you have a code
> sample with your issue that you can provide us with, we'd be happy to take
> a look.
> 
> Cheers
> 
> Jon
> 
> On Fri, Dec 20, 2019 at 4:13 AM Ihsan Ecemis  wrote:
> 
>> 
>> Hello Everyone,
>> 
>> We would like to store Quartz scheduling information within a relational
>> database. We tried different configuration options to use our own
>> properties file instead of TomEE's default, but could not get it to work.
>> 
>> Here are the things we tried:
>> 
>> (1) We defined the system property 'org.quartz.properties', e.g. did
>> "-Dorg.quartz.properties=/tmp/quartz.properties".
>> (2) Since TomEE shades org.quartz, we also tried
>> "-Dorg.apache.openejb.quartz.properties=/tmp/quartz.properties".
>> (3) We also tried configuring this via web.xml file by adding:
>> 
>>  
>>quartz:config-file
>>/tmp/quartz.properties
>>  
>> 
>> 
>> In all these cases, even though we set org.quartz.jobStore.class =
>> org.quartz.impl.jdbcjobstore.JobStoreTX (or
>> org.apache.openejb.quartz.jobStore.class =
>> org.apache.openejb.quartz.impl.jdbcjobstore.JobStoreTX) and adjust all
>> parameters as documented at Quartz User Guide,  TomEE is initializing
>> RAMJobStore instead of JobStoreTX.  Also, there is no indication in the
>> logs that Quartz is opening our properties file.
>> 
>> How can we configure Quartz under TomEE?
>> 
>> Any help would be greatly appreaciated.
>> 
>> Thanks,
>> 
>> Ihsan.

Configuring Quartz under TomEE

[Ihsan Ecemis]

Hello Everyone,

We would like to store Quartz scheduling information within a relational 
database. We tried different configuration options to use our own properties 
file instead of TomEE's default, but could not get it to work.

Here are the things we tried:

(1) We defined the system property 'org.quartz.properties', e.g. did 
"-Dorg.quartz.properties=/tmp/quartz.properties".
(2) Since TomEE shades org.quartz, we also tried 
"-Dorg.apache.openejb.quartz.properties=/tmp/quartz.properties".
(3) We also tried configuring this via web.xml file by adding:

  
quartz:config-file
/tmp/quartz.properties
  


In all these cases, even though we set org.quartz.jobStore.class = 
org.quartz.impl.jdbcjobstore.JobStoreTX (or 
org.apache.openejb.quartz.jobStore.class = 
org.apache.openejb.quartz.impl.jdbcjobstore.JobStoreTX) and adjust all 
parameters as documented at Quartz User Guide,  TomEE is initializing 
RAMJobStore instead of JobStoreTX.  Also, there is no indication in the logs 
that Quartz is opening our properties file.

How can we configure Quartz under TomEE? 

Any help would be greatly appreaciated.

Thanks,

Ihsan.

Re: Problem with MessageConsumers under TomEE 8.0.0

[Ihsan Ecemis]

Sorry I just had time to make these experiments.

Having the following (setting transacted = false) did not fix the problem if we 
do not use try-with-resources:

final Session session = connection.createSession(false, 
Session.AUTO_ACKNOWLEDGE);


On the other hand, when we added transactionSupport=none to resources.xml, we 
could dequeue only 1 message, which is weird  (at each server restart, we 
dequeue 1 message even though there are more message in the queue.  Reverting 
the code back to try-with-resources  makes the server dequeue all the messages)


Hope that would help you guys find out where the problem is.



> On Oct 1, 2019, at 16:42, Jonathan S. Fisher  wrote:
> 
> Just curious, try this:
> 
> final Session session = connection.createSession(false,
> Session.AUTO_ACKNOWLEDGE);
> 
> and/or try this:
> 
> 
>ResourceAdapter  = MyJmsResourceAdapter
> transactionSupport=none
>
> 
> 
> 
> 
> On Mon, Sep 30, 2019 at 8:53 PM Ihsan Ecemis  wrote:
> 
>> 
>> Thanks for digging into this Jon  (and pointing my attention toward that
>> other paragraph in the Javadoc)
>> 
>> And I highly appreciated the try-with-resources workaround.
>> 
>> 
>>> On Sep 30, 2019, at 17:11, Jonathan Gallimore <
>> jonathan.gallim...@gmail.com> wrote:
>>> 
>>>> Is this a bug with TomEE 8.0.0?   Because Connection.close()’s Javadoc
>>> states the following:  There is no need to close the sessions, producers,
>>> and consumers of a closed connection.
>>> 
>>>> Here is the link:
>>> https://docs.oracle.com/javaee/7/api/javax/jms/Connection.html#close-- <
>>> https://docs.oracle.com/javaee/7/api/javax/jms/Connection.html#close-->
>>> 
>>> Good question. The changes in this area between 8.0.0-M3 and 8.0.0, are,
>>> you'll be unsurprised to find out, around transaction handling. We need
>> to
>>> dig in a bit further.
>>> 
>>> The Javadoc also states this: "Closing a connection causes any of its
>>> sessions' transactions in progress to be rolled back. In the case where a
>>> session's work is coordinated by an external transaction manager, a
>>> session's commit and rollback methods are not used and the result of a
>>> closed session's work is determined later by the transaction manager.
>>> Closing a connection does NOT force an acknowledgment of
>>> client-acknowledged sessions."
>>> 
>>> A lot of this describes standalone usage, as opposed to usage in an
>>> application server. The Connection object should actually be a proxy, and
>>> calling close() shouldn't actually do anything. The sendMessage() method
>> on
>>> the CustomJmsService bean is transactional, and the connection should be
>>> returned back to the pool once the method completes and the transaction
>> is
>>> committed.
>>> 
>>> Thank you for the sample code, we should be able to debug through and see
>>> what's going on. I should be able to do this over the next day - I'll
>> post
>>> my steps here in case you want to dig in and have a go yourself.
>>> 
>>> Jon
>>> 
>>> On Mon, Sep 30, 2019 at 6:32 PM Ihsan Ecemis  wrote:
>>> 
>>>> 
>>>> Thank you very much for your suggestion Jon,  adding
>>>> connection.createSession(), session.createProducer(), and
>>>> session.createConsumer() in the try-with-resources block  make things
>> work
>>>> again!
>>>> 
>>>> 
>>>> Is this a bug with TomEE 8.0.0?   Because Connection.close()’s Javadoc
>>>> states the following:  There is no need to close the sessions,
>> producers,
>>>> and consumers of a closed connection.
>>>> 
>>>> Here is the link:
>>>> https://docs.oracle.com/javaee/7/api/javax/jms/Connection.html#close--
>> <
>>>> https://docs.oracle.com/javaee/7/api/javax/jms/Connection.html#close-->
>>>> 
>>>> 
>>>> And our original code, that did not close/auto-close Session,
>>>> MessageProducer, and MessageConsumer objects worked fine since at least
>>>> TomEE 7.0.2  (our git history shows that we had such a piece of code
>>>> implemented in March 2017)
>>>> 
>>>> 
>>>> 
>>>>> On Sep 30, 2019, at 09:14, Jonathan Gallimore <
>>>> jonathan.gallim...@gmail.com> wrote:
>>>>> 
>>>>> Hi,
>>>>> 
>>>>> I'm wondering if this is because your send method

Re: Problem with MessageConsumers under TomEE 8.0.0

[Ihsan Ecemis]

Thanks for digging into this Jon  (and pointing my attention toward that other 
paragraph in the Javadoc) 

And I highly appreciated the try-with-resources workaround.


> On Sep 30, 2019, at 17:11, Jonathan Gallimore  
> wrote:
> 
>> Is this a bug with TomEE 8.0.0?   Because Connection.close()’s Javadoc
> states the following:  There is no need to close the sessions, producers,
> and consumers of a closed connection.
> 
>> Here is the link:
> https://docs.oracle.com/javaee/7/api/javax/jms/Connection.html#close-- <
> https://docs.oracle.com/javaee/7/api/javax/jms/Connection.html#close-->
> 
> Good question. The changes in this area between 8.0.0-M3 and 8.0.0, are,
> you'll be unsurprised to find out, around transaction handling. We need to
> dig in a bit further.
> 
> The Javadoc also states this: "Closing a connection causes any of its
> sessions' transactions in progress to be rolled back. In the case where a
> session's work is coordinated by an external transaction manager, a
> session's commit and rollback methods are not used and the result of a
> closed session's work is determined later by the transaction manager.
> Closing a connection does NOT force an acknowledgment of
> client-acknowledged sessions."
> 
> A lot of this describes standalone usage, as opposed to usage in an
> application server. The Connection object should actually be a proxy, and
> calling close() shouldn't actually do anything. The sendMessage() method on
> the CustomJmsService bean is transactional, and the connection should be
> returned back to the pool once the method completes and the transaction is
> committed.
> 
> Thank you for the sample code, we should be able to debug through and see
> what's going on. I should be able to do this over the next day - I'll post
> my steps here in case you want to dig in and have a go yourself.
> 
> Jon
> 
> On Mon, Sep 30, 2019 at 6:32 PM Ihsan Ecemis  wrote:
> 
>> 
>> Thank you very much for your suggestion Jon,  adding
>> connection.createSession(), session.createProducer(), and
>> session.createConsumer() in the try-with-resources block  make things work
>> again!
>> 
>> 
>> Is this a bug with TomEE 8.0.0?   Because Connection.close()’s Javadoc
>> states the following:  There is no need to close the sessions, producers,
>> and consumers of a closed connection.
>> 
>> Here is the link:
>> https://docs.oracle.com/javaee/7/api/javax/jms/Connection.html#close-- <
>> https://docs.oracle.com/javaee/7/api/javax/jms/Connection.html#close-->
>> 
>> 
>> And our original code, that did not close/auto-close Session,
>> MessageProducer, and MessageConsumer objects worked fine since at least
>> TomEE 7.0.2  (our git history shows that we had such a piece of code
>> implemented in March 2017)
>> 
>> 
>> 
>>> On Sep 30, 2019, at 09:14, Jonathan Gallimore <
>> jonathan.gallim...@gmail.com> wrote:
>>> 
>>> Hi,
>>> 
>>> I'm wondering if this is because your send method isn't closing the
>>> producer and the session? I did try your code and I saw the issue. I
>> turned
>>> it into an example, and added an Arquillian test:
>>> https://github.com/apache/tomee/pull/578
>>> 
>>> Note that I added the session, producer and consumer into the
>>> try-with-resources block so they are auto-closed at the end of the
>> method.
>>> 
>>> Can you take a look and let me know what you think?
>>> 
>>> Jon
>>> 
>>> On Fri, Sep 27, 2019 at 6:05 PM Ihsan Ecemis  wrote:
>>> 
>>>> 
>>>> Hello Everyone,
>>>> 
>>>> We recently upgraded our staging environment from TomEE 8.0.0-M3 to
>> 8.0.0
>>>> and things started to break.
>>>> 
>>>> After some troubleshooting, we realized that we cannot dequeue JMS
>>>> messages from our ActiveMQ server using MessageConsumers.
>>>> 
>>>> 
>>>> We dequeue messages in 2 different ways:  We use MessageDriven beans for
>>>> most of our queues.  But with some others, we periodically poll by
>> creating
>>>> a MessageConsumer (please see the code below for that second case)
>>>> 
>>>> MessageDriven beans work without any problems but we cannot receive any
>>>> messages via MessageConsumers.  That same backend code is working fine
>> with
>>>> 8.0.0-M3.
>>>> 
>>>> 
>>>> We tested this with different versions of ActiveMQ server (5.15.6,
>> 5.15.9,
>>

Re: Problem with MessageConsumers under TomEE 8.0.0

[Ihsan Ecemis]

Hi Jonathan,

We do not have a tomee.xml file, we use resources.xml file instead.  I pasted 
its contents below.

BTW, my previous redacted code snippet omitted the following 2 lines from the 
CustomJmsService class:

@Resource(name = "MyJmsConnectionFactory")
private ConnectionFactory connectionFactory;

(in case you wonder where connectionFactory is coming from)

Let me know if you see any problems with our resource configuration.

Thank you,

Ihsan.






jdbcDriver   = org.postgresql.Driver
jdbcUrl  = 
jdbc:postgresql://${database_hostname}:${database_port}/${database_name}${jdbc_ssl_flag}
userName = ${database_username}
password = ${database_password}



# Connect to the external ActiveMQ broker running on localhost:61616
BrokerXmlConfig  =
ServerUrl=  nio://localhost:61616

 

ResourceAdapter  = MyJmsResourceAdapter



ResourceAdapter  = MyJmsResourceAdapter









> On Sep 30, 2019, at 13:08, Jonathan S. Fisher  wrote:
> 
> Also, can you post your tomee.xml?
> 
> On Mon, Sep 30, 2019 at 8:14 AM Jonathan Gallimore <
> jonathan.gallim...@gmail.com> wrote:
> 
>> Hi,
>> 
>> I'm wondering if this is because your send method isn't closing the
>> producer and the session? I did try your code and I saw the issue. I turned
>> it into an example, and added an Arquillian test:
>> https://github.com/apache/tomee/pull/578
>> 
>> Note that I added the session, producer and consumer into the
>> try-with-resources block so they are auto-closed at the end of the method.
>> 
>> Can you take a look and let me know what you think?
>> 
>> Jon
>> 
>> On Fri, Sep 27, 2019 at 6:05 PM Ihsan Ecemis  wrote:
>> 
>>> 
>>> Hello Everyone,
>>> 
>>> We recently upgraded our staging environment from TomEE 8.0.0-M3 to 8.0.0
>>> and things started to break.
>>> 
>>> After some troubleshooting, we realized that we cannot dequeue JMS
>>> messages from our ActiveMQ server using MessageConsumers.
>>> 
>>> 
>>> We dequeue messages in 2 different ways:  We use MessageDriven beans for
>>> most of our queues.  But with some others, we periodically poll by
>> creating
>>> a MessageConsumer (please see the code below for that second case)
>>> 
>>> MessageDriven beans work without any problems but we cannot receive any
>>> messages via MessageConsumers.  That same backend code is working fine
>> with
>>> 8.0.0-M3.
>>> 
>>> 
>>> We tested this with different versions of ActiveMQ server (5.15.6,
>> 5.15.9,
>>> 5.15.10) but TomEE  8.0.0 did not work with any of them.
>>> 
>>> 
>>> Below is redacted code snippets showing where we have the problem.
>>> 
>>> Any help will be greatly appreciated.   Please let me know if you have
>> any
>>> questions about our setup.
>>> 
>>> Thanks,
>>> 
>>> Ihsan.
>>> 
>>> 
>>> 
>>> @Stateless
>>> public class LogService {
>>> 
>>>@EJB
>>>private CustomJmsService customJmsService;
>>> 
>>>@javax.ejb.Schedule(second = "*/30", minute = "*", hour = "*")
>>>public void pollLogQueue() throws Exception {
>>>final TextMessage logMessage =
>>> customJmsService.receiveLogMessage(1000);
>>>if (logMessage != null) {
>>>persistLogMessages(logMessages);
>>>}
>>>}
>>> }
>>> 
>>> @Stateless
>>> public class CustomJmsService {
>>> 
>>>@Resource(name = "logQueue")
>>>private Queue logQueue;
>>> 
>>>public void sendLogMessage(final LogMessage message) {
>>>sendMessage(logQueue, message);
>>>}
>>> 
>>>private void sendMessage(final Queue queue, final CustomJmsMessage
>>> message) {
>>>try (final Connection connection =
>>> connectionFactory.createConnection()) {
>>>connection.start();
>>> 
>>>final Session session = connection.createSession(true,
>>> Session.AUTO_ACKNOWLEDGE);
>>>final MessageProducer producer =
>> session.createProducer(queue);
>>>final String serializedMessage =
>>> CustomJsonProvider.toJson(message);
>>>final Message jmsMessage =
>>> session.createTextM

Re: Problem with MessageConsumers under TomEE 8.0.0

[Ihsan Ecemis]

Thank you very much for your suggestion Jon,  adding 
connection.createSession(), session.createProducer(), and 
session.createConsumer() in the try-with-resources block  make things work 
again!


Is this a bug with TomEE 8.0.0?   Because Connection.close()’s Javadoc states 
the following:  There is no need to close the sessions, producers, and 
consumers of a closed connection.

Here is the link:  
https://docs.oracle.com/javaee/7/api/javax/jms/Connection.html#close-- 
<https://docs.oracle.com/javaee/7/api/javax/jms/Connection.html#close-->


And our original code, that did not close/auto-close Session, MessageProducer, 
and MessageConsumer objects worked fine since at least TomEE 7.0.2  (our git 
history shows that we had such a piece of code implemented in March 2017)



> On Sep 30, 2019, at 09:14, Jonathan Gallimore  
> wrote:
> 
> Hi,
> 
> I'm wondering if this is because your send method isn't closing the
> producer and the session? I did try your code and I saw the issue. I turned
> it into an example, and added an Arquillian test:
> https://github.com/apache/tomee/pull/578
> 
> Note that I added the session, producer and consumer into the
> try-with-resources block so they are auto-closed at the end of the method.
> 
> Can you take a look and let me know what you think?
> 
> Jon
> 
> On Fri, Sep 27, 2019 at 6:05 PM Ihsan Ecemis  wrote:
> 
>> 
>> Hello Everyone,
>> 
>> We recently upgraded our staging environment from TomEE 8.0.0-M3 to 8.0.0
>> and things started to break.
>> 
>> After some troubleshooting, we realized that we cannot dequeue JMS
>> messages from our ActiveMQ server using MessageConsumers.
>> 
>> 
>> We dequeue messages in 2 different ways:  We use MessageDriven beans for
>> most of our queues.  But with some others, we periodically poll by creating
>> a MessageConsumer (please see the code below for that second case)
>> 
>> MessageDriven beans work without any problems but we cannot receive any
>> messages via MessageConsumers.  That same backend code is working fine with
>> 8.0.0-M3.
>> 
>> 
>> We tested this with different versions of ActiveMQ server (5.15.6, 5.15.9,
>> 5.15.10) but TomEE  8.0.0 did not work with any of them.
>> 
>> 
>> Below is redacted code snippets showing where we have the problem.
>> 
>> Any help will be greatly appreciated.   Please let me know if you have any
>> questions about our setup.
>> 
>> Thanks,
>> 
>> Ihsan.
>> 
>> 
>> 
>> @Stateless
>> public class LogService {
>> 
>>@EJB
>>private CustomJmsService customJmsService;
>> 
>>@javax.ejb.Schedule(second = "*/30", minute = "*", hour = "*")
>>public void pollLogQueue() throws Exception {
>>final TextMessage logMessage =
>> customJmsService.receiveLogMessage(1000);
>>if (logMessage != null) {
>>persistLogMessages(logMessages);
>>}
>>}
>> }
>> 
>> @Stateless
>> public class CustomJmsService {
>> 
>>@Resource(name = "logQueue")
>>private Queue logQueue;
>> 
>>public void sendLogMessage(final LogMessage message) {
>>sendMessage(logQueue, message);
>>}
>> 
>>private void sendMessage(final Queue queue, final CustomJmsMessage
>> message) {
>>try (final Connection connection =
>> connectionFactory.createConnection()) {
>>connection.start();
>> 
>>final Session session = connection.createSession(true,
>> Session.AUTO_ACKNOWLEDGE);
>>final MessageProducer producer = session.createProducer(queue);
>>final String serializedMessage =
>> CustomJsonProvider.toJson(message);
>>final Message jmsMessage =
>> session.createTextMessage(serializedMessage);
>> 
>>// This enqueues messages successfully with both 8.0.0-M3 and
>> 8.0.0
>>producer.send(jmsMessage);
>>} catch (final Exception e) {
>>throw new RuntimeException("Caught exception from JMS when
>> sending a message", e);
>>}
>>}
>> 
>>public TextMessage receiveLogMessage(final long receiveTimeoutMillis) {
>>return receiveMessage(logQueue, receiveTimeoutMillis);
>>}
>> 
>>private TextMessage receiveMessage(final Queue queue, final long
>> receiveTimeoutMillis) {
>>try (final Connection connection =
>> connectionFactory.createConnection()) {
>>connection.start();
>> 
>>final Session session = connection.createSession(true,
>> Session.AUTO_ACKNOWLEDGE);
>>final MessageConsumer messageConsumer =
>> session.createConsumer(queue);
>>final Message jmsMessage =
>> messageConsumer.receive(receiveTimeoutMillis);
>> 
>>// PROBLEM: jmsMessage is always null with 8.0.0. This was
>> working with 8.0.0-M3
>>if (jmsMessage == null) {
>>return null;
>>}
>> 
>>return (TextMessage) jmsMessage;
>>} catch (final Exception e) {
>>throw new RuntimeException("Caught exception from JMS when
>> receiving a message", e);
>>}
>>}
>> }
>> 
>> 
>> 

Problem with MessageConsumers under TomEE 8.0.0

[Ihsan Ecemis]

Hello Everyone,

We recently upgraded our staging environment from TomEE 8.0.0-M3 to 8.0.0 and 
things started to break.  

After some troubleshooting, we realized that we cannot dequeue JMS messages 
from our ActiveMQ server using MessageConsumers.


We dequeue messages in 2 different ways:  We use MessageDriven beans for most 
of our queues.  But with some others, we periodically poll by creating a 
MessageConsumer (please see the code below for that second case)

MessageDriven beans work without any problems but we cannot receive any 
messages via MessageConsumers.  That same backend code is working fine with 
8.0.0-M3.


We tested this with different versions of ActiveMQ server (5.15.6, 5.15.9, 
5.15.10) but TomEE  8.0.0 did not work with any of them.


Below is redacted code snippets showing where we have the problem.

Any help will be greatly appreciated.   Please let me know if you have any 
questions about our setup.  

Thanks,

Ihsan.



@Stateless
public class LogService {

@EJB
private CustomJmsService customJmsService;

@javax.ejb.Schedule(second = "*/30", minute = "*", hour = "*")
public void pollLogQueue() throws Exception {
final TextMessage logMessage = customJmsService.receiveLogMessage(1000);
if (logMessage != null) {
persistLogMessages(logMessages);
}
}
}

@Stateless
public class CustomJmsService {

@Resource(name = "logQueue")
private Queue logQueue;

public void sendLogMessage(final LogMessage message) {
sendMessage(logQueue, message);
}

private void sendMessage(final Queue queue, final CustomJmsMessage message) 
{
try (final Connection connection = 
connectionFactory.createConnection()) {
connection.start();

final Session session = connection.createSession(true, 
Session.AUTO_ACKNOWLEDGE);
final MessageProducer producer = session.createProducer(queue);
final String serializedMessage = CustomJsonProvider.toJson(message);
final Message jmsMessage = 
session.createTextMessage(serializedMessage);

// This enqueues messages successfully with both 8.0.0-M3 and 8.0.0
producer.send(jmsMessage);
} catch (final Exception e) {
throw new RuntimeException("Caught exception from JMS when sending 
a message", e);
}
}

public TextMessage receiveLogMessage(final long receiveTimeoutMillis) {
return receiveMessage(logQueue, receiveTimeoutMillis);
}

private TextMessage receiveMessage(final Queue queue, final long 
receiveTimeoutMillis) {
try (final Connection connection = 
connectionFactory.createConnection()) {
connection.start();

final Session session = connection.createSession(true, 
Session.AUTO_ACKNOWLEDGE);
final MessageConsumer messageConsumer = 
session.createConsumer(queue);
final Message jmsMessage = 
messageConsumer.receive(receiveTimeoutMillis);

// PROBLEM: jmsMessage is always null with 8.0.0. This was working 
with 8.0.0-M3
if (jmsMessage == null) {
return null;
}

return (TextMessage) jmsMessage;
} catch (final Exception e) {
throw new RuntimeException("Caught exception from JMS when 
receiving a message", e);
}
}
}

Using JMS Message Groups with TomEE

[Ihsan Ecemis]

Hi,

In our application, we have a dozen JMS queues and corresponding MDBs, running 
against an external ActiveMQ server.  All this is running reliably.

Recently, we had to add a new queue with the following requirement:  Some 
messages should not get processed concurrently. 

It looked like ActiveMQ Message Groups is built for this purpose so we added 
JMSXGroupID to messages that shouldn’t get processed concurrently  (Reference: 
http://activemq.apache.org/message-groups.html 
)

However, this has not worked as we expected:  Even though the container is 
using a single MessageConsumer (which may be respecting our JMSXGroupID 
settings),  the onMessage method of multiple MDB instances are getting called 
concurrently for the same JMSXGroupID — and that is not acceptable per our 
requirement. 

Is there a way around this using MDBs?  E.g. some kind of TomEE or ActiveMQ 
setting?

If this is not possible using MDBs, what kind of architecture can be used to 
solve this problem?  (We thought about creating our own MessageConsumer in a 
Singleton and have it continuously poll this new queue but we are not excited 
about it.  This would not scale well and we don’t like the idea to manage 
transactions on our own.  Another idea we had was to use ReentrantLocks, but we 
realized that we have to release the lock after transaction is completed and we 
don’t have access to that from a stateless session bean.  That solution is 
messy in other fronts as well so again, we are not excited about it).

Any help will be greatly appreciated.

Thanks,

Ihsan. 

Re: CXF and WebSocket messages are merged together

[Ihsan Ecemis]

> On Jun 16, 2016, at 2:37 AM, Romain Manni-Bucau <rmannibu...@gmail.com> wrote:
> 
> 2016-06-16 4:09 GMT+02:00 Ihsan Ecemis <miece...@gmail.com 
> <mailto:miece...@gmail.com>>:
> 
>> 
>> Thanks for your answer Romain.  I would appreciate any links to inspire me
>> how to do that, especially for Twilio API calls.  I don’t know how to use
>> sessionIds to track connections.
>> 
>> 
> Idea was to use websocket ot http session, I don't know if you activated it
> (atmosphere can need session support for long polling).

We have this in our web.xml:

  
org.atmosphere.cpr.SessionSupport
  

  
org.atmosphere.cpr.sessionSupport
true
  

as documented here: 
https://github.com/Atmosphere/atmosphere/wiki/Enabling-HttpSession-Support 
<https://github.com/Atmosphere/atmosphere/wiki/Enabling-HttpSession-Support>

And we can get sessionId with AtmosphereResource.session(). 

But apparently since Atmosphere doesn’t notify us about the disconnect we can 
still write to the underlying resource, which is not cleared when another 
producer starts using it.  

BTW, we are using @ManagedService 
(https://github.com/Atmosphere/atmosphere/wiki/Getting-Started-with-the-ManagedService-Annotation#managedservice
 
<https://github.com/Atmosphere/atmosphere/wiki/Getting-Started-with-the-ManagedService-Annotation#managedservice>)
 which comes with HeartbeatInterceptor, so I don’t understand how the Server 
doesn’t detect the disconnect for 10 minutes...


>> 
>> Here are 2 new pieces of information:
>> 
>> (1) WebSocket connections were shaky for some users and Atmosphere
>> javascript client had a failover to long-polling.
>> 
>> So yesterday, we disabled long-polling failover and since then we didn't
>> have any errors from Twilio.  Probably it is too early to claim victory but
>> I think it is an interesting observation.
>> 
>> If we don’t see any other errors, I will think that the client was
>> switching from websocket to long-polling, and then getting disconnected.
>> The server (Atmosphere?) didn’t realize this disconnect and kept on writing
>> to the same connection. And at some point that same connection was handed
>> over to the Twilio API call…  (which should not happen!  must be prevented
>> by Tomcat?  nginx?  CXF?  Atmosphere?)
>> 
>> I don’t know how the Socket Connection Pool works at low-level so this is
>> only my speculation, both from my observation there is something really
>> wrong here.
>> 
>> 
>> (2) I looked at Twilio error messages more carefully,  and each error I
>> looked so far contained WebSockets messages addressed to the same user
>> (This is very manual process, I check our logs for each task_id posted to
>> Twilio in JSON).
>> 
>> In one case there were 5 WebSockets messages addressed to the same user,
>> prepended to Twilio XML.   These 5 messages spanned 576 seconds, i.e.
>> almost 10 minutes!  (Each WebSockets messages has a  timestamp).   So we
>> kept on writing to the same connection for 10 minutes after the WebSocket
>> was disconnected   ;-(
>> 
>> 
> Can it be a bad mobile connection?

The user who had lots of disconnects the other day was working in a dorm room 
over WiFi.  Not mobile, but not great connection either. 

Maybe the user was continuously connecting and disconnecting,  and Atmosphere 
was trying to keep the underlying resource alive? 




>> 
>> 
>>> On Jun 15, 2016, at 7:26 PM, Romain Manni-Bucau <rmannibu...@gmail.com>
>> wrote:
>>> 
>>> Is debugging using the sessionId to track connections an option?
>>> Le 16 juin 2016 01:12, "Ihsan Ecemis" <miece...@gmail.com> a écrit :
>>> 
>>>> 
>>>> TL;DR:  We are having this weird, non-reproducable problem in a complex
>>>> system with lots of moving parts. I posted this question to Atmosphere
>>>> mailing list but didn’t get useful answers.  I would appreciate if
>> anyone
>>>> can tell me whether there is any chance what we observe can be a bug
>> with
>>>> Tomcat/TomEE.  Any other help/tips would be greatly appreciated. Thanks
>>>> 
>>>> 
>>>> Problem:
>>>> 
>>>> We experience some weird problems with WebSockets under Atmosphere,
>>>> running under TomEE 7.0.0 — the whole stack is listed below.
>>>> 
>>>> 
>>>> One of our JAX-RS API endpoints (something like /twilio/) is called
>> by
>>>> Twilio.  Twilio expects  the following XML response:
>>>> 
>>>> 
>>>> 
>>>> That system was working

Re: CXF and WebSocket messages are merged together

[Ihsan Ecemis]

Thanks for your answer Romain.  I would appreciate any links to inspire me how 
to do that, especially for Twilio API calls.  I don’t know how to use 
sessionIds to track connections.


Here are 2 new pieces of information:

(1) WebSocket connections were shaky for some users and Atmosphere javascript 
client had a failover to long-polling. 

So yesterday, we disabled long-polling failover and since then we didn't have 
any errors from Twilio.  Probably it is too early to claim victory but I think 
it is an interesting observation.

If we don’t see any other errors, I will think that the client was switching 
from websocket to long-polling, and then getting disconnected.  The server 
(Atmosphere?) didn’t realize this disconnect and kept on writing to the same 
connection. And at some point that same connection was handed over to the 
Twilio API call…  (which should not happen!  must be prevented by Tomcat?  
nginx?  CXF?  Atmosphere?) 

I don’t know how the Socket Connection Pool works at low-level so this is only 
my speculation, both from my observation there is something really wrong here. 


(2) I looked at Twilio error messages more carefully,  and each error I looked 
so far contained WebSockets messages addressed to the same user (This is very 
manual process, I check our logs for each task_id posted to Twilio in JSON).

In one case there were 5 WebSockets messages addressed to the same user, 
prepended to Twilio XML.   These 5 messages spanned 576 seconds, i.e. almost 10 
minutes!  (Each WebSockets messages has a  timestamp).   So we kept on writing 
to the same connection for 10 minutes after the WebSocket was disconnected   ;-(



> On Jun 15, 2016, at 7:26 PM, Romain Manni-Bucau <rmannibu...@gmail.com> wrote:
> 
> Is debugging using the sessionId to track connections an option?
> Le 16 juin 2016 01:12, "Ihsan Ecemis" <miece...@gmail.com> a écrit :
> 
>> 
>> TL;DR:  We are having this weird, non-reproducable problem in a complex
>> system with lots of moving parts. I posted this question to Atmosphere
>> mailing list but didn’t get useful answers.  I would appreciate if anyone
>> can tell me whether there is any chance what we observe can be a bug with
>> Tomcat/TomEE.  Any other help/tips would be greatly appreciated. Thanks
>> 
>> 
>> Problem:
>> 
>> We experience some weird problems with WebSockets under Atmosphere,
>> running under TomEE 7.0.0 — the whole stack is listed below.
>> 
>> 
>> One of our JAX-RS API endpoints (something like /twilio/) is called by
>> Twilio.  Twilio expects  the following XML response:
>> 
>> 
>> 
>> That system was working fine for months.  We were receiving Text Messages
>> with no errors from Twilio.
>> 
>> 
>> Then, we added WebSockets at a different endpoint (something like
>> /ws/).  Using our AngularJS app, our users started communicating with
>> our backend in JSON.  A sample message our backend wrote to a WebSocket
>> client:
>> 
>> 
>> {"thread_id":"Server-2702","session_id":null,"command":"cancel_caleasy_item","data":{"text_message_id":1126,"task_id":10134},"time":1465409434004}
>> 
>> 
>> 
>> After a while, Twilio started sending us "Schema validation warning”
>> emails.  When I went to Twilio Dashboard,  I saw that they received the
>> following response to their API call:
>> 
>> {"thread_id":”Server-1732","session_id":null,"command":"cancel_caleasy_item","data":{"text_message_id”:734,"task_id”:9345},"time":
>> 1465409122781}> standalone="yes"?>
>> 
>> 
>> So Twilio received a message that was meant to be sent to a WebSocket
>> user, prepended to the usual Twilio response!  This looks crazy, and not
>> unacceptable of course.
>> 
>> This happens a few times, sometimes a dozen times a day.  We put together
>> a test system but could not reproduce the problem. (Our test system was not
>> exactly the same system as our production in many respects unfortunately)
>> 
>> Sometimes Twilio receives more than one WebSocket message, again an actual
>> example (redacted just a little for brevity):
>> 
>> {"thread_id":"Server-2722","session_id":null,"command":"cancel_caleasy_item","data":{"text_message_id":1966,"task_id":2},"time":1465409571004}{"thread_id":"Server-2723","session_id":null,"command":"new_caleasy_item","data":{"text_message_id":1453,"text_

Re: [ANNOUNCE] Apache TomEE 7.0.0

[Ihsan Ecemis]

Many thanks to everyone who is involved with this, can’t wait to upgrade my 
servers to 7.0.0

By the way, are you planning to tag the release on Github?  I couldn’t see the 
release here:  https://github.com/apache/tomee/releases 
 


> On May 29, 2016, at 10:50 AM, Romain Manni-Bucau  
> wrote:
> 
> The Apache Team Team is pleased to announce the availability of Apache TomEE
> 7.0.0
> 
> When downloading, please verify signatures using the KEYS file available at:
> http://www.apache.org/dist/tomee
> 
> Maven artifacts are also available in the central Maven repository.
> 
> 
> The Apache TomEE Team

Re: Problem fetching JSF resources over SSL when ActiveMQ broker is running

[Ihsan Ecemis]

You mean you confirmed that this works on Tomcat 8.5.0  (vs Tomcat 8.0.32)? 

Actually, I spoke too soon when I claimed that I made my app work when I moved 
the resource definition from resources.xml to tomee.xml.  It didn’t make a 
difference (I put tomee.xml in a wrong location, and that didn’t start ActiveMQ 
broker so I didn’t observe the problem cause the problem requires ActiveMQ 
broker running).

If Tomcat 8.5.0 is fine, then I can wait until 7.0.0-M4 or 7.0.0


> On Apr 6, 2016, at 5:08 AM, Romain Manni-Bucau <rmannibu...@gmail.com> wrote:
> 
> Hi
> 
> I'm tempted to think it was a bug in tomcat backbone since it seems ok
> on tomee snapshot which upgraded tomcat version.
> 
> Romain Manni-Bucau
> @rmannibucau |  Blog | Github | LinkedIn | Tomitriber
> 
> 
> 2016-04-06 0:13 GMT+02:00 Ihsan Ecemis <miece...@gmail.com>:
>> 
>> I tested a few other cases, and found that everything works fine with TomEE
>> 1.7.x  (I tested 1.7.1 and 1.7.4).
>> 
>> And then I made it work with TomEE 7.0.0-M3 by moving ActiveMQ resource
>> definition from resources.xml file to tomee.xml file!   Both files are
>> attached.
>> 
>> The file contents are the same, why do we have this problem when ActiveMQ
>> resource is defined under resources.xml?
>> 
>> Again, the problem is with serving JSF resources like
>> /jsf/javax.faces.resource/primefaces.js?ln=primefaces=5.3 — and there is
>> NO problem with serving static files like /sample_static_file.txt  or xhtml
>> files served by Faces Servlet, like /jsf/sample_xhtml_file.xhtml
>> 
>> And the problem only exists on Linux or Mac OS X with Java 1.8 and TomEE
>> 7.0.0-M3.   The following cases work fine:
>> 
>> WindowsJava 1.8 and TomEE 7.0.0-M3
>> Mac OS X  Java 1.7  and TomEE 7.0.0-M3
>> Mac OS X  Java 1.8  and TomEE 1.7.x
>> 
>> 
>> 
>> 
>> 
>> 
>> On Apr 5, 2016, at 1:59 AM, Romain Manni-Bucau <rmannibu...@gmail.com>
>> wrote:
>> 
>> Isnt it due to new ciphers? I know tomee 1 uses an older - pre cipher
>> enforcement - AMQ than tomee 7 cause of java version constraints. Maybe
>> testing both can validate it.
>> Le 5 avr. 2016 04:10, "Ihsan Ecemis" <miece...@gmail.com> a écrit :
>> 
>> 
>> Also, I just tried it under Java 1.7.0_71 on Mac OS X and it worked fine!
>> 
>> So far, I could observe the problem under Mac OS X 1.8.0_73,  Mac OS X
>> 1.8.0_77, and Linux  1.8.0_71.
>> 
>> 
>> On Apr 4, 2016, at 5:02 PM, Ihsan Ecemis <miece...@gmail.com> wrote:
>> 
>> 
>> I didn’t have time to investigate your suggestion but tested it under
>> 
>> Windows and confirmed that everything works fine.  Will dig more when I
>> have some time.
>> 
>> 
>> 
>> On Apr 3, 2016, at 7:23 AM, Romain Manni-Bucau <rmannibu...@gmail.com>
>> 
>> wrote:
>> 
>> 
>> SSL config is at connector level so nothing particular under the
>> webapp. Client side behavior doesn't help - at least I'm not sure how
>> to check it at the moment - but on server side you can check if there
>> is any SSLContext#init setup which is unexpected or has some side
>> effects (a debug point there with mvn tomee:debug should do it).
>> 
>> Romain Manni-Bucau
>> @rmannibucau |  Blog | Github | LinkedIn | Tomitriber
>> 
>> 
>> 2016-04-03 13:19 GMT+02:00 Ihsan Ecemis <miece...@gmail.com>:
>> 
>> 
>> Is SSL config different for JSF resources than static files under
>> 
>> Tomcat?  Note that I can fetch static files without any problem,  I have
>> the problem only with JSF resources!  (I didn’t add static files to the
>> sample project to show this but my application have them)
>> 
>> 
>> If you’d like I can setup an EC2 server for you to try this.Would
>> 
>> you have a few minutes to login and see it for yourself?
>> 
>> 
>> 
>> On Apr 3, 2016, at 7:07 AM, Romain Manni-Bucau <rmannibu...@gmail.com>
>> 
>> wrote:
>> 
>> 
>> tried on windows so wonder if it can be linked to gnu tools.
>> 
>> If you get such an issue the only thing I can think about is AMQ
>> changing the SSL config of the JVM which would then make the SSL
>> config of tomcat changing if relying on the JVM settings for any of
>> them.
>> 
>> Can also be a local firewall etc even if weird for a UNIx box - saw
>> several company windows boxes to fail even on localhost cause of
>> McAfee or equivalent.
>> 
>> 
>> Romain Manni-Bucau
>> @rmannibucau |  Blog | Githu

Re: Problem fetching JSF resources over SSL when ActiveMQ broker is running

[Ihsan Ecemis]

I tested a few other cases, and found that everything works fine with TomEE 1.7.x  (I tested 1.7.1 and 1.7.4).And then I made it work with TomEE 7.0.0-M3 by moving ActiveMQ resource definition from resources.xml file to tomee.xml file!   Both files are attached.The file contents are the same, why do we have this problem when ActiveMQ resource is defined under resources.xml?  Again, the problem is with serving JSF resources like /jsf/javax.faces.resource/primefaces.js?ln=primefaces=5.3 — and there is NO problem with serving static files like /sample_static_file.txt  or xhtml files served by Faces Servlet, like /jsf/sample_xhtml_file.xhtmlAnd the problem only exists on Linux or Mac OS X with Java 1.8 and TomEE 7.0.0-M3.   The following cases work fine:Windows    Java 1.8 and TomEE 7.0.0-M3Mac OS X  Java 1.7  and TomEE 7.0.0-M3Mac OS X  Java 1.8  and TomEE 1.7.x

resources.xml
Description: XML document


tomee.xml
Description: XML document
On Apr 5, 2016, at 1:59 AM, Romain Manni-Bucau <rmannibu...@gmail.com> wrote:Isnt it due to new ciphers? I know tomee 1 uses an older - pre cipherenforcement - AMQ than tomee 7 cause of java version constraints. Maybetesting both can validate it.Le 5 avr. 2016 04:10, "Ihsan Ecemis" <miece...@gmail.com> a écrit :Also, I just tried it under Java 1.7.0_71 on Mac OS X and it worked fine!So far, I could observe the problem under Mac OS X 1.8.0_73,  Mac OS X1.8.0_77, and Linux  1.8.0_71.On Apr 4, 2016, at 5:02 PM, Ihsan Ecemis <miece...@gmail.com> wrote:I didn’t have time to investigate your suggestion but tested it underWindows and confirmed that everything works fine.  Will dig more when Ihave some time.On Apr 3, 2016, at 7:23 AM, Romain Manni-Bucau <rmannibu...@gmail.com>wrote:SSL config is at connector level so nothing particular under thewebapp. Client side behavior doesn't help - at least I'm not sure howto check it at the moment - but on server side you can check if thereis any SSLContext#init setup which is unexpected or has some sideeffects (a debug point there with mvn tomee:debug should do it).Romain Manni-Bucau@rmannibucau |  Blog | Github | LinkedIn | Tomitriber2016-04-03 13:19 GMT+02:00 Ihsan Ecemis <miece...@gmail.com>:Is SSL config different for JSF resources than static files underTomcat?  Note that I can fetch static files without any problem,  I havethe problem only with JSF resources!  (I didn’t add static files to thesample project to show this but my application have them)If you’d like I can setup an EC2 server for you to try this.    Wouldyou have a few minutes to login and see it for yourself?On Apr 3, 2016, at 7:07 AM, Romain Manni-Bucau <rmannibu...@gmail.com>wrote:tried on windows so wonder if it can be linked to gnu tools.If you get such an issue the only thing I can think about is AMQchanging the SSL config of the JVM which would then make the SSLconfig of tomcat changing if relying on the JVM settings for any ofthem.Can also be a local firewall etc even if weird for a UNIx box - sawseveral company windows boxes to fail even on localhost cause ofMcAfee or equivalent.Romain Manni-Bucau@rmannibucau |  Blog | Github | LinkedIn | Tomitriber2016-04-03 13:04 GMT+02:00 Ihsan Ecemis <miece...@gmail.com>:That makes this even more interesting.  I can consistently reproducethis on:Mac OS X 10.11.4,  Java 1.8.0_73-b02Linux 4.1.10-17.31.amzn1.x86_64,  Java 1.8.0_71-b15Thank you for trying to reproduce.  I would appreciate if you couldgive me any ideas/tips about how to proceed in terms ofdebugging/experimenting.On Apr 3, 2016, at 4:26 AM, Romain Manni-Bucau <rmannibu...@gmail.com> wrote:HiDidn't reproduce it with your sample. Ran on java8, not sure it islinkedRomain Manni-Bucau@rmannibucau |  Blog | Github | LinkedIn | Tomitriber2016-04-02 13:27 GMT+02:00 Ihsan Ecemis <miece...@gmail.com>:Hello,I was having some weird problems with my JSF pages lately, andafter some brute-force experimentation, I realized that TomEE has problemswith serving JSF resources over SSL if I start an embedded ActiveMQbroker.  I found this awkward as I wouldn’t expect these 2 things tointerfere with each other.I created a barebones project to show the problem:https://github.com/ecemis/activemq-jsf-troubleshoot <https://github.com/ecemis/activemq-jsf-troubleshoot>The project has 2 scripts at top level:run_server.sh:  That’s how I start the servertest_command.sh:  That’s the test script that fetches a JSFresource via curl. I ran this on a separate terminalAnd there are 3 tags you can checkout to test 3 cases:case-1-working:  This case doesn’t have ActiveMQ andtest_command.sh can successfully fetch a JSF resourcecase-2-not-working:  This case adds resources.xml file that startsan embedded ActiveMQ broker. As a result, test_command.sh fails to fetchthe JSF resourcecase-3-working:  This one changes the service from https to http,and  test_command.sh works again (while ActiveMQ broker is running)(You can checkout and try e

Re: Problem fetching JSF resources over SSL when ActiveMQ broker is running

[Ihsan Ecemis]

I didn’t have time to investigate your suggestion but tested it under Windows 
and confirmed that everything works fine.  Will dig more when I have some time.


> On Apr 3, 2016, at 7:23 AM, Romain Manni-Bucau <rmannibu...@gmail.com> wrote:
> 
> SSL config is at connector level so nothing particular under the
> webapp. Client side behavior doesn't help - at least I'm not sure how
> to check it at the moment - but on server side you can check if there
> is any SSLContext#init setup which is unexpected or has some side
> effects (a debug point there with mvn tomee:debug should do it).
> 
> Romain Manni-Bucau
> @rmannibucau |  Blog | Github | LinkedIn | Tomitriber
> 
> 
> 2016-04-03 13:19 GMT+02:00 Ihsan Ecemis <miece...@gmail.com>:
>> 
>> Is SSL config different for JSF resources than static files under Tomcat?  
>> Note that I can fetch static files without any problem,  I have the problem 
>> only with JSF resources!  (I didn’t add static files to the sample project 
>> to show this but my application have them)
>> 
>> If you’d like I can setup an EC2 server for you to try this.Would you 
>> have a few minutes to login and see it for yourself?
>> 
>> 
>>> On Apr 3, 2016, at 7:07 AM, Romain Manni-Bucau <rmannibu...@gmail.com> 
>>> wrote:
>>> 
>>> tried on windows so wonder if it can be linked to gnu tools.
>>> 
>>> If you get such an issue the only thing I can think about is AMQ
>>> changing the SSL config of the JVM which would then make the SSL
>>> config of tomcat changing if relying on the JVM settings for any of
>>> them.
>>> 
>>> Can also be a local firewall etc even if weird for a UNIx box - saw
>>> several company windows boxes to fail even on localhost cause of
>>> McAfee or equivalent.
>>> 
>>> 
>>> Romain Manni-Bucau
>>> @rmannibucau |  Blog | Github | LinkedIn | Tomitriber
>>> 
>>> 
>>> 2016-04-03 13:04 GMT+02:00 Ihsan Ecemis <miece...@gmail.com>:
>>>> 
>>>> That makes this even more interesting.  I can consistently reproduce this 
>>>> on:
>>>> 
>>>> Mac OS X 10.11.4,  Java 1.8.0_73-b02
>>>> Linux 4.1.10-17.31.amzn1.x86_64,  Java 1.8.0_71-b15
>>>> 
>>>> Thank you for trying to reproduce.  I would appreciate if you could give 
>>>> me any ideas/tips about how to proceed in terms of debugging/experimenting.
>>>> 
>>>> 
>>>>> On Apr 3, 2016, at 4:26 AM, Romain Manni-Bucau <rmannibu...@gmail.com> 
>>>>> wrote:
>>>>> 
>>>>> Hi
>>>>> 
>>>>> Didn't reproduce it with your sample. Ran on java8, not sure it is linked
>>>>> 
>>>>> Romain Manni-Bucau
>>>>> @rmannibucau |  Blog | Github | LinkedIn | Tomitriber
>>>>> 
>>>>> 
>>>>> 2016-04-02 13:27 GMT+02:00 Ihsan Ecemis <miece...@gmail.com>:
>>>>>> 
>>>>>> Hello,
>>>>>> 
>>>>>> I was having some weird problems with my JSF pages lately, and after 
>>>>>> some brute-force experimentation, I realized that TomEE has problems 
>>>>>> with serving JSF resources over SSL if I start an embedded ActiveMQ 
>>>>>> broker.  I found this awkward as I wouldn’t expect these 2 things to 
>>>>>> interfere with each other.
>>>>>> 
>>>>>> I created a barebones project to show the problem:  
>>>>>> https://github.com/ecemis/activemq-jsf-troubleshoot 
>>>>>> <https://github.com/ecemis/activemq-jsf-troubleshoot>
>>>>>> 
>>>>>> The project has 2 scripts at top level:
>>>>>> 
>>>>>> run_server.sh:  That’s how I start the server
>>>>>> test_command.sh:  That’s the test script that fetches a JSF resource via 
>>>>>> curl. I ran this on a separate terminal
>>>>>> 
>>>>>> And there are 3 tags you can checkout to test 3 cases:
>>>>>> 
>>>>>> case-1-working:  This case doesn’t have ActiveMQ and test_command.sh can 
>>>>>> successfully fetch a JSF resource
>>>>>> case-2-not-working:  This case adds resources.xml file that starts an 
>>>>>> embedded ActiveMQ broker. As a result, test_command.sh fails to fetch 
>>>>>> the JSF resource
>>>>>> case-3-working:  This one changes the service 

Re: Problem fetching JSF resources over SSL when ActiveMQ broker is running

[Ihsan Ecemis]

Is SSL config different for JSF resources than static files under Tomcat?  Note 
that I can fetch static files without any problem,  I have the problem only 
with JSF resources!  (I didn’t add static files to the sample project to show 
this but my application have them)

If you’d like I can setup an EC2 server for you to try this.Would you have 
a few minutes to login and see it for yourself?  
 

> On Apr 3, 2016, at 7:07 AM, Romain Manni-Bucau <rmannibu...@gmail.com> wrote:
> 
> tried on windows so wonder if it can be linked to gnu tools.
> 
> If you get such an issue the only thing I can think about is AMQ
> changing the SSL config of the JVM which would then make the SSL
> config of tomcat changing if relying on the JVM settings for any of
> them.
> 
> Can also be a local firewall etc even if weird for a UNIx box - saw
> several company windows boxes to fail even on localhost cause of
> McAfee or equivalent.
> 
> 
> Romain Manni-Bucau
> @rmannibucau |  Blog | Github | LinkedIn | Tomitriber
> 
> 
> 2016-04-03 13:04 GMT+02:00 Ihsan Ecemis <miece...@gmail.com>:
>> 
>> That makes this even more interesting.  I can consistently reproduce this on:
>> 
>> Mac OS X 10.11.4,  Java 1.8.0_73-b02
>> Linux 4.1.10-17.31.amzn1.x86_64,  Java 1.8.0_71-b15
>> 
>> Thank you for trying to reproduce.  I would appreciate if you could give me 
>> any ideas/tips about how to proceed in terms of debugging/experimenting.
>> 
>> 
>>> On Apr 3, 2016, at 4:26 AM, Romain Manni-Bucau <rmannibu...@gmail.com> 
>>> wrote:
>>> 
>>> Hi
>>> 
>>> Didn't reproduce it with your sample. Ran on java8, not sure it is linked
>>> 
>>> Romain Manni-Bucau
>>> @rmannibucau |  Blog | Github | LinkedIn | Tomitriber
>>> 
>>> 
>>> 2016-04-02 13:27 GMT+02:00 Ihsan Ecemis <miece...@gmail.com>:
>>>> 
>>>> Hello,
>>>> 
>>>> I was having some weird problems with my JSF pages lately, and after some 
>>>> brute-force experimentation, I realized that TomEE has problems with 
>>>> serving JSF resources over SSL if I start an embedded ActiveMQ broker.  I 
>>>> found this awkward as I wouldn’t expect these 2 things to interfere with 
>>>> each other.
>>>> 
>>>> I created a barebones project to show the problem:  
>>>> https://github.com/ecemis/activemq-jsf-troubleshoot 
>>>> <https://github.com/ecemis/activemq-jsf-troubleshoot>
>>>> 
>>>> The project has 2 scripts at top level:
>>>> 
>>>> run_server.sh:  That’s how I start the server
>>>> test_command.sh:  That’s the test script that fetches a JSF resource via 
>>>> curl. I ran this on a separate terminal
>>>> 
>>>> And there are 3 tags you can checkout to test 3 cases:
>>>> 
>>>> case-1-working:  This case doesn’t have ActiveMQ and test_command.sh can 
>>>> successfully fetch a JSF resource
>>>> case-2-not-working:  This case adds resources.xml file that starts an 
>>>> embedded ActiveMQ broker. As a result, test_command.sh fails to fetch the 
>>>> JSF resource
>>>> case-3-working:  This one changes the service from https to http, and  
>>>> test_command.sh works again (while ActiveMQ broker is running)
>>>> 
>>>> (You can checkout and try each case separately, e.g. git checkout 
>>>> case-2-not-working. You can also compare the changes between the cases via 
>>>> git diff, e.g. git diff case-1-working case-2-not-working)
>>>> 
>>>> Note that fetching static files works in all cases. The problem I could 
>>>> observe so far is just with fetching JSF resources.
>>>> 
>>>> All help will be greatly appreciated.
>>>> 
>>>> Thanks,
>>>> 
>>>> Ihsan.
>>>> 
>>>> 
>>>> PS: For the impatient who wants to know the errors before cloning the 
>>>> sample project above, here is what curl gives me:
>>>> 
>>>> * SSLRead() return error -9845
>>>> * Closing connection 0
>>>> curl: (56) SSLRead() return error -9845
>>>> 
>>>> 
>>>> And here is what I get on the server:
>>>> 
>>>> WARNING - JSF1064: Unable to find or serve resource, primefaces.js, from 
>>>> library, primefaces.
>>>> WARNING -
>>>> org.apache.catalina.connector.ClientAbortException: jav

Re: Partial ajax update problem with TomEE 7.0.0-MX

[Ihsan Ecemis]

Thank your for the quick reply Romain.  I just figured the problem:  I was 
using the “evil” c:forEach instead ui:repeat on that page  (Re-reading BalusC’s 
following StackOverflow post helped: 
https://stackoverflow.com/questions/3342984/jstl-in-jsf2-facelets-makes-sense 
<https://stackoverflow.com/questions/3342984/jstl-in-jsf2-facelets-makes-sense> 
)

It still puzzles me why this was working perfectly under 1.7.1.  I guess there 
must be a bug with Mojarra 2.1 that got fixed under Mojarra 2.2  (too tired now 
to dig for the Jira issue with that fixed)


> On Mar 12, 2016, at 3:34 AM, Romain Manni-Bucau <rmannibu...@gmail.com> wrote:
> 
> Hi
> 
> The only potentially breaking change I m aware of is the coercing of string
> from null to "" which was a servlet change. However if you can reproduce it
> we can help you to dig into it.
> Le 12 mars 2016 07:30, "Ihsan Ecemis" <miece...@gmail.com> a écrit :
> 
>> 
>> Hi,
>> 
>> About a month ago, I upgraded my application from using TomEE 1.7.1 to
>> TomEE 7.0.0-M1.  I had to change only my pom.xml and server.xml files,  and
>> all seemed to be working fine after the upgrade.
>> 
>> However, I just realized that I have some problems with my PrimeFaces JSF
>> pages (I am using version 5.3) that are using partial ajax updates.  Page
>> reloads work fine, but when I click a button that submits a partial ajax
>> request,  the page is missing some components.
>> 
>> AFAIK, JSF 2.2 is backward compatible with JSF 2.1.  Before I start diving
>> into debugging this, I wonder if anybody has any idea on top of their head
>> about what else I should have updated in my code or settings regarding this
>> TomEE upgrade.   (I know that that help would be limited without providing
>> sample code but it would take me a long time to produce a small sample out
>> of my codebase.  Plus I don’t have any errors or other suspicious messages
>> in my logs and that’s why it took me so long to observe this bug)
>> 
>> Thanks,
>> 
>> Ihsan.
>> 
>> PS: The problem persists with TomEE 7.0.0-M2 and TomEE 7.0.0-M3.

Partial ajax update problem with TomEE 7.0.0-MX

[Ihsan Ecemis]

Hi,

About a month ago, I upgraded my application from using TomEE 1.7.1 to TomEE 
7.0.0-M1.  I had to change only my pom.xml and server.xml files,  and all 
seemed to be working fine after the upgrade.

However, I just realized that I have some problems with my PrimeFaces JSF pages 
(I am using version 5.3) that are using partial ajax updates.  Page reloads 
work fine, but when I click a button that submits a partial ajax request,  the 
page is missing some components. 

AFAIK, JSF 2.2 is backward compatible with JSF 2.1.  Before I start diving into 
debugging this, I wonder if anybody has any idea on top of their head about 
what else I should have updated in my code or settings regarding this TomEE 
upgrade.   (I know that that help would be limited without providing sample 
code but it would take me a long time to produce a small sample out of my 
codebase.  Plus I don’t have any errors or other suspicious messages in my logs 
and that’s why it took me so long to observe this bug)

Thanks,

Ihsan.

PS: The problem persists with TomEE 7.0.0-M2 and TomEE 7.0.0-M3.

Re: Problem setting Xms/Xmx with Maven Plugin

[Ihsan Ecemis]

Thank you Vincenzo,  the below worked   ;-)


On Jan 18, 2015, at 12:18 PM, Vincenzo D'Amore v.dam...@gmail.com wrote:

 Hi,
 
 if you want modify jvm memory settings during the execution of maven
 goal tomee:run  you should change tomee-maven-plugin configuration:
 
 configuration
args-Xms64m -Xmx256m/args
 /configuration
 
 Take a look at the documentation here:
 http://tomee.apache.org/maven/index.html
 
 
 On Sat, Jan 17, 2015 at 5:39 AM, Ihsan Ecemis ih...@lindycare.com wrote:
 
 
 Hello,
 
 I am having problems with setting Xms/Xmx values for Tomcat. Here is my
 setup:
 
 - Attached file is located at src/main/tomee/bin/setenv.sh
 - I start Tomcat with the following command:  mvn -Dmaven.test.skip=true
 clean package tomee:build tomee:run”
 
 When I check the running process with “ps auwx”,  I see that -Xms256m
 -Xmx768m” is not there, and the server can allocate more memory than I
 specify.
 
 BTW, I see that setenv.sh file is copied to
 target/apache-tomee/bin/setenv.sh without any problems.
 
 And if I do :
 
 #  cd target/apache-tomee/
 #  ./bin/catalina.sh run
 
 The server starts running with the -Xms256m -Xmx768m” setting and doesn’t
 allocate more memory.
 
 Any help is greatly appreciated.
 
 Thanks,
 
 Ihsan.
 
 
 

Problem setting Xms/Xmx with Maven Plugin

[Ihsan Ecemis]

Hello, 

I am having problems with setting Xms/Xmx values for Tomcat. Here is my setup:

- Attached file is located at src/main/tomee/bin/setenv.sh
- I start Tomcat with the following command:  mvn -Dmaven.test.skip=true clean 
package tomee:build tomee:run”

When I check the running process with “ps auwx”,  I see that -Xms256m 
-Xmx768m” is not there, and the server can allocate more memory than I specify.

BTW, I see that setenv.sh file is copied to target/apache-tomee/bin/setenv.sh 
without any problems.

And if I do :

#  cd target/apache-tomee/
#  ./bin/catalina.sh run

The server starts running with the -Xms256m -Xmx768m” setting and doesn’t 
allocate more memory.

Any help is greatly appreciated.

Thanks,

Ihsan.